Overview

Harness Engineering is defined in the basics chapter: the system outside the model that provides context, tools, constraints, verification, and correction, and determines whether an agent can move from a working demo to a reliable product.

This page does not redefine the harness. It asks the next practical question: as tasks get longer, state gets richer, and failure modes get more complicated, how should a harness evolve from a control loop into a maintainable system?

Anthropic’s engineering essays from 2024 to 2026 give a useful progression:

  1. First decide whether you need an agent at all.
  2. If the control flow is predictable, prefer a workflow.
  3. Move to an autonomous agent only when the task needs the model to choose the next step itself.
  4. When work spans context windows, agents, or execution environments, the harness itself needs handoff, evaluation, recovery, and replacement mechanisms.

The value of this progression is not that every system should use the same architecture. It is the reminder that each additional layer of autonomy requires a matching layer of engineering constraint.

From Patterns To Infrastructure

Early agent design focused on how the model acts: give it tools, let it observe results, and let it decide what to do next. At this stage, the most important choice is the pattern. Many tasks should stay as simple model calls or workflows instead of being turned into agents prematurely.

Long-running tasks shift the question to how the model resumes work. Context windows fill up, agents restart, environments change, and the next run needs to know what has been done, which assumptions still hold, and which tests prove that progress is real.

Multi-agent harnesses push the question further. Complex application development is not just “write code”; it includes spec decomposition, subjective quality judgment, implementation checks, and iteration. Asking the same agent to generate and evaluate its own work often amplifies confirmation bias, so planner, generator, and evaluator responsibilities need to be separated.

Managed Agents finally lift the perspective from “how should this harness be written?” to “what stable interfaces should an agent platform expose?” If session, harness, and sandbox are bundled together, it is hard to replace models, migrate execution environments, or recover from harness failure. Once brain, hands, and session state are decoupled, the harness can become replaceable infrastructure instead of a single system that must be carefully preserved.

The Four Questions

PageCore QuestionWhat To Take Away
Building Effective AgentsWhen should you use a normal LLM call, a workflow, or an autonomous agent?The complexity ladder: start with the simplest solution and use agents only when the task needs model-driven decisions.
Long-Running HandoffsHow can an agent keep working across multiple context windows?Use initializer / coding agents, feature lists, progress files, git history, and tests to create reliable handoff.
Multi-Agent ArchitectureHow should generation, evaluation, and planning be separated in complex app development?Give different agents different judgments, especially instead of asking the generator to judge its own output alone.
Managed AgentsWhen the harness itself can fail or go stale, how should platform interfaces be designed?Decouple brain, hands, and state through Session / Harness / Sandbox so the system can recover, scale, and replace parts independently.

Choosing The Right Complexity

Use task uncertainty to choose the harness shape.

If the steps are clear and the output is easy to verify, you usually do not need an agent. A single model call, structured output, and simple validation are enough.

If the task has multiple steps but the path can be written down ahead of time, use a workflow. Prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer all fit here. The key is to keep control flow in code instead of handing it to the model too early.

If the task requires the model to choose the next step based on feedback during execution, use an autonomous agent. At that point the harness is no longer just “tool calling”; it also needs stopping conditions, permission boundaries, traceability, error recovery, and human takeover points.

If the task runs for a long time, crosses context windows, or spans multiple runs, it needs a long-running harness. Context management is no longer just truncation and compaction. Task state has to be written into recoverable external records so the next agent can resume reliably.

If the task contains different kinds of judgment, such as product specs, visual quality, code correctness, and user experience, consider a multi-agent harness. The reason to split agents is not that “more agents is better”; it is that different judgment standards need different context and different failure paths.

If you need to run many agents at scale, or allow models, execution environments, and harness implementations to be replaced independently, you are in Managed Agents territory. The most important design object becomes the stable interface, not the prompt trick inside one run.

Core Judgments

Complexity needs cost discipline. Multi-agent systems, long-running execution, and managed infrastructure all make debugging harder. A complex harness is worth introducing only when the task’s uncertainty exceeds what a simple workflow can carry.

Context is a handoff mechanism, not just window content. The main risk in long-running work is not that the context window is too short; it is the lack of a reliable record explaining why the task reached its current state. Compression, memory, and context lifecycle are covered in the Context section.

Evaluation needs independence. For complex artifacts, the evaluator needs its own criteria, evidence, and failure exit. Otherwise evaluation easily becomes a rationalization layer for the generated output.

State belongs somewhere recoverable. Agent loops and sandboxes should be killable, restartable, and replaceable. User intent, tool results, progress records, and session events need to live in a durable session.

Harnesses go stale as models improve. Every harness component encodes an assumption about model capability. As models improve, decomposition, resets, limits, or checks that used to be necessary can become drag. Revisit whether those components are still load-bearing whenever the model changes.

Reading Order

Read in publication order, because it mirrors the expanding problem size:

  1. Building Effective Agents
  2. Long-Running Handoffs
  3. Multi-Agent Architecture
  4. Managed Agents

If you are designing a specific system, you can also work backward from the problem: first check whether you truly need an autonomous agent, then ask whether the work is long-running, whether it needs multi-agent evaluation, and whether it has reached the platform or managed-agent stage.

Sources

Was this page helpful?
Edit on GitHub