The Case for Harness Engineering
Mike Chambers distinguishes between two types of agents: those we use (coding assistants like Cursor or Claude Code) and those we build. While the former focuses on developer productivity, the latter requires a robust architecture to handle production-grade demands like multi-tenancy, identity, and scaling.
He defines a "harness" by subtraction: if you remove the LLM from an agent, everything remaining—memory, tools, loop management, and runtime—is the harness. The core mistake in early agent development is bundling these components into a single container. Instead, developers should treat these as independent, composable services that can scale separately. This approach, which he calls "harness engineering," is essential for moving from local prototypes to production systems serving thousands of users.
Moving Beyond 'Slop Ops'
Chambers strongly advocates against "slop ops," the agentic equivalent of "click ops." Developers should avoid having agents manually spin up cloud resources via console clicks. Instead, agents should be designed to generate Infrastructure as Code (IaC). This ensures that the infrastructure remains owned and managed by the engineering team, maintaining security, reproducibility, and visibility into the deployment environment.
Composable Architecture with Agent Core
To achieve production readiness, Chambers demonstrates the use of AWS Bedrock Agent Core. This framework allows developers to decouple critical agent functions:
- Memory Management: By offloading long-term and short-term memory to managed, asynchronous infrastructure, the agent remains lightweight and scalable.
- Multi-tenancy: Using frameworks like the Strands Agents SDK in conjunction with Agent Core allows developers to handle isolation and identity without writing custom multi-tenant logic from scratch.
- Observability: Chambers emphasizes that observability and evaluation should be the first priority, not an afterthought. By separating the harness, developers can implement tracing and evaluation metrics across individual components.
Ultimately, Chambers suggests that for many use cases, the "harness" is the product. He demonstrates that by using a simple JSON configuration, one can define an agent's model and system prompt without writing any custom agent code, allowing the infrastructure to handle the heavy lifting of execution, tool integration via MCP (Model Context Protocol), and state management.