Harness Engineering: Building the Production Cage for Powerful Domain Agents — Mike Chambers, AWS

A coding assistant on your machine and an agent serving an audience can use similar models while demanding very different engineering. Mike Chambers, a senior AI specialist developer advocate at AWS, approaches that difference through the infrastructure surrounding the model. His opening background moves from generative AI education in 2023 to an MCP Lambda handler in 2025 that simplifies serverless tool serving. The live examples will make the same progression: start with an agent that works locally, then change how its surrounding parts operate.

The first distinction is between agents we use and agents we build. Claude Code, Cursor and Kiro belong to the first category, alongside productivity assistants. The second category consists of agents developers offer to other people. These roles can connect—you can build an agent somebody else uses—but the builder has to choose behavior and resource use for that audience. A user's enthusiasm for consuming tokens does not settle how a service should operate.

A harness begins with the ordinary image of straps and fastenings controlling an animal; substitute a model and the analogy works. The more useful engineering definition is subtraction: take an agent, remove its model, and everything remaining is the harness. This definition includes the machinery that gives the model context, connects it to actions and manages its operation. It does not require a particular framework.

For a coding assistant with access to local files, the harness determines how it uses memory, which skills it follows and which tools or MCP servers it can reach. Documentation servers are one concrete destination. Teams can distribute these choices across their developers' assistants, extending familiar coding standards into shared harness standards. The environment becomes part of how the team asks software to be written.

The Agent Toolkit for AWS is presented as an installable aid for assistants helping with AWS development and deployment. Its purpose connects to Chambers's objection to “slop ops”: letting an agent make ad hoc cloud changes reproduces the problem of clicking through a console, only through a different operator. Console exploration can help explain a system. Production provisioning needs a representation the developer continues to own.

Consider the request to create an S3 bucket or obtain an EC2 instance. A direct agent action leaves the resource creation in the agent's interaction with the cloud. Chambers's preferred sequence asks the assistant to produce infrastructure as code, then uses that code to create the resources. The desired cloud result remains the same; the deployment definition now exists as code under the developer's control. The assistant helps describe and construct the deployment rather than becoming the only place its decisions live.

An agent built for users still needs memory, skills and tools. MCP can connect it to many kinds of functionality, but those connections are only part of operating a service. The builder also has to place the loop, payments, identity, runtime and context management somewhere. Observability and evaluations appear last in Chambers's list, followed immediately by his correction: they should come first.

Putting every responsibility into one container makes the container the unit you replicate. Chambers rejects that as the architecture for the thousands of users he has in mind: each component needs its own scaling consideration. The next examples focus especially on memory. Adding persistence inside a local program improves its behavior; moving memory into a connected service changes how that capability can operate and scale. That separation is his working meaning of harness engineering.

The first example in Kiro uses the Strands Agents SDK. An agent receives a system prompt and two tools: an installable calculator and a time function defined with a tool decorator. This is already a small harness. The tools supply capabilities around the model, and Strands manages the agent loop. Chambers skips executing the proposed time query; the example establishes the structure of a laptop agent, with deployment capabilities still to add. He also enjoys pointing out that he wrote this one himself: “I deserve a round of applause.”

The second Strands example, generated with Kiro, adds two distinct ways to retain information:

• Session restoration: A session manager maintains state between invocations and rehydrates conversation history when the user returns. This carries the conversation forward instead of making each invocation start without its earlier context.
• Explicit remembering: A remember tool lets the agent choose to retain information about the user, with longer-lived memories stored in files. This is separate from restoring the conversation itself.

The observable change appears in a World Cup question. Chambers starts the local agent, enters a greeting, then asks who will win. The response recognizes that he wants Australia to win, a preference he attributes to their previous conversations. The causal sequence is useful: earlier interaction leaves retained context; the session manager restores history on a later invocation; that context influences the new answer. The walkthrough does not distinguish whether this particular preference also passed through the file-based remember mechanism.

Remembering a preference does not give the model knowledge of the winner. Chambers says the agent also acknowledges that it does not know. The result is personalization: a later answer can refer to what the user cares about while leaving the outcome uncertain. Persistence supplies context for the answer, rather than evidence for a prediction.

What crosses the gap between two conversations? The flow below follows the history-restoration path in the example. The important relationship is between retained conversation state and the later response: the later invocation can use earlier information because the harness restores it. Both the agent and its persistence mechanisms still run on Chambers's machine, so the next step changes where memory is managed.

Amazon Bedrock AgentCore supplies the cloud infrastructure in the next example. Its CLI walks through an agent setup, initially skipping the option called harness. This route can accept existing code or create a hello-world agent for customization. Chambers chooses generated Python code from the offered Python and TypeScript options.

Several choices remain separate in this setup:

• Caller interface: HTTP is the selected entry point. MCP serving and AG-UI for interactive chat agents are presented as alternatives.
• Agent implementation: Strands is the example framework, but Chambers describes support for other frameworks or custom code.
• Model access: The runtime is presented as supporting models beyond Amazon's own offerings and those accessed through Bedrock. The demonstration keeps the offered default model.

Memory is the consequential infrastructure choice. Selecting short-term and long-term memory causes the setup to create cloud infrastructure to manage those capabilities separately from the running agent. Chambers describes the memory infrastructure as connected to the agent and running asynchronously from it. The agent can use memory without containing the memory service inside its own execution environment.

What changes when memory moves outside the agent? The topology below shows the selected HTTP entry point, the agent's runtime integration and the separate memory infrastructure. The separation makes independent operation visible: memory remains connected to the agent while becoming its own managed component. After beginning local configuration, Chambers switches to a prepared project he had already deployed, so this sequence is a setup walkthrough rather than a fresh deployment completing onstage.

The prepared project is still a recognizable Strands agent, now linked to the AgentCore app. Chambers assigns scaling and multi-tenant isolation to the managed runtime: developers can write an agent for one user without writing all the machinery for multiple tenants themselves. That is a substantial shift in responsibility, although the walkthrough does not explain the isolation mechanism or measure behavior under load.

The application capabilities remain familiar: tools, an MCP connection, a session manager, memory connections and a system prompt. Runtime integration surrounds them. The design therefore separates what the agent does from infrastructure that operates it, while still requiring the application to connect to the selected services.

agentcore dev opens a browser interface connected to the locally running agent. Chambers interacts with that local instance and describes seeing code updates appear live. The same interface can switch to a deployed version. Local iteration and hosted interaction share a development interface, but they address different running instances.

agentcore deploy applies the earlier infrastructure-as-code principle to the harness itself. It deploys the agent, runtime, memory and other selected components. Inspection then reaches both execution and persistence: traces help reveal what happened during a run, and stored memories help reveal what information survived it. These are concrete ways to investigate behavior; the talk emphasizes evaluation as a priority without developing an evaluation method.

The ending returns to the CLI option Chambers deliberately skipped. His examples needed relatively little application behavior: a system prompt and tools. He suggests that perhaps 80% of agentic use cases or agent development could be covered by a prompt connected to MCP tools. This is his proposed estimate, with no measured coverage rate or defined population of use cases, so its useful implication is a design question: how much custom orchestration does this particular agent actually need?

The built-in harness offers a concrete alternative. The configuration shown is a simple JSON file naming a model and a system prompt, deployable with agentcore deploy without writing agentic code. The harness supplies the surrounding implementation while the developer specifies the model and instructions. The shown fields illustrate the simplified entry point; they do not explain how tools are declared in that configuration.

There are therefore two useful adoption choices:

• Use the built-in harness: Supply configuration and let the provided implementation run the agent, when that implementation meets the use case.
• Adopt a component: Keep an existing production agent and integrate a selected capability. Chambers's closing example adds managed, serverless long-term memory to an agent that already works.

Selective adoption preserves the point of separating the parts in the first place. A useful memory service need not require replacing the entire agent architecture. Strands, which Chambers closes by describing as an open-source, model-first framework, assembles the agent in these examples; AgentCore capabilities provide composable infrastructure around its operation. The final choice is how much of that surrounding work to build yourself and how much to take as a managed component.