Agent Harnesses
An agent harness is the software and policy environment surrounding a model that gives an AI agent context, state, tools, a control loop, constraints, evaluation, and operational visibility. The model proposes behavior; the harness mediates what information and authority turn those proposals into action. New SDLC source record (pp. 24–30) · Security and evaluation source record (pp. 8–12)
Components
Across the sources, a production harness may include:
- context assembly and retrieval;
- instructions, policies, and specifications;
- memory and session state;
- tool dispatch and interoperability clients;
- orchestration, retries, and stopping conditions;
- sandboxes, permissions, network boundaries, and approval gates;
- deterministic checks and evaluators;
- traces, metrics, audit records, and deployment infrastructure.
Anthropic’s “augmented LLM” and tool-use loop cover the functional core, while OpenAI groups the foundations as model, tools, and instructions. The Google papers extend the surrounding system into production, security, and SDLC controls. Anthropic source record · OpenAI source record · New SDLC source record (pp. 10–30)
External enforcement
A central safety principle is that critical restrictions should not depend on the model remembering or obeying a prompt. Sandboxing, scoped credentials, policy checks, network controls, and approval gates should be enforced externally by the harness. Security and evaluation source record (pp. 9–26) · Spec-driven development source record (pp. 26–35)
This extends agent safety and control from output filtering to the complete execution environment.
Harness versus framework
A framework is an implementation library; a harness is an architectural role. A harness can be built directly or through one or more frameworks. Anthropic cautions that framework abstractions can obscure prompts, responses, and control flow, so teams should retain visibility into the actual harness behavior. Anthropic source record
Knowledge substrate
An agent harness may consume a maintained LLM Wiki or a portable OKF bundle as context. The knowledge representation does not decide retrieval, trust, permissions, or context priority; those remain harness responsibilities. Karpathy LLM Wiki source record · OKF source record
Verification boundary
Analysis: The harness should be evaluated as part of the agent, not treated as neutral plumbing. Tool schemas, context selection, retry logic, permissions, and termination behavior can change outcomes even with the same model.
Useful harness tests include:
- context and instruction selection;
- tool routing and parameter validation;
- permission and sandbox enforcement;
- recovery from tool errors and partial state;
- stopping and escalation behavior;
- trace completeness and privacy;
- outcome quality under realistic load and multi-step tasks.
Evidence status
Confidence is medium. Multiple practical sources agree on the importance of surrounding controls, but “harness” boundaries vary among systems and the complete architectures proposed by the Google papers lack independent comparative validation.