Your agent broke. Do you add a tool, add a retry, or draw a workflow? Three buzzwords are fighting for that answer in 2026: harness engineering, loop engineering and graph engineering. The cleanest map we've seen is an X article by beamnxw (@beamnxw), "Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering" (Jul 25, 2026, around 1.2M views). We use it as the community framing, paraphrased, and anchor every layer to primary docs from LangChain, Anthropic, OpenAI and Microsoft. The diagnosis tips are beamnxw's; the jokes and the worked example are ours.
The 30-second answer
- Harness engineering
- EnvironmentThe machinery around the model: tools, context, state, permissions, traces.
- Loop engineering
- FeedbackThe repeated work-and-feedback cycle: act, check, fix, stop.
- Graph engineering
- FlowThe workflow made explicit: nodes, branches, joins, state transitions, controlled cycles.
Paraphrased from @beamnxw. Two notes from the same article: "loop engineering" is a newer practitioner term in 2026, and graph engineering here means execution graphs and state machines, not knowledge graphs.
They aren't rivals. They nest. The graph runs inside the harness, the loops live inside the graph, and the harness hands everyone the state, tools and evaluators they need.
Harness
Supplies state, tools, evaluators, permissions and traces to everything below.
Graph node: research
A loop lives here: gather, check sources, retry.
Graph node: build
A loop lives here: write, run tests, fix.
Graph node: review
A loop lives here: grade against a rubric, send back.
Graph edges and joins
Routing conditions decide what runs next; cycles have exits.
Result, traced by the harness
Every node's state and tool I/O is observable.
Harness: everything that isn't the model
LangChain's Vivek Trivedy put it as an equation in "The Anatomy of an Agent Harness": Agent = Model + Harness. The harness is every piece of code, configuration and execution logic that isn't the model itself, and "a raw model is not an agent". beamnxw's shortcut for spotting it: delete the model from your architecture diagram, and what's left is probably harness. Our harness engineering explainer goes deep on this layer.
Harness
Model
Environment
- Context injection
- APIs
- Browsers
- Shells
- Databases
- MCP tools
- Files
- Checkpoints
- Git
- Progress logs
Control
- Timeouts
- Retries
- Budgets
- Routing
- Sub-agents
- Approval gates
- Permissions
- Isolation
- Secrets
- Traces
Harness
Environment
- Context injection
- APIs
- Browsers
- Shells
- Databases
- MCP tools
- Files
- Checkpoints
- Git
- Progress logs
Control
- Timeouts
- Retries
- Budgets
- Routing
- Sub-agents
- Approval gates
- Permissions
- Isolation
- Secrets
- Traces
Model
Context + actions →
Limits + observability →
Anthropic's "Effective harnesses for long-running agents" (Nov 26, 2025) is the best worked example of harness fixes. The problem: agents that work across many sessions forget what they did. Their fixes are all environment, no new model, because, as Anthropic puts it, "compaction isn't sufficient":
- An initializer agent sets up the environment on the first session.
- A progress file, claude-progress.txt, carries state between sessions.
- Agents commit with descriptive messages and use git history to revert.
- A JSON feature list of 200+ end-to-end features, all marked "failing" at the start.
- Each session leaves the environment in a clean state.
Harness work is also where tool customisation lives. Claude Code's new mods, for example, let you rewrite tool calls and draw your own UI from inside the agent; we covered them in Claude Code Mods: Rewrite the Agent From the Inside.
Loops: repeat until there's evidence
Every agent already has one loop. The OpenAI Agents SDK docs spell out its runner: call the model; if it returns a final output (typed text, no tool calls), stop; if it hands off, switch agents and run again; if it calls tools, run them, append the results and loop. Go past max_turns and you get MaxTurnsExceeded. Loop engineering is about the loops you add on top of that one.
- 01
Agent loop
The model calls tools repeatedly until a task is complete.
- 02
Verification loop
Output is scored against a rubric and retried with feedback.
- 03
Event-driven loop
Events trigger agent runs that update a real system.
- 04
Hill-climbing loop
Production traces feed an analysis agent that improves the harness configuration.
Notice the last one: a loop whose output is a better harness. The layers really do feed each other.
Anatomy of a loop
| Part | The question it answers |
|---|---|
| Trigger | What starts a run? |
| Goal | What does done look like? |
| State & memory | What carries over between attempts? |
| Action policy | What is the agent allowed to try next? |
| Evidence | What proves the attempt worked? |
| Feedback | What goes back to the agent when it didn't? |
| Stopping rule | When do we stop, on success or out of budget? |
Loop on evidence, not confidence
beamnxw's line is the one to tattoo: "Do not loop on confidence. Loop on evidence." "The agent says it is done" is not a stop condition. A passing test is. A schema check is. A reviewer with a rubric is. It's the same point Hanako made in the loops-and-graphs playbook we covered in our agent teams post. And loops aren't free: every grader and retry adds cost and latency. Add one where a failure costs more than checking for it.
Graphs: make the flow explicit
A graph turns "the agent figures out the order" into a diagram you can read, test and resume. Per beamnxw, a graph engineer decides six things:
- Node boundaries: what is one unit of work?
- State schema: what data moves between nodes?
- Routing conditions: which edge fires, and why?
- Concurrency: what runs in parallel?
- Cycles and exits: where can work loop back, and how does it get out?
- Durability: checkpoints and resume after a crash or a human pause.
The frameworks agree on when to reach for one. Microsoft's AutoGen docs say to use a graph when you need "strict control over the order in which agents act", or when different outcomes must lead to different next steps, and suggest starting with RoundRobinGroupChat or SelectorGroupChat first. Its DiGraphBuilder supports sequential chains, parallel fan-outs, conditional branching and loops with safe exit conditions; GraphFlow itself is marked experimental. LangGraph calls itself a low-level orchestration framework and runtime for long-running, stateful agents, with durable execution, human-in-the-loop state edits and memory, and it lets you mix deterministic and LLM steps in one graph. For node types, edges and governance, see our graph engineering explainer.
✅ Draw the graph
Meaningful branches and recovery paths.
Parallel work, approvals, or several specialists in a set order.
🙅 Skip it for now
One agent, three tools.
Work you don't understand yet: a graph can freeze assumptions too early.
Anthropic's "Building effective agents" says the same in general form: find the simplest solution possible, and only increase complexity when needed. It calls predefined code paths workflows, and systems where the LLM directs its own process agents.
Diagnose by symptom
This is the useful bit. Don't pick a layer because it's trending; pick it because of what's going wrong.
| Symptom | Layer | What we'd do |
|---|---|---|
| Can't reach the data or tool it needs, or can't reach it safely | Harness | Give it one well-described tool with scoped permissions, run it in a sandbox, and hand it the context it needs up front |
| Forgets progress across sessions | Harness | Write progress down outside the chat: a progress file, git commits, checkpoints. In our blog pipeline, a research facts file carries the sources from one agent to the next, and git carries the work |
| First attempt is close but unreliable | Loop | Add a checker the agent doesn't control (tests, or a separate reviewer agent like ours), feed the failures back, and cap the retries |
| Keeps going after it's done, or stops before it can prove it | Loop | Define done as something you can verify, plus a budget that ends the run either way |
| Several specialists must act in a set order | Graph | Draw the steps and the hand-offs: who runs, in what order, and where results merge |
| Failures are hard to pin down in a multi-step run | Graph + harness | Log state per step so a failed run points at one node and its tool calls |
| The workflow changes too often for a fixed diagram | Simpler harness | Hold off on the diagram; let the model plan inside a lean harness until the shape settles |
01Can't reach a tool or data safely, or forgets yesterday's work?
YES → Harness: tools, permissions, durable stateNO ↓
02Close on the first try, but unreliable, or stops at the wrong time?
YES → Loop: external checks, feedback, a bounded retry and a stop ruleNO ↓
03Several specialists, branches or approvals in a fixed order?
YES → Graph: nodes, edges, routing, joinsNO ↓
04Something fails mid-run and you can't tell where?
YES → Graph + harness: traces aligned with nodesNO ↓
The workflow keeps changing: keep a simpler harness and let the model drive. Delay the graph.
🐛 Symptom lane
illustrative examples
"My agent says done but the tests fail."
"My agent forgets yesterday's work every morning."
🔧 Fix lane
illustrative examples
Loop fix: the stop condition becomes "the test suite exits 0", failures go back as feedback, and retries are capped.
Harness fix: a progress file, descriptive git commits and a feature list the agent reads at the start of every session, like Anthropic's long-running harness.
Illustrative examples, ours. Same agent, same model: one bug is missing evidence, the other is missing memory.
One real system: how this blog ships
Theory is cheap, so here's a first-hand one: the multi-agent pipeline we use at ByteVancer to research, write and publish posts on this blog. In order, it runs: research facts file (sources only) → builder agent writes the post → scratch SSG build with a page count → reviewer agent fact-checks against the research file → commit on ali_dev → fast-forward main → Coolify auto-deploy → live curl checks → IndexNow. Mapped to the three layers:
The pipeline
Research → build → review → ship, with an agent at each writing step.
Harness
A research facts file as the only source of truth, a scratch build, a git branch, Coolify.
Loop
The reviewer fact-checks against the research file: PASS or PASS-WITH-FIXES, with a cap on fix rounds.
Graph
A fixed order: builder → scratch build → reviewer → commit → deploy. No step skips the reviewer.
Gate: reviewer verdict + clean SSG build
Evidence, not "looks good": a verdict against sources and a page count.
Ship and verify
Fast-forward main → Coolify auto-deploy → live curl checks → IndexNow.
The writer never grades its own work (separate reviewer), the loop stops on a verdict, not a feeling, and the graph is boring on purpose. Our posts don't need branches, so we didn't draw any.
Expensive mistakes
beamnxw's list of the costly ones, paraphrased, with our own spin:
- Drawing the flowchart first. If you haven't done the task by hand a couple of times, you don't know its graph yet.
- Letting the writer grade its own homework. Our pipeline uses a separate reviewer agent for exactly this reason.
- "Try again until it works" as the whole loop spec. No check, no cap, just a token bonfire. 🔥
- Hoarding tools and memory in the harness. Every extra tool is one more wrong turn the model can take.
- Calling the model dumb when the orchestration lost the context, skipped the check or routed to the wrong step.
Production checklist
| Area | Ask yourself |
|---|---|
| Harness | Could a new teammate read every tool's description and permissions in five minutes? Can you stop a run, look at its state and resume it tomorrow? |
| Loop | What exact signal means done? (For our blog: the reviewer's verdict plus a clean build.) What does the agent hear when it fails, how many tries does it get, and what happens when the budget runs out? |
| Graph | Which steps are fixed code, which run in parallel, what state do they share, and where does a human sign off or a failed step recover? |
| Evaluation | Can you replay last week's run against today's version and say which change made it better? |
| Operations | Do you know the cost, the latency, the failure rate, how often a human stepped in, and how many tasks actually succeeded? |
TL;DR: harness is the environment, loops are the feedback, graphs are the flow. When your agent breaks, read the symptom first, then fix that layer, and only that layer. Most "the model is dumb" bugs are a missing check or a missing progress file. 🫡