The agent harness is the new framework: how to make coding agents reliable

The most important question about a coding agent is no longer “which prompt should we use?” It is “what happens around the model while it works?”

A strong model can inspect a repository, edit files, run commands, and recover from some mistakes. None of that guarantees a useful result. Give the same model a vague goal, an unrestricted shell, no durable state, and no independent check, and its performance will vary wildly. Put it inside a well-designed operating environment and the work becomes easier to repeat, review, and trust.

That operating environment is the agent harness: the code, tools, instructions, state, boundaries, and feedback loops that turn model capability into an engineering process.

The model is only one component

Teams often evaluate coding agents as if they were testing a smarter autocomplete. They compare models, rewrite prompts, and look at whether the first patch appears correct. That view misses most of the system.

An agent does not produce a patch in isolation. It discovers files, interprets repository rules, chooses tools, changes state, reacts to test output, and decides when to stop. Each step is shaped by the harness. A better model may improve the decisions, but it cannot compensate reliably for missing context, ambiguous permissions, broken tests, or an environment that forgets what happened between sessions.

This is why harness design has become a visible part of the current agentic-coding race. Anthropic’s work on long-running application development describes a planner, generator, and evaluator supported by structured artifacts. OpenAI presents the Codex app as a command center for parallel agents with isolated worktrees, skills, and automations. Google’s Antigravity platform similarly combines managed agents with persistent isolated environments and reusable instructions.

The products differ, but the direction is consistent: reliability comes from the system around the model.

Prompts do not carry enough structure

A prompt is useful for intent. It can describe the desired behavior, constraints, and acceptance criteria. It is a poor place to hold the entire operating state of a long task.

As work expands, a single conversation accumulates discoveries, failed approaches, test results, and decisions. Important facts compete for attention. Context may be summarized or truncated. A later session may need to reconstruct why a particular trade-off was made. Repeating a larger prompt does not solve this; it mixes durable project knowledge with temporary execution history.

A harness separates these concerns:

Instructions define stable repository rules and working conventions.
A task specification defines the current goal and observable acceptance criteria.
Artifacts record plans, decisions, progress, and unresolved questions.
The environment exposes only the tools and resources needed for the task.
Verification decides whether the result satisfies the specification.

The prompt starts the work. The harness keeps it coherent.

Decompose work before multiplying agents

Parallel agents are attractive because they can compress elapsed time. They can also produce several incompatible solutions at once.

The useful unit of delegation is not “work on the application.” It is a bounded task with a clear owner, input, output, and stopping condition. Good parallel tasks have limited overlap: one agent can investigate an API change while another reproduces a UI bug, or separate agents can implement independent packages. Tasks that edit the same module or depend on an unsettled architecture should usually remain sequential.

The planner’s job is therefore not to generate a long checklist. It is to identify dependency boundaries and define what evidence will prove each step complete. Before another agent starts, it should know:

which files and systems are in scope;
which behavior must change and which must remain stable;
what tests or observations demonstrate success;
what it may modify without further approval;
what result it must hand back to the next stage.

This structure matters more than the number of agents. Two well-separated tasks usually outperform five agents competing for the same context and files.

Treat artifacts as durable memory

Long-running work needs memory outside the conversation. The simplest useful form is not a vector database or an elaborate knowledge graph. It is a small set of versioned, human-readable artifacts.

A task plan can record completed and pending steps. A decision note can capture why an approach was selected. A test report can distinguish verified behavior from assumptions. A handoff can name changed files, remaining risks, and the exact next action.

These artifacts solve two problems at once. They let another agent resume without replaying the full transcript, and they give humans a compact surface for review. They also make failures diagnosable. If an agent repeats work, skips a constraint, or stops early, the team can inspect the state it received instead of guessing what the model “understood.”

Keep the format boring. Markdown, JSON, and normal Git history are often enough. Durable memory is valuable because it is explicit and inspectable, not because it is sophisticated.

Separate generation from evaluation

An agent that produced a change is naturally biased toward the path it already took. Asking it “are you sure?” may trigger another pass, but it does not create independent evidence.

A stronger harness separates the builder from the checker. The builder implements the scoped change. The evaluator receives the specification, the resulting diff, and the verification output. Its job is to find mismatches, not to defend the implementation.

The evaluator should rely on observable checks wherever possible:

run focused tests and the relevant broader suite;
type-check and build the application;
inspect the final diff for unrelated changes;
render or exercise user-facing behavior;
compare API or schema changes with their consumers;
confirm that every acceptance criterion has evidence.

Evaluation does not always require a second model. Compilers, tests, linters, screenshots, database constraints, and policy checks are often better judges. Use model-based review for ambiguity and judgment; use deterministic tools for facts they can establish directly.

Autonomy needs boundaries, not constant clicking

Permission prompts can make an agent feel safe while teaching the user to approve everything. Once approvals become routine, they stop functioning as meaningful review.

The alternative is not unrestricted access. A reliable harness assigns permissions according to risk. Reading repository files and running local tests may be allowed automatically. Writing within an isolated worktree may be allowed but logged. Network access, credential use, deployment, destructive commands, and external messages should have narrower rules or require explicit approval.

Isolation reduces the cost of mistakes. Worktrees keep parallel edits apart. Sandboxes limit filesystem and network reach. Short-lived credentials reduce exposure. Budgets and turn limits stop runaway tasks. Audit trails make actions reviewable after the fact.

OpenAI’s account of running Codex safely emphasizes sandboxing, approvals, network controls, identity, and telemetry as complementary layers. Anthropic’s discussion of Claude Code auto mode reaches a similar conclusion from another angle: autonomy works best when low-risk actions flow while suspicious actions are classified, blocked, or escalated.

The goal is not zero friction. It is friction placed where human judgment changes the outcome.

Build the smallest harness that closes the loop

Teams do not need a multi-agent platform before they can benefit from harness thinking. A useful first version can be built around one agent and an ordinary repository:

Write a bounded task with explicit acceptance criteria.
Give the agent repository instructions and a clean, isolated branch or worktree.
Require a short plan before edits begin.
Persist progress and decisions in files or task state, not only in chat.
Run focused checks after each meaningful change.
Run an independent final review against the specification and diff.
Escalate actions that cross predefined security or product boundaries.

Measure the result with operational questions. How often does work pass verification on the first handoff? How much unrelated code changes? How frequently does a human need to redirect the task? Can another session resume from the recorded state? Which permission requests lead to an actual rejection?

Those signals reveal where the harness is weak. More prompt text may hide the symptom for one run; better task boundaries, state, tools, or evaluation improve the system for every run.

Reliability is an architectural property

Coding models will continue to improve, and model choice still matters. But production engineering has never depended on a compiler alone. It depends on source control, tests, environments, review, observability, and release controls. Agentic engineering is converging on the same lesson.

The model supplies reasoning and execution. The harness supplies continuity, limits, evidence, and accountability. Once those responsibilities are designed explicitly, a coding agent stops being an impressive demo and starts becoming a dependable part of the development system.