Harness, loop and graph engineering: what they are and when you need each

Three new terms spread through AI engineering in 2026. Harness engineering shapes one agent run, loop engineering keeps an agent working without you, and graph engineering organises many agents into a system. Here is what each means, where it came from, and which one to invest in first.

Over the past few years the focus of AI engineering moved from prompts to context, and in 2026 to three newer words: harness, loop and graph. If you read agent blogs in 2026 you have seen all three, often used loosely and sometimes as if they were rivals. They are not rivals. They are layers, and each one answers a different question.

The short answer

Harness engineering answers "What does one agent run inside?" The tools, context, rules, checks and limits around the model for a single piece of work.
Loop engineering answers "Who prompts the agent?" Instead of you typing the next prompt, a system triggers the agent, checks its output and feeds the result back until a goal is met.
Graph engineering answers "How do many steps and agents fit together?" An explicit structure of nodes (agents, tools, checks, humans) and the allowed paths between them.

A recent survey paper sums up the stack in one line: an individual agent is a loop around a foundation model plus a harness, and graph engineering organises many of those into a system (Feng et al., 2026).

Each agent is a model inside a harness, driven by a loop. A graph decides how many of them, plus checks and people, work together.

Where the terms came from

These words spread fast in 2026, mostly in this order. Many of the practices are older than the names.

February 2026, harness engineering. The term was popularised by an OpenAI post describing an internal beta of a product built over about five months with no hand-written code: roughly a million lines and 1,500 merged pull requests from a team of three to seven engineers. The engineers' job became to "design environments, specify intent, and build feedback loops" (OpenAI).
June 2026, loop engineering. Addy Osmani described the next step as "replacing yourself as the person who prompts the agent", one floor above the harness (Osmani, The New Stack).
July to August 2026, graph engineering. A practitioner guide framed it as representing an AI application as an executable graph (Analytics Vidhya), and a survey paper placed it as the layer that turns individual agents into "system intelligence" (arXiv).

None of these is a standard with a spec. They are names for practices, so expect the edges to stay blurry.

Harness engineering

A harness is everything around the model for one run of work. A useful mental model is agent = model + harness: the model reasons, the harness makes that reasoning safe and useful to act on.

What goes into a harness:

Tools: what the agent can call, with clear descriptions and errors it can recover from. Often exposed through MCP.
Context: what the agent can read. OpenAI's lesson was to give the agent "a map, not a 1,000-page instruction manual": a short AGENTS.md that points to structured docs in the repo.
Constraints: linters, structural tests and architecture rules that fail fast. OpenAI wrote its lint errors to include the fix, so the agent can correct itself.
Verification: tests, checks and a final review step before the agent declares it is done.
Guardrails: sandboxes, permissions, budgets and human approval for risky actions.
Observability: traces and logs of what the agent saw and did.

The clearest evidence that harnesses matter comes from LangChain. Its coding agent went from just outside the top 30 to the top 5 on Terminal Bench 2.0, from 52.8% to 66.5%, with the model (gpt-5.2-codex) held fixed. In their words: "We only changed the harness." The changes were ordinary. They included a forced verification pass before the agent exits, startup context about the directory and tools, time-budget warnings, a nudge to rethink after editing the same file too often, and more reasoning effort for planning and verification than for implementation (LangChain).

You need harness engineering as soon as an agent does real work. In client projects this is where most of the effort goes: the copilot is only as good as its tools, the docs it can see and the checks that stop it from guessing.

Loop engineering

A loop removes you from the middle. Instead of prompting, reading, and prompting again, you design a system that does it: something triggers the agent, the agent works, something checks the result, and the outcome feeds the next round until a goal is met or a limit is hit.

The building blocks Osmani lists are now common across coding agents such as Claude Code and Codex:

Triggers and automations: schedules or events that start work, for example a nightly triage of new issues.
Isolation: separate worktrees or sandboxes so parallel runs don't trample each other.
Skills: written project knowledge the agent reuses.
Connectors: access to your existing tools.
Sub-agents as verifiers: one agent proposes, another checks. A model grading its own work is too generous.
State: a file or board that records what is done and what is next, so the loop does not repeat itself.

Loops add risks the harness alone does not have. Every round costs tokens, so set a budget and a stop condition. Unattended loops make mistakes unattended, so treat "done" as a claim to verify, not proof. And Osmani's warning about comprehension debt is worth repeating: the faster a loop ships work you did not read, the less you understand your own system.

You need loop engineering when you notice yourself giving an agent the same kind of prompt again and again: triaging, fixing failing tests, refreshing a report. This site is a small example. A scheduled agent runs every morning, researches updates, checks them against a second source and commits them, with a schema check before anything is published.

Graph engineering

In a single-agent loop, most decisions are hidden inside the model's context: when to search, when evidence is enough, when to stop. Graph engineering moves those decisions into an explicit structure you can read, test and audit.

Nodes are units of work: an agent, a tool, a plain function, an evaluator, or a human decision.
Edges are the allowed paths: dependencies, hand-offs, delegation, verification and approval.
Common shapes are chains (step after step), routing (a coordinator picks who handles what) and fan-out, fan-in (parallel work that is merged at the end).
State lives in the graph, so a run can be paused, resumed, inspected and recovered after a failure.

A concrete example: research, then draft, then score how well the draft is grounded. If the score is below a threshold, go back to research; allow at most two revisions; send anything high-risk to a human; otherwise publish. Each rule is an edge you can see and test, not a hope inside a prompt. Not every node needs an LLM either. Checking an invoice against an approval limit is a plain function.

Frameworks built for this include LangGraph, Google's ADK and Microsoft's Agent Framework. Plain code or an existing workflow engine is fine when most steps are deterministic. Note that graph engineering is about workflow graphs. It does not require a knowledge graph or GraphRAG.

You need graph engineering when the process matters as much as the answer: several agents or teams, human approvals, compliance rules, long-running work that must survive failures, or anything an auditor will ask about.

Side by side

	Harness engineering	Loop engineering	Graph engineering
Question it answers	What does one agent run inside?	Who prompts the agent?	How do many steps and agents fit together?
Unit you design	A single agent run	A repeating cycle over time	A system of nodes and edges
Typical artifacts	Tools, `AGENTS.md`, docs, linters, tests, sandbox	Schedules, triggers, verifier agents, state file, budgets	Workflow graph, routing rules, checkpoints, approval steps
Failure it prevents	Agent guesses, breaks rules, claims false success	You become the bottleneck; work stalls between prompts	Hidden decisions, no audit trail, no recovery after failure
Main risk	Over-building before you know the failures	Runaway cost, unattended mistakes, comprehension debt	Rigid flows that block useful model judgement
Popularised	February 2026	June 2026	July to August 2026

Which one to invest in first

Build them in order, and only move up when you feel the pain the next layer solves.

Start with the harness. Every agent needs one, and it is where quality comes from. Each time the agent makes a mistake, ask what tool, doc, check or rule would have prevented it, and add that.
Add a loop when you are the bottleneck. If you keep prompting the same task, automate the prompting, but keep a verifier, a budget and a stop condition from day one.
Add a graph when the process needs to be explicit. Multiple agents, people in the loop, compliance or recovery requirements are the signals. Before that, a graph is overhead.

The terms will keep shifting, and the 2026 survey already points to ontology engineering as a possible next layer above graphs. The underlying lesson is steadier: models keep improving, but the reliability of an agent comes from the engineering around it.

Sources