AI agent harnesses and harness engineering

A foundation model reasons. Left alone, that reasoning is text and tool-call proposals. The harness is what makes the reasoning operational.

OpenAI’s “Unrolling the Codex agent loop” frames the agent loop as the core logic that orchestrates the user, the model, and the tools the model invokes. Inference samples the model; tool calls are executed; results return into the next prompt; the cycle continues until the model emits a terminal assistant message. That loop is harness work.

Harness engineering is the craft of making autonomous systems effective at multi-step work. It is not a formal standard; it is a durable set of engineering concerns that appear across current primary sources.

• Context management: what enters the window, how history is compacted, and how sessions resume without losing the task.
• Repository and environment legibility: structure, docs, conventions, and setup scripts that let an agent orient quickly.
• Tool access: shell, file, search, skills, and external capability surfaces available under a consistent policy model.
• Feedback loops: tests, logs, diffs, browser checks, and other signals that let the agent correct course.
• Persistence across context windows: progress files, commits, thread history, and handoff artifacts for long-running work.
• Planning and incremental progress: feature lists, plans, and session discipline that resist one-shotting or false completion.
• Observability useful to the agent: telemetry and traces that are actionable during the run, not only after the fact.
• Resource constraints: tokens, latency, runtime, cost, and other limits that shape how far a loop can go.
• Multi-step and long-running execution: the machinery that keeps useful work moving across turns and sessions.

Anthropic’s long-running harness work emphasises continuity across context windows: initializer sessions, incremental progress, clean handoff state, and explicit testing. OpenAI’s “Harness engineering” work emphasises repository legibility, tools, tests, observability, feedback loops, and environments that let coding agents perform substantial work. Both target the same engineering job: make the model’s capability usable over time.

The Model Context Protocol is an open protocol for connecting AI applications to external systems (tools, resources, and prompts) over a defined client-host-server architecture. Official MCP architecture documentation states that MCP focuses solely on the protocol for context exchange; it does not dictate how an AI application uses LLMs or manages the supplied context.

That means MCP can be part of a harness or agent system. It does not itself define:

• the agent loop;
• autonomy policy;
• sandboxing;
• memory strategy;
• governance;
• acceptance of generated changes.

OpenAI’s Codex harness documentation is explicit that tool execution may include MCP servers under a consistent policy model. That is integration, not equivalence. Calling MCP “the harness” collapses a protocol into a runtime.

Harnesses are not limited to effectiveness, and governance is not the only place security appears. Current first-party material shows substantial overlap between the two.

OpenAI’s “Unlocking the Codex harness” describes the harness as including the agent loop plus thread lifecycle and persistence, configuration and authentication, tool execution, sandboxing, MCP servers, and skills. “Running Codex safely at OpenAI” treats sandboxing and approval policy as complementary controls: the sandbox defines technical execution limits (writable paths, network reach, protected paths); approval policy decides when boundary-crossing actions stop for review. Managed configuration, network allowlists, credential storage, rules for common commands, and agent-native telemetry appear alongside the agent loop.

Anthropic’s Claude Code sandboxing work frames filesystem and network isolation as a way to reduce permission prompts while increasing safety: bounded autonomy rather than either constant approval or unrestricted host access. Later containment writing discusses capping blast radius through enforced access boundaries, and auto-mode work addresses approval fatigue with classifiers as a complement to sandboxing.

So “harness” describes the operating software around the model. Different harnesses may include substantial security and governance machinery. Effectiveness and boundary design increasingly share the same product surface.

Once a harness can make an agent effective enough to work for long periods, the remaining question is not only whether it can complete the task. It is what authority that increasingly capable process should receive.

Capability is whether the system can produce useful changes. Authority is what effects it is permitted to cause while it tries. Those questions are related but not the same. See why governed autonomous LLM work for the autonomy-versus-authority framing, and containment for how consequences can be bounded when the model is wrong.

A useful question for any autonomous system is therefore:

Under what conditions can a human delegate unattended work and still retain bounded consequences, visibility, and final acceptance?

OpenTendril’s defining problem is governed delegation rather than model effectiveness alone. OpenTendril still coordinates lifecycle, routes capabilities, and runs workers; the distinction is about the problem the system is organised around.

In OpenTendril vocabulary, reasoning remains external (the Mycorrhizal Network, the LLM). Deterministic command authority and lifecycle live in the Stem. The ephemeral worker body is a Sprout. The isolation boundary is a Terrarium. An external requester is a Pollinator carrying Pollen (identity). Observation flows through the Greenhouse. Reviewable handoff is Fruit in Git, accepted or rejected by a Botanist.

Implementation detail belongs on architecture. As harnesses improve autonomous work, the full delegated-authority contract becomes more important, not less.

Model quality can improve while authority stays bounded. Containment can hold even when the model makes a poor engineering decision. A powerful harness increases how much useful work can be delegated. Stronger autonomous capability therefore makes governance more important, not less.

If you are researching harnesses for effectiveness, the industry sources below are the right starting point. If you are researching how far that effective system may be left alone, continue to containment and governed delegation.