Harness, Loop, and Graph Engineering: The Real Design Problem Is Uncertainty

Agent engineering has acquired three new labels: harness engineering, loop engineering, and graph engineering. They can sound like a succession of fashions—first prompts, then harnesses, then loops, then graphs. These remain fast-moving practitioner terms rather than standardized disciplines.

The useful interpretation is not a maturity ladder but three orthogonal control surfaces. A harness controls the agent's working world. A loop controls feedback over time. A graph controls the topology between pieces of work. Any serious agent system must answer all three sets of questions, whether or not it uses frameworks carrying those names.

This distinction matters because the practical unit of agent engineering is no longer the prompt. It is a controlled system. The model makes local judgments; the surrounding system decides what the model can see and change, how failure becomes evidence, when execution continues, and which boundaries return control to deterministic code or a person.

Compressed into three questions: what can the agent see, do, retain, and prove? How does it use consequences to correct itself and stop? Which paths may branch, run in parallel, retry, or converge? Those are the harness, loop, and graph questions respectively.

A harness defines the working world. In OpenAI's February 2026 account of building Codex with Codex, the limiting factor was often not code generation. The environment was underspecified: tools were missing, repository structure was hard for agents to read, and important constraints existed only in human memory. Engineering shifted toward designing environments, expressing intent, and building feedback.

A harness is therefore more than a CLI wrapper or a longer system prompt. It includes the workspace, tools, permissions and sandbox, repository instructions, searchable documentation, durable state, context handoffs, logs, and the feedback emitted by tests and linters. It determines what kind of world the agent enters and whether that world can explain success and failure.

A good harness makes the repository agent-legible. Architectural boundaries should become executable through types, tests, static checks, and useful remediation messages wherever possible. Stronger models increase the value of this work: they can travel farther on their own, which also means they can amplify an unclear assumption across a larger blast radius.

But a harness does not solve time. An agent can have excellent tools, complete context, and carefully scoped permissions, yet still make one attempt and confidently stop. The harness enables work; it does not by itself guarantee recovery, convergence, or a sensible stopping point.

A loop governs feedback over time. Its smallest form is goal, action, observation, adjustment, and a decision to continue or finish. ReAct demonstrated the value of interleaving reasoning, action, and environmental observation in 2022. What is now called loop engineering turns that pattern into an operational execution policy.

A production loop is not `while true` around a prompt. It needs explicit state, recoverable checkpoints, failure classification, retry budgets, context management, evaluators, escalation paths, and termination rules. Most importantly, each pass must consume fresh evidence from the previous one. Repetition without new evidence does not converge; it only hardens the original mistake.

The run model in modern agent SDKs makes the distinction concrete: a final answer ends the loop; a tool request is executed and its result returns to the model; a handoff changes the active agent and input; a turn limit forces termination. IBM's July 2026 framing adds the wider operating surface—scheduling, hooks, context, tools, workspaces, and human oversight.

A weak harness turns persistence into automated error. If the test command is wrong, the verifier reads stale artifacts, or tools have excessive permissions, ten more rounds do not create reliability. Persistence without an evidence threshold is not autonomy. It is loss of control.

A graph controls coordination topology. It makes state, work units, and transitions explicit. A node may be deterministic code, a model call, a tool, a human approval, or a complete agent with its own harness and loop. Edges may be fixed, conditional, dynamically generated, parallel, or cyclic.

The value of a graph is not the diagram. It is the ability to encode structure that should not be improvised by the model: which compliance path follows classification, which research branches may fan out, when retries must escalate, and who approves a payment, publication, or merge. Explicit topology improves observability, recovery, and auditability.

More graph is not automatically more advanced. Anthropic recommends starting with the simplest approach that meets the need because agency adds latency and cost. LangChain's 2026 retrospective gives an even sharper example: it tried to force open-ended deep research into predefined paths, then moved back toward a more agentic harness. Open exploration needs discretion inside nodes; regulated work needs firmer edges.

The overlap is now easier to see. A loop is a cyclic graph in topological terms, but loop engineering asks whether feedback is fresh, state recoverable, and stop conditions sound. Graph engineering asks how work may move between nodes. One graph can host many loops, while one node can be a fully harnessed agent. These are lenses at different scales, not competing stacks.

Their failure modes are equally distinct. Harness without loop produces a capable one-shot worker that still needs repeated human prompting. Loop without harness repeats unreliable actions at machine speed. Graph without dependable nodes produces orchestration theatre: an elegant diagram connecting unpredictable black boxes.

Start with the uncertainty in the task. For open-ended, one-off exploration, strengthen the harness and keep the graph light. For repeated work with objective checks, engineer the loop. For branching, parallel, multi-role, or regulated processes, make the graph explicit. Mature high-risk systems often need all three, but they do not need to begin with the heaviest version of each.

Consider an AI coding system. Intake, repository exploration, implementation, testing, review, human approval, and merge can form an outer graph. Implementation and testing form a loop that reacts to failure evidence. Each coding agent operates inside a harness made of repository rules, tool permissions, a sandbox, test commands, and commit constraints. This architecture requires three answers, not necessarily three frameworks or multiple agents.

The deeper common purpose is to decide where uncertainty belongs. Ambiguous requirements, exploration, and solution generation can leave room for model judgment. Permission changes, deletion, payments, deployment, and merge boundaries should be controlled by deterministic rules, fresh evidence, and explicit human authority. The most reliable system is not autonomous everywhere; it places freedom and constraint accurately.

That changes the human role as well. People should not stand outside every loop pressing Continue, nor wait at the end for an opaque result. Human judgment belongs at goal definition, evidence standards, exception escalation, and irreversible transitions. The scarcer that judgment is, the more deliberately it should be placed.

Use these three labels, then, as design questions rather than identities. Harness engineering makes the environment actionable and verifiable. Loop engineering turns repetition into convergence. Graph engineering turns hidden workflow into explicit structure. The enduring advantage will not belong to the team with the newest vocabulary, but to the team that can organize model uncertainty into repeatable, recoverable, auditable outcomes.