Agent harnesses: turning model decisions into running tasks

The same model can offer advice in a chat window and read files or check artifacts inside a development tool. Software around it connects decisions to an environment and manages the task. That surrounding execution layer is often called a harness.

For a research task, the model suggests what to investigate next; the harness makes that step run and manages execution. It needs working ways to access sources, save a draft and record where work stopped. Suggestions alone cannot deliver a file.

The term has no universal module checklist. Check what a particular author includes before comparing implementations.

Loop, graph and harness can coexist

This article treats the harness as software supporting agent execution. In its Managed Agents architecture, Anthropic separates the harness that calls the model and dispatches tools from the session history and execution sandbox. Other discussions use a broader boundary.

For learning, distinguish the questions being answered:

Concept	Main question
Loop	How do model and tool calls repeat and stop?
Graph	Which node runs for this state, and where does it go next?
Harness	Where do actions run, what may they do, and what survives failure?

They are not competing frameworks. A harness can run a loop or a branching graph, and a graph node can contain its own loop.

List the dependencies of “save a research note”

Suppose the task is to read supplied material and create notes/agent-runtime.md. Before execution, establish:

• Which tools exist and what their results mean.
• Which workspace and output paths the task uses.
• Whether permission covers a draft or also publication.
• What happens when a tool hangs, the process exits or the allowance runs out.
• What evidence will establish completion.

These contracts live in executors, registries, configuration and records as well as prompts. An instruction to edit only a particular directory does not itself enforce filesystem isolation.

This is a custom teaching manifest, not a configuration accepted by a specific product:

{
  "runId": "research-042",
  "workspace": "/workspace/research-042",
  "allowedTools": ["read_source", "save_note"],
  "outputPath": "notes/agent-runtime.md",
  "limits": {"modelCalls": 12, "toolCalls": 20},
  "completionChecks": ["file_exists", "required_sections", "source_support"]
}

The numbers illustrate limits, not universal recommendations. Enforcement requires implementation: normalize output paths, account for symlinks and verify the destination remains inside the allowed directory. A string prefix check alone is insufficient.

Leave a record another run can use

After an interruption, “keep going” conveys little. A resumed run needs the goal, completed operations, artifact locations, open questions and next step.

Goal: prepare and save a draft; do not publish
Done: read two sources; saved notes/agent-runtime.md
Verified: file exists and contains Loop and Graph sections
Unverified: whether the third section's citation supports its claim
Next: check that citation, then run complete acceptance checks

This original handoff example distinguishes work from verification. Inspect the actual file on resumption: a person could have changed it, or the previous write might not have completed.

Anthropic’s long-running harness experiment describes environment initialization, incremental work and artifacts connecting sessions. It is a useful reference, not evidence that a progress file guarantees recovery for every task.

Recovery must account for uncertain writes

A save may succeed while its response is lost. Recording only “failed, retry” can create duplicates; recording “completed” can hide a genuinely missing write.

Retain an operation identifier, an input digest and an explicit unknown outcome. Check the artifact or server-side status before proceeding. Tool retry contracts cover the receiving system’s role. A harness coordinates these steps without removing external-system limitations.

Here, idempotency means that repeating the same logical operation does not duplicate its business effect. Resending a request to save one draft should not unexpectedly create a second note. The receiving system must help enforce that behavior.

Start with the mechanisms the task needs

A first experiment can use one workspace, one read-only tool, a bounded loop and an execution log. Add cross-process recovery, concurrency or external-write handling when those requirements become concrete.

Try terminating the process after saving a draft, then restarting from its handoff. Can the new run locate the same draft and identify unverified work, instead of starting over or declaring success? That tests more than the length of its tool list.

Continue with context, state and memory and outcome evaluation.