The demo runs smoothly. The agent answers a question with what feels like genuine situational awareness, and the sales engineer explains that this is exactly what your users will experience. Someone in the room says "this is impressive" out loud, which is the moment the decision quietly gets made.

What the room has just watched is an agent that someone else built, running in someone else's environment, probably connected to a dataset that was cleaned for this specific demonstration. What the contract will require someone to build is a different thing entirely, serving dozens or hundreds of users across real operational data, maintaining context between sessions, logging decisions for when something goes wrong, and running without a sales engineer standing by to restart it when it loops. The distance between those two things is not a matter of polish or timeline. It is an architectural gap that has a name, and the IT director in that room almost certainly does not know the name yet.

Two Kinds of Agents, One Demo

Mike Chambers, AWS Senior AI Specialist, speaking at the aiDotEngineer conference in September 2026, drew a distinction that belongs in every IT strategy conversation before a platform engagement gets signed. There are, he argued, two fundamentally different categories of agent: agents we use, and agents we build, as we covered in part 1 of this series. Agents we use include tools like Claude Code, Cursor, and Kiro, coding assistants and productivity tools that serve a single user in a single session and can be configured for maximum token utilization because there is only one person's context to manage. Agents we build are production systems that serve an audience, maintain state across multiple users over time, and need to be architected accordingly from the first line of infrastructure code.

The demo almost always shows an agent-we-use. The contract almost always proposes to build an agent-we-build. This is not necessarily dishonest on the vendor's part; many vendors genuinely conflate the two because the underlying model behavior looks similar at demo scale. But the conflation is expensive for the buyer, because these two categories require different infrastructure, and the infrastructure for agents-we-build has to be designed before implementation begins. Once the sprint starts, every design decision that was left unspecified becomes the vendor's discretionary call, made under time pressure, in favor of whatever ships fastest.

This distinction is also the organizing question for internal IT strategy: when does your organization need an agent-we-use, and when does it need an agent-we-build? They are not points on a maturity curve. They are different tools, and deploying the wrong one, even a well-engineered version of the wrong one, produces problems that are hard to diagnose because the system technically works.

What a Harness Is and Why It Belongs in the Strategy Conversation

Chambers defines a harness as everything in an agent except the model itself: memory management, skills, tools, MCP servers, observability, loop control, scaling, payments, identity, and runtime infrastructure. Remove the model from a production agent, and what remains is the harness. This is useful vocabulary not because it is new jargon to acquire, but because it names the surface area your IT strategy has to account for.

In practice, most internal AI strategy conversations focus on model selection, which is the one component the harness definition explicitly sets aside. The conversations tend to sound like: "Should we use GPT-4o or Claude?" or "Does this vendor support our preferred model?" Those are real questions, but they are downstream of the infrastructure questions that actually determine whether a production agent succeeds. The model is the engine. The harness is the vehicle, and you cannot evaluate the vehicle by staring at the engine.

For agents-we-use, the harness is relatively lean: it covers the tools the assistant can call, the memory standards your engineering team maintains, and the coding or workflow standards baked into the instruction set. Well-organized teams have been building these informally for years, often without calling them harnesses at all. For agents-we-build, the harness becomes independently complex in each of its components, and that complexity has to be planned for before deployment.

The Components That Determine Whether a Production Agent Actually Works

Chambers describes memory, loop control, and observability as separately scalable components in a production harness, and he demonstrated this concretely during his session by showing how Bedrock Agent Core provisions long-term and short-term memory as independent cloud infrastructure, running asynchronously from the agent itself and connected to it rather than embedded in it. That architecture is not the default. It is a deliberate design choice that has to be made before deployment, because retrofitting separate memory infrastructure onto a running agent is not a configuration change; it is a rebuild.

For an IT director evaluating a vendor proposal or an internal build, the question "how does the agent remember what a user asked last week?" needs a real answer. "The platform handles that" is technically true the same way "the building handles that" is technically true about plumbing. The question that actually needs an answer is which memory tier handles it, where that memory lives relative to the agent runtime, who manages it when it grows past initial projections, and what happens to user state if the agent service restarts.

Loop control is the component that generates the most expensive surprises on cloud-billed infrastructure. An agent-we-build can be invoked by many users simultaneously, and if any invocation enters a loop because a tool call returns an unexpected value, the costs run until someone notices. Chambers is explicit that loop management needs to be extracted from the agent itself and scaled separately, which means it needs to be designed as a component before the agent goes anywhere near production. A vendor proposal that does not address loop control is not proposing to solve this problem; it is proposing to discover it later at your expense.

Observability is the component that matters most when something goes wrong and the one most likely to be deferred until after go-live. If an agent misroutes a request, associates a document with the wrong record, or makes a tool call that produces a cost anomaly, the ability to reconstruct what happened depends entirely on whether the harness was logging decisions at the point they were made. Without purpose-built observability, the audit trail is whatever the model happened to include in its output, which is not an audit trail. Chambers frames infrastructure-as-code and observability standards as things that should be built into agent harnesses from the start specifically to avoid what he calls "slop ops at scale," the condition where a production system is running but nobody actually knows what it is doing.

The Scenario Question Your Strategy Actually Needs to Answer

The agents-we-use versus agents-we-build distinction is not just definitional; it maps directly to scenarios your organization is already planning for, and the mapping changes what you have to build. An agent deployed to help a developer work faster in their editor is an agent-we-use, and the harness design is relatively contained: tools the agent can call, memory standards baked into the instruction file, model selection based on task type. The organizational risk of a poorly designed harness here is low, because the user is also the quality-control layer and failures surface immediately.

An agent deployed to handle intake, route requests, summarize documents for multiple users, or make decisions that touch shared data is an agent-we-build, and the harness requirements are qualitatively different. Session state has to persist across invocations from different users. Memory has to be segmented correctly so one user's context does not leak into another's. Loop control has to be externalized and monitored. Observability has to be in place before go-live, not added after. These are not implementation details to leave to the vendor's judgment; they are architectural decisions that shape what gets built.

The scenario question your IT strategy needs to answer, before any vendor conversation, before any SOW, is which category each planned use case actually falls into. Many organizations are currently procuring agents-we-build while budgeting and planning as though they are agents-we-use, and the gap between those two planning assumptions is where implementation costs and timelines go wrong.

What to Ask Before Anything Gets Built

The harness conversation belongs in the pre-kickoff window, which is the only point where you have real influence over how these components get designed. After implementation begins, each unspecified harness component gets resolved by whoever is writing that module that week, using whatever the platform defaults provide, on whatever timeline the sprint allows. Those defaults are not necessarily wrong, but they are not the result of a design decision you participated in.

Ask the vendor or internal team to describe the memory architecture: whether long-term and short-term memory are provisioned as separate infrastructure, who manages that infrastructure as data volumes grow, and what happens to session state during a service restart. Ask how loop control is implemented, whether it is embedded in the agent or managed as an external component, and what the cost exposure looks like if an invocation enters a loop in production. Ask what observability is built into the harness at launch, specifically whether tool calls, decisions, and cost events are logged at the point they happen. Ask, for each planned use case, whether it is being designed as an agent-we-use or an agent-we-build, and whether the harness plan reflects that distinction.

If those questions produce vague answers, that tells you something important: the harness has not been designed yet. The time to resolve that is before the sprint starts, because the sprint will resolve it regardless, just without you in the room.