AI Systems Atlas

Agent Harness Patterns

The harness is everything around the model: the loop, the state, the retries, the stopping rule. These fourteen plates cover the architectures that recur in almost every production agent — from a single forward pass to systems that run for days.

Index H-01 Single-shotH-02 Tool Loop / ReActH-03 Plan → ExecuteH-04 Planner → Executor → ReplannerH-05 Generator → Critic → ReviseH-06 Actor → VerifierH-07 Best-of-N / SearchH-08 Retry / Recovery LoopH-09 State Machine AgentH-10 Hierarchical AgentH-11 Parallel SwarmH-12 Human-in-the-loopH-13 Event-driven AgentH-14 Long-running Agent

When to reach for what

H-01Single-shot

/harnesses/single-shot

One prompt in, one completion out. No loop, no tools, no feedback.

Key insight

Still the right architecture for a surprising number of tasks. Every pattern below should have to justify its complexity against this baseline.

Failure mode

No recovery path: if the first answer is wrong, the system is wrong.

RelatedReAct loopBest-of-N

H-02Tool Loop / ReAct

/harnesses/react

The model alternates reasoning with tool calls, folding each observation back into context until it can answer.

Key insight

The loop converts a static predictor into something that can gather its own evidence. Nearly every modern agent is a descendant of this cycle.

Failure mode

Unbounded loops: without a step budget and a stopping rule, an agent that cannot solve the task will happily keep observing forever.

RelatedPlan → ExecuteActor–VerifierCoding loop

H-03Plan → Execute

/harnesses/plan-execute

Plan the whole task up front, then run the steps without further deliberation.

Key insight

Separating planning from execution makes runs cheap, auditable and parallelizable — you can review the plan before anything happens.

Failure mode

The plan is frozen at the moment of least information. Anything the planner didn’t anticipate breaks the run.

RelatedReplannerReAct loop

H-04Planner → Executor → Replanner

/harnesses/replanner

A plan is executed step by step, and rewritten whenever the environment disagrees with it.

Key insight

Treat the plan as mutable state, not scripture. The interesting engineering is in what evidence triggers a revision.

Failure mode

Thrash: a replanner that revises on every hiccup never finishes; one that revises too rarely is just Plan → Execute with extra cost.

RelatedPlan → ExecuteRetry loop

H-05Generator → Critic → Revise

/harnesses/generator-critic

One role produces a draft; a separate role critiques it; the draft is revised against the critique.

Key insight

Models are better at spotting flaws in text than at avoiding them while writing. Splitting the roles exploits that asymmetry.

Failure mode

Sycophantic critique: if generator and critic share a model and a prompt style, the critic tends to approve whatever it would have written.

RelatedActor–VerifierLLM-as-judge

H-06Actor → Verifier

/harnesses/actor-verifier

One agent performs the task; another independently checks whether it actually succeeded.

Key insight

Separating execution from verification is the single most reliable upgrade to an agent loop — especially when the verifier is grounded in tests, builds or other hard checks.

Failure mode

Shared blind spots: if both roles miss the same class of error, verification adds latency and false confidence, not reliability.

RelatedGenerator–CriticCoding loopOutcome evals

H-07Best-of-N / Search

/harnesses/best-of-n

Sample several independent attempts in parallel and keep the one a judge scores highest.

Key insight

When attempts are cheap and judging is easier than generating, N tries plus a selector beats one careful try.

Failure mode

The judge is the ceiling: if it can’t tell good from bad, you pay N× inference to select noise.

RelatedParallel swarmLLM-as-judge

H-08Retry / Recovery Loop

/harnesses/retry-loop

On failure, classify what kind of failure it was — and only then decide how to retry.

Key insight

The classification step is the whole pattern. Transient errors want patience; systematic errors want a different strategy.

Failure mode

Blind retries: re-running the identical attempt against a deterministic failure just multiplies cost by the retry budget.

RelatedReplannerActor–Verifier

H-09State Machine Agent

/harnesses/state-machine

The agent’s lifecycle is an explicit state machine; the model acts within states, the harness owns the transitions.

Key insight

Explicit states make agents debuggable, resumable and observable — you can always answer “what is it doing right now?”

Failure mode

States that don’t match reality: work that spans two states, or a “waiting” that never fires, forces the model to fight the harness.

RelatedEvent-driven agentLong-running agent

H-10Hierarchical Agent

/harnesses/hierarchical

A manager agent decomposes the goal and delegates to specialized workers, integrating their reports.

Key insight

The hierarchy is really a context architecture: each level compresses detail before passing it up, so no single context holds everything.

Failure mode

Compression loss: every report is a lossy summary. Critical detail dies in the middle of the org chart, same as in human ones.

RelatedParallel swarmMulti-agent coding

H-11Parallel Swarm

/harnesses/parallel-swarm

Shard a partitionable task across independent agents and merge the results at one aggregation point.

Key insight

Wall-clock time collapses to the slowest shard — but only for tasks that genuinely decompose without shared state.

Failure mode

Hidden coupling: if shards secretly depend on each other, the aggregation step inherits every inconsistency at once.

RelatedHierarchicalBest-of-N

H-12Human-in-the-loop

/harnesses/human-in-the-loop

The agent proposes; a gate routes risky actions to a human who approves or denies before execution.

Key insight

Put the human at the decision, not in the loop’s hot path: gate on irreversibility and blast radius, and let everything else flow.

Failure mode

Approval fatigue: gate too much and humans rubber-stamp; the checkpoint remains, the checking stops.

RelatedAgent securityEvent-driven agent

H-13Event-driven Agent

/harnesses/event-driven

The agent sleeps until an external event wakes it; its first decision is whether the event matters at all.

Key insight

Inverting control — the world calls the agent — is what makes always-on agents affordable and non-annoying.

Failure mode

Event storms: without dedupe and rate limits, a burst of correlated events becomes a burst of correlated, conflicting agent actions.

RelatedLong-running agentCI feedback loop

H-14Long-running Agent

/harnesses/long-running

Work in bounded bursts, checkpoint durable state, sleep, and resume — for goals that outlive any single session.

Key insight

The context window is not the state. Anything that must survive lives in the checkpoint; the window is just a working set.

Failure mode

Checkpoint drift: if the saved state and the real world diverge while the agent sleeps, it resumes confidently into a world that no longer exists.

RelatedState machineContext compactionCheckpointing

Elsewhere in the atlas

Security →Evals →Context →Coding Agents →