Agent vs Harness vs Loop: Decoding Boundaries Through a Single Execution Chain

Core Distinction: Agent, Harness, and Loop Are Not Fixed Layers

The article opens by noting that Agent, Harness, and Loop are frequently depicted as three stacked layers — Agent works, Harness manages Agent, Loop manages Harness. However, real systems from OpenAI and Anthropic show these boundaries are fluid. OpenAI describes Codex's Harness as providing the core Agent Loop and execution logic, placing Loop inside Harness. Anthropic's Managed Agents go further: Harness itself is a loop that calls the model and routes tools. Yet Loop Engineering pulls Loop outside a single Agent run, encompassing scheduled triggers, validation, retries, human takeover, and post-deployment bad-case handling. The key insight: the three terms answer different questions.

Agent is the execution subject that judges and acts toward a goal; Harness bears the runtime of that execution; Loop is the feedback relationship that observes results and decides the next step.

Walking Through a Concrete Execution Chain: T42 → R1 → C1 → E1

The author uses a familiar task — fixing a failing end-to-end test and committing once verified — to illustrate. The chain is rendered as a diagram (preserved in the source as a code block and an image):

task T42
  │ trigger
  ▼
Agent run R1
  ┌────────────── Harness ──────────────┐
  │ assemble context → call model → route tools   │
  │      ↑                     ↓          │
  │ record events ← execution result ← Sandbox   │
  └─────────────────────────────────────┘
  │ end
  ▼
candidate C1 → verifier → evidence E1
                  │
          pass ───┴────── fail / unknown
          │                     │
      deliver              update T42, start R2
                              or escalate to human

R1 is one actual run. The Agent reads the task, inspects the repo, modifies code, runs tests. Harness wires together context, model, tools, and execution environment while recording what happened. Tests inside R1 help the Agent decide the next edit; the external verifier re-runs in a clean environment to decide whether C1 can proceed. Both may use the same test command, but their weight differs: the first aids the Agent, the second produces acceptance evidence. If the test passes, acceptance evidence is generated; if it fails, the Agent iterates. Budget exhaustion, environment anomalies, or uninterpretable results pause the run, letting the outer layer decide to resume, retry, or hand off to a human.

Two loops already exist in this chain:

Inside the run: model initiates tool calls, Harness executes and feeds results back to the model (seconds to minutes).

Outside the run: verifier checks the candidate, task system decides whether to launch the next run (hours to days).

Both are called Loop, yet they read different state, hold different permissions, and stop on different conditions.

Agent: Who Acts This Time

The term "Agent" is overloaded — sometimes meaning model+tools, sometimes a whole product, sometimes an automation role. In runtime architecture, Agent run is more precise: the system gives a goal, the Agent executes once, and that execution is observable and terminable. A complete run record must answer:

Goal and inputs

Context used and tools available

Budget, timeout, and permission limits

External state mutated

Why it ended and what result it left

The model judges the next step, tools turn judgment into action, and the environment absorbs the resulting changes (code written to a worktree, browser clicks, database rows). The equation "Agent = LLM + Harness" is a useful mental shortcut but insufficient for drawing system boundaries because it does not specify state ownership, fault recovery, or who authorizes task completion.

Harness: How This Run Executes

Harness is best understood as the Agent's runtime. It assembles the capabilities a run needs and guards the boundaries that must not be crossed. Typical responsibilities:

Selecting and compressing context

Calling the model and parsing its output

Routing tools, validating parameters and permissions

Managing sandbox, workspace, and credential boundaries

Controlling budget, timeout, concurrency, and cancellation

Recording events, handling exceptions and recovery

Harness need not be a single service; desktop clients, cloud schedulers, sandboxes, and repo scripts may each handle a portion. Regardless of process decomposition, the boundary settles on four questions: what the model can see, where actions can reach, how events are persisted, and when the run ends.

OpenAI's Codex Agent Loop decomposition shows a simple main chain: user input → model → tool calls executed by Harness with results appended → model reasons again → repeat until final message. One conversation turn may span multiple model calls and tool executions. Anthropic's Managed Agents separate session (append-only event log), harness (model calls and tool routing), and sandbox (action execution environment). If the Harness process crashes, recover from session; if Sandbox fails, rebuild the execution environment — two failure modes need not be coupled.

Loop: How the Next Step Is Decided

Loop describes how feedback returns: do one step, observe the result, decide the next. This logic can live in the Harness event loop, a task scheduler, a workflow engine, a CI system, or a product backend. Placement depends on two factors: which state it reads and which actions it can trigger.

Inside R1, the Loop reads session events. After a test failure, the model reads logs, edits code, re-runs tests. It can continue calling tools but may lack permission to merge code or mark the business task complete.

At the T42 layer, the Loop reads work items, candidate versions, and acceptance evidence. It can end R1, wait for CI, then start R2. The state read and the permissions held have changed.

Further out, production bad-cases enter eval sets, driving adjustments to Harness, prompts, tools, or model configuration. This Loop mutates the system version; the immediate task finished long ago.

Whether Loop sits inside or outside Harness depends on which feedback cycle you are describing. Stuffing all feedback into one big outer box makes the diagram tidy but erases the recovery and acceptance boundaries.

Three Concurrent Rhythms

A single Agent system often runs three loops at different cadences:

Run Loop : Processing — Model decisions, tool execution, result return; Primary State — Context, session events, budget; Stop Condition — Model stops, timeout, cancellation, or Harness rules

Task Loop : Processing — Candidate persistence, external verification, re-execution; Primary State — Work item, runs, candidates, acceptance records; Stop Condition — Acceptance passed, confirmed blocked, or human takeover

Evolution Loop : Processing — Bad-case attribution, evaluation, canary, release; Primary State — Datasets, configs, baselines, versions; Stop Condition — Release gates and production results

Run Loop operates in seconds/minutes, Task Loop spans hours/days, Evolution Loop crosses versions. They trigger each other but must not share a vague done signal. R1 stopping only means the run ended; C1 passing tests only means a candidate satisfies current technical checks. Whether code is merged, deployed, and effective in live traffic requires observing later states.

Stopping Does Not Equal Completion

The article emphasizes a state progression that each step adds one auditable fact:

MODEL_STOPPED
  ↓
RUN_COMPLETED
  ↓
CANDIDATE_PERSISTED
  ↓
VERIFIED
  ↓
DELIVERED
  ↓
EFFECTIVE

Model stopping may only mean it thinks it can answer. Harness returning normally only means the run concluded cleanly. Test passing only vouches for that candidate. Merge, deploy, and real-world effect must be verified downstream. Anthropic's agent evaluations deliberately separate transcript (full trial process) from outcome (what actually happened in the environment). An agent claiming "booking succeeded" does not guarantee a booking row exists in the database; similarly, a run log saying "test fixed" does not replace the actual test result. Each layer proves only what it can.

Four Identifiers That Must Stay Linked

Returning to the opening chain, four identifiers should always travel together:

task_id     = T42  // this piece of work
run_id      = R1   // this execution
candidate_id = C1  // this result
evidence_ref = E1  // verification evidence for this result

task_id

keeps the cross-run goal stable. run_id isolates each execution's context, budget, and termination reason. candidate_id points to the code commit, artifact, or business object. evidence_ref records who verified which candidate under what conditions.

Breaking this chain causes mismatches: R2 reads R1 's stale conclusions, C2 inherits C1 's test results, the task system mistakes Harness's clean exit for acceptance, and when production fails, no one can trace which model, toolset, or config was used.

The article maps state to its natural owner:

Session : Typical Content — Messages, model outputs, tool calls, tool results; Better Holder — Harness / session store

Workspace : Typical Content — Files, code, browser pages, temp databases; Better Holder — Sandbox / worktree / external systems

Task : Typical Content — Pending, in-progress, awaiting-verification, blocked, done; Better Holder — Scheduler or business system

Acceptance : Typical Content — Test reports, deployment receipts, human approvals, live observations; Better Holder — CI, grader, release or business system

Chat context can be compressed, Harness restarted, Sandbox rebuilt. As long as task, candidate, and evidence are not all stuffed into a single volatile context, the outer Loop knows where to resume. Anthropic's separation of session, harness, and sandbox yields exactly this: logs, decisions, and execution environment can each recover independently.

Workflow vs. Loop

Workflow is often equated with fixed paths, Loop with dynamic exploration — a memorable but misleading opposition. Workflow cares about state transitions: nodes, allowed branches, error routes. Loop cares about post-feedback action: continue, retry, change strategy, or stop. A state machine can contain cycles and dynamic branches; an apparently autonomous Agent may merely retry on a fragile path. Together they clarify: Workflow draws the possible roads; Loop reads feedback and picks the next segment. At architecture time, two concrete questions remain: what evidence advances state, and who has authority to declare the end. Without those, even beautiful flowcharts produce systems that prematurely report completion or retry endlessly.

When the Outer Loop Adds Value

Peter Steinberger shifted focus from per-prompt coding agents to the outer Loop: who triggers, where state lives, how results are verified, how to recover from failure. Gergely Orosz added constraints: most teams lack infinite token budgets, and not every task warrants endless runs. He endorses a specific scenario — hard-to-fix but easy-to-verify defects, e.g., reproducible bugs with end-to-end test coverage. Combined, the conditions for a reliable outer Loop emerge:

Goal is machine-checkable or verifiable by an independent role

Every execution leaves recoverable state

Attempts, time, and cost have upper bounds

System distinguishes retry, strategy change, and human escalation

Single failure leaves no irreversible, unjudgeable side effects

Fixing flaky tests, satisfying static checks, handling rollback-safe migrations fit well. Subjective-outcome tasks or operations that can charge, broadcast, or delete data on a single call demand far more caution. Example: a publish request times out — the system received no success response and doesn't know if the remote side created content. State is UNKNOWN. If the outer Loop only knows success/failure, a naive retry may double-publish. Preserve the operation id, query the remote; if still unclear, stop. Handling "I don't know" often determines Loop reliability.

Long Tasks Do Not Necessitate Multi-Agent

Task length alone doesn't mandate multiple agents. A single run with persisted progress, clean workspace, explicit task checklist, and external verification can handle many cross-context jobs. Anthropic's early long-task experiments relied on progress files, Git history, incremental advancement, and per-item testing. Multi-agent value appears when work can be cleanly partitioned or when generation and evaluation truly need isolation. Their later long-task Harness introduced planner, generator, evaluator roles — the gain came not from role count but from giving planning, execution, and verification independent contexts and responsibilities. Each added agent introduces handoff, conflict, merge, and acceptance overhead. Before task boundaries are clear, multi-agent merely replicates the same ambiguity. The author's heuristic: first check if a single run can leave recoverable state and if results can be independently verified; agent count can be decided later.

Revisiting the Chain

Re-examining T42 → R1 → C1 → E1 grounds the three terms:

Agent judges and acts inside R1.

Harness connects model, tools, and execution environment; constrains, records, and recovers.

When results return, Loop decides where the next step goes.

A run may contain many model-tool cycles; a task may span many runs; production feedback opens a longer system evolution. They have no fixed hierarchy — boundaries arise from the state each holds, the actions each can trigger, and the evidence each accepts. The three-layer diagram is good for naming; in system design, the author cares whether task_id, run_id, candidate_id, and evidence_ref can be chained: which execution changed what, which result passed what verification, where to resume after failure, and who ultimately stops the Loop.

References

Anthropic, Scaling Managed Agents: Decoupling the brain from the hands

OpenAI, Unrolling the Codex agent loop

OpenAI, Harness engineering: leveraging Codex in an agent-first world

Anthropic, Demystifying evals for AI agents

Anthropic, Effective harnesses for long-running agents

Anthropic, Harness design for long-running application development

Anthropic, Building effective agents

Lulla et al., Loop Engineering: Building Blocks, Adoption, and Impact (arXiv:2608.21884)

Addy Osmani, Loop Engineering

Peter Steinberger on X

Gergely Orosz on X