Skip to specification
harnessarch

Harness

Sub-agents

Bounded loops with a narrower job, narrower context, narrower tools. One explores, one reviews, one verifies — and the orchestrator integrates the results.

Sub-agents let the harness split work into bounded loops. Instead of one agent with one crowded context doing everything serially, you get specialists: one explores the codebase, one reviews the diff, one verifies sources — while the main agent keeps responsibility for integrating the results.

MAIN AGENTkeeps context · integrates resultsEXPLOREmap the codebasenarrower context · narrower toolsread · grepREVIEWaudit the diffnarrower context · narrower toolsread · lintVERIFYcheck the claimsnarrower context · narrower toolstest · browseresults integrate back — in parallel, without crowding the main context
Fan out to bounded specialists; integrate the results. Each worker reasons over a fraction of the surface area.

A sub-agent is not just more model

The primitive here is the capability to fire off a branch with clean, narrow context — a model with:

  • a narrower job — "review this diff for security issues," not "help with the project"
  • a narrower context — only what that job needs, not the whole session's history
  • often narrower tools — a read-only explorer doesn't get write access

That's why the word is specialist. The harness is doing attention management by delegation: don't worry about everything — worry about this, with these tools, and report back. The main agent's window stays clean, and the branches run in parallel instead of serially.

In the wild

Two patterns cover most of the territory (both formalized in OpenAI's Agents SDK, and present in every serious harness):

  • Agents as tools — the manager stays in control and calls specialists the way it calls any tool, integrating their outputs
  • Handoff — the active conversation itself moves to a specialist, which takes over

Claude Code's Task/Agent tool, background subagents, and explore-plan-review agent types are all this primitive.

The wiring gets its own name

Fan out and integrate is one shape. It is not the only one. Add a reviewer that can send work back, a branch that only runs when a condition holds, a step that must wait for two others — and the wiring between the specialists stops being incidental. It becomes the thing you design.

In mid-2026 the field gave that design job a name. Aishwarya Srinivasan — whose essay this movement stands on — places it at the end of a lineage this site's readers will recognise: "prompt engineering, context engineering, loop engineering, harness engineering, and now graph engineering." Each term in the ladder names where the design effort moved next. Her definition of the new rung: "wiring multiple specialized agents or steps into a graph: nodes that do the work, edges that route between them, and shared state flowing along those edges, for when a single agent running one loop is not enough."

Strip the framework away and three parts remain, each one a decision:

  • Nodes — "functions," in her phrasing. Each "takes the current state, does some work (an LLM call, a tool call, a retrieval, a decision), and returns an update to the state." A node is the specialist from the top of this sheet: a bounded loop with a narrower job.
  • Edges — the routing. "A normal edge says 'after node A, go to node B.' A conditional edge inspects the state and decides where to go next." The conditional ones are where the graph earns its keep.
  • State — "a shared data structure, usually a typed dict or a Pydantic model, that captures everything persisting across the run." Not a transcript — a record with a shape.
taskinRESEARCHgather · take notesWRITEdraft from notesREVIEWjudge the draftpass?reads stateoutnotesdraftverdictyesno — reviseSHARED STATE{ task · notes · draft · verdicts }every node reads it, works, writes an update back
The canonical graph, and every edge type it takes to read one. Plain edges carry work forward; the diamond inspects state and chooses; the dashed edge is a cycle with a purpose — the verdict rides back to the writer inside the state. Collapse this picture to one node with an edge back to itself and you have the single-agent loop.

What the vocabulary buys is legibility. "Instead of one agent with nested conditionals," Srinivasan writes, "you declare a network of nodes, each doing a specialized job, with edges that explicitly wire how control and state move between them." The routing that used to live in a prompt — if the review fails, try again — becomes a drawn edge. When a run goes wrong, the path it took is a fact you can read, not a branch buried in an instruction.

The last clause of her definition is the guardrail, and it is worth reading twice: for when a single agent running one loop is not enough. A graph is not the upgrade path for every task. Wiring five specialists to do one specialist's job adds interfaces without adding capacity — and a graph multiplies whatever its loops already are, the bad ones included.

Two graphs, one word

Same word, two different objects — and most arguments about the term are two people holding one each. The knowledge kind lives on this site's memory pillar: entities and relationships are semantic memory wearing a data structure. The execution kind is this sheet and the one before it — orchestration owns how work moves; sub-agents own who it moves between. The two can share an architecture. They never answer the same question.

Delegation creates a new problem

It feels faster — until everyone comes back with a different interpretation of the job. If every sub-agent invents its own process for "review a PR" or "verify a source," you get parallel inconsistency: five workers, five methodologies, five formats.

Specialists need procedures. Reusable know-how, loaded at the moment the task matches — so that every agent given the same job does it the same way.