What is Agent Harness?
Agent Harness is the application control system around an AI agent that assembles context, constrains model proposals, mediates tools and permissions, persists state and effects, emits evidence, and enforces termination, recovery, evaluation, and release policy.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
An Agent Harness turns a model-driven loop into an operable application. The term is an engineering abstraction, not a standardized protocol or a requirement for one product, service, or fixed number of layers. It covers the controls surrounding model decisions; it does not refer to electrical wiring, mechanical restraints, or hardware test harnesses.
Harness, Agent, Runtime, and Workflow Engine have different responsibilities. The Agent chooses or proposes task actions within an allowed envelope. The Runtime creates, schedules, resumes, and terminates runs. A Workflow Engine can provide durable histories, queues, timers, and retries. The Harness defines and connects the application-level contracts across context, tools, identity, policy, state, effects, approvals, observations, evaluation, and releases. One library may package several roles, but the boundaries still matter during failures and audits.
A production release should pin the model and provider adapter, system instructions and prompt digest, context builder, retriever and data policy, tool catalog and schema digests, runtime and state schema, authorization policy, approval rules, budgets, parsers, evaluators, and event schema. This Release Manifest makes a run reproducible enough to compare, route, roll back, or quarantine; a model name alone is not an Agent version.
The model proposes; trusted code authorizes and executes. Tool schemas validate shape, not permission. The Harness resolves actor and tenant identity, filters context, verifies resource scope, applies current policy, obtains proposal-bound approval when required, invokes narrow adapters with least-privilege credentials, validates and limits results, and prevents retrieved or tool-provided instructions from expanding authority.
Persist authoritative Run State separately from model context, transcript, long-term memory, and audit evidence. Use state versions or compare-and-set for concurrent workers. Checkpoints identify where work can resume, but external writes need stable operation keys and an Effect Journal. A timeout after dispatch can be outcome_unknown; reconcile with the source system before retrying. Cancellation does not undo a committed effect.
Treat messages, retrieved documents, tool definitions, tool results, files, web pages, and worker outputs as untrusted data. Apply allowlists, provenance, size and type limits, redaction, sandboxing, egress control, secret isolation, output validation, and downstream authorization. Approval Gates, Guardrails, and Human-in-the-Loop review reduce specific risks but do not make an overprivileged adapter safe.
The Evidence Plane should correlate release, run, step, call, parent, attempt, model, tool, policy decision, approval, operation key, effect status, usage, cost, latency, redaction, cancellation, and terminal reason. Do not retain hidden chain-of-thought or unnecessary sensitive payloads. Evaluate complete trajectories and source-system outcomes against a simpler deterministic or single-agent baseline, then use shadow runs, bounded canaries, rollback criteria, and failure injection before expanding autonomy.
Key Characteristics
- Application-level contracts across context, model, tools, identity, policy, state, effects, and evidence
- Explicit separation among Agent decisions, Runtime execution, Workflow durability, and Harness controls
- Versioned Release Manifest rather than a model name as the complete deployment identity
- Proposal, authorization, execution, effect accounting, and observation as separate records
- Durable state, idempotent effects, unknown-outcome reconciliation, cancellation, and recovery
- Trajectory evaluation, failure injection, shadow testing, canary limits, and rollback evidence
Common Use Cases
- Operating customer-service agents with tenant isolation and approval-bound writes
- Constraining coding agents to reviewed repositories, commands, networks, and merge paths
- Running research agents with source provenance, budgets, result limits, and citation checks
- Mediating MCP and API tools through policy, credentials, validation, and effect records
- Replaying failed runs against a new release without repeating production side effects
- Comparing agent releases using trajectories, accepted business outcomes, latency, and cost
Example
Loading code...Frequently Asked Questions
Is an Agent Harness the same as an AI Agent?
No. The Agent proposes decisions and actions. The Harness is the surrounding application control system that constrains inputs, tools, permissions, state, effects, evidence, recovery, and release.
How is an Agent Harness different from an Agent Runtime?
The Runtime owns run and step execution, scheduling, persistence, and cancellation. The Harness is broader: it defines how runtime execution connects to context, policy, tools, approvals, effects, evaluation, security, and release governance.
Does an Agent Harness require a specific framework?
No. It can be assembled from application code, model and tool adapters, a workflow engine, policy services, stores, sandboxes, and telemetry. The term does not define one standard architecture or vendor.
What should an Agent Harness record?
Record versioned release identity, run and step events, model and tool calls, policy and approval decisions, state versions, operation keys, effect status, errors, budgets, latency, cost, redaction, cancellation, and terminal outcome.
Can an Agent Harness guarantee safe behavior?
No. It makes selected boundaries enforceable and testable. Safety still depends on narrow capabilities, least privilege, downstream authorization, isolation, data governance, evaluation, monitoring, incident response, and human accountability.