At the start of 2025, we started talking about Agentic AI and multi-agent systems. Back then, our biggest pain point was building them to do what they’re supposed to, while still respecting the context window, avoiding hallucinations and not crashing.
In 2026, we introduced new paradigms to ensure agents are more reliable. They’re not exactly new, we’ve seen them work differently in different programming settings, but this is the first time we use them to ensure agents do what they’re supposed to.
Let’s take a look at these 3 agents, that have 3 failure modes.
Agent one edits a file, breaks a test, fixes that test, breaks another one, and keeps going like that until someone kills the process or the bill arrives. Nobody stopped it because nothing was checking whether the edit was safe before it happened.
Agent two never gets stuck, because it never does anything on its own. Every step needs a human to re-prompt it. It’s a very expensive autocomplete.
Agent three works beautifully in demos and then does something baffling in production. It skips the compliance check, answers before it retrieves, escalates a ticket it should have resolved. The model was free to choose a path you never wanted it to be able to take.
These look like three bugs. They’re three missing disciplines, and in mid-2026 each one picked up a name: harness engineering, loop engineering, graph engineering.
The terms are getting used interchangeably, which is a problem, because they are not interchangeable. You can’t fix a missing harness by adding another loop. And most production incidents I see come from having one of the three missing, not all three.
That’s what the failures look like in practice. A well-harnessed agent that loops forever and never lands. A tightly-looped agent with nothing stopping it from touching something it shouldn’t. A safe, terminating agent that takes a path through your workflow you never sanctioned. Same team, same model, three completely different root causes and the fixes don’t transfer. You cannot patch a missing harness by adding another retry layer, which is exactly what most teams try first.
This post defines all three, shows what breaks when each one is missing, and gives you a way to diagnose which one your project is short on. Because in production it’s almost never all three at once. It’s one — and the expensive part isn’t fixing it, it’s spending three weeks fixing the wrong one.
Five terms ranked smallest to largest. Every one of them already existed in software engineering under a different name, which is the fastest way to understand them.
They nest. A prompt sits inside a context window. Context is assembled at each step of a loop. A loop is one shape of graph — the simplest one, a single node with an edge back to itself. And the graph runs inside a harness, because the harness is everything that isn’t the model.
(One honest wrinkle: people also use “harness” the other way, as in “don’t build a graph here, just use an agent harness” — meaning a loose agentic loop instead of a fixed topology. Same word, narrower sense. I’ll flag it when it comes up.)
In traditional programming, the node is deterministic and the graph handles uncertainty in the data. You write a function that always does the same thing, then you build control flow around it to deal with inputs you can’t predict.
In agentic systems, that’s inverted. The uncertainty is inside the node. The function itself is stochastic. You’re building the same old structures — loops, state machines, runtimes — for the opposite reason: not to route data through trusted components, but to constrain a component you can’t fully trust.
That inversion is why the vocabulary had to be rebuilt. A while loop whose body might decide to stop early, hallucinate a tool call, or quietly do nothing is a different engineering problem than a while loop over an array, even though it’s the same keyword. Every one of these disciplines is an answer to “how much do I let the non-deterministic part decide?”
Which gives you the one line worth remembering: the harness is what surrounds the model, the loop is what repeats, the graph is what constrains the path.
The cleanest definition I’ve seen: Agent = Model + Harness. If it isn’t the model, it’s the harness.
That includes the system prompt, tools and their descriptions, MCP servers, the filesystem, the sandbox, memory, orchestration logic, compaction strategy, permission checks, and every hook that runs deterministically around a model call.
The framing matters because it forces you to stop asking “which model is smartest” and start asking “what system am I building around this intelligence.” The same model in two different harnesses produces wildly different results — there are public benchmarks where a model in its native harness scores well below the same model in a better-tuned one.
Harness engineering is what you’re missing when:
The agent takes actions it shouldn’t have been able to take at all
Performance degrades halfway through long tasks (context rot — no compaction, no offloading)
The agent can’t see its own work: no test runner, no logs, no browser, no way to verify
It forgets everything between sessions
You keep discovering after the fact what it did
The tell: the agent’s behavior is the problem. It did something wrong, and nothing structurally prevented it.
The fix is not another retry layer. If nothing checks whether an action is safe before it happens, adding retries just means it does the unsafe thing more times.
The core agent algorithm is embarrassingly simple: give the model context, let it call tools in a loop until it’s done. That’s loop one.
The interesting work is in stacking loops on top of it. The version I find most useful is four levels:
Agent loop — model calls tools until the task is complete. Automates work.
Verification loop — a grader (deterministic or LLM-as-judge) scores the output against a rubric and sends it back with feedback if it fails. Automates correctness.
Event-driven loop — a webhook, cron, or Slack message fires the agent. It stops being something you invoke and becomes a component running inside your system. Automates work at scale.
Hill-climbing loop — an analysis agent reads production traces and rewrites the harness config: prompts, tools, grader rubrics. Automates improvement.
That fourth loop is where most teams haven’t gone yet, and it’s the one that compounds. The return arrow doesn’t just go back to the top — it reaches inside and makes the inner loops better. Every cycle raises the floor.
Loop engineering is what you’re missing when:
The agent never terminates, or terminates too early (”early stopping” is a real, common failure)
Every run needs a human to kick it off and nudge it along
Nothing checks the output before it ships
Nothing improves run over run — you’re fixing the same class of bug in the prompt every week
State doesn’t persist between iterations, so each run starts from zero
The tell: the agent’s cadence is the problem. It’s not doing the wrong thing — it’s doing the right thing forever, or once, or only when you’re watching.
Model the system as nodes and edges. Nodes do work — deterministic code, a single LLM call, a tool call, or a full agent run. Edges define what happens next, and some of them are conditional on state.
It’s a state machine. And that’s the entire point: a graph is where you encode what you already know about how the workflow should go.
A support agent should classify before it answers or escalates. A coding agent should read the repo before it proposes a change. A compliance workflow requires approval before any external action. Those aren’t things you should be hoping the model figures out. Those are edges.
Two clarifications that cut through most of the confusion:
Agent graphs are usually not DAGs. Production agents retry, ask for missing info, revise after validation, and pause for human input. Cycles are the norm.
A loop is just a directed cyclic graph. Loop engineering isn’t the alternative to graph engineering — it’s the simplest case of it. LangChain’s own simple-agent-loop framework is literally built on top of their graph framework.
What’s genuinely new in this wave isn’t the graph. It’s what you can now put inside a node. Early on, a node was code or one LLM call. Now a node can be a full coding agent doing open-ended work in a repo. You’re orchestrating agents, not model calls.
Graph engineering is what you’re missing when:
The workflow has known structure the model keeps ignoring
You’re paying for model reasoning on steps that are pure deterministic plumbing
Behavior is unpredictable between runs on the same input
Certain steps are non-negotiable (approval, audit, policy) and you need them enforced, not encouraged
The tell: the agent’s path is the problem. It got there a way you didn’t want it to.
This is the part people skip, and it matters.
Some work is genuinely agentic and forcing it into predefined paths makes it worse. Generic deep research is the standard example: plan, delegate, search, read, synthesize — in an order that depends entirely on what it finds. LangChain built early deep research on graph workflows and then moved it to a more agentic core loop. GPT Researcher made the same move.
The rule: if you can’t draw the workflow ahead of time, don’t encode it as a graph. Give it a strong harness and let the structure emerge at runtime.
Corollary: if you can draw it and you’re still letting the model choose, you’re paying tokens for a decision you already made.
Back to the glossary, now that the pieces have names.
The harness is the runtime. The graph is the control flow. The loop is the simplest graph there is. Each node assembles context. Each context contains a prompt.
Five layers of one stack — different units of work, different failure modes, different tools. Nobody is replacing anybody, and “graph engineering is the new loop engineering” is roughly as coherent as saying state machines replaced while.
Skip the theory. Match the symptom.
Run this on your actual production incidents from the last month. I’d bet the failures cluster in one column, not three.
If you’re starting from zero, in order:
Harness first, always. Tools, sandbox, filesystem, permissions, one verification step. A weak harness makes every other layer unsafe. There’s no clever loop design that compensates for an agent that can drop a production table.
Then the simplest loop that works. One agent loop plus one grader. Resist the urge to build four levels on day one. Don’t start with a loop for a workflow a script would handle — the honest test is whether the decision logic is genuinely ambiguous at runtime.
Add graph structure only where you know the answer. Every edge you hardcode is a decision you’re taking away from the model. That’s good when you’re right and expensive when you’re wrong. Encode the steps you’d fire someone for skipping; leave the rest agentic.
Then the loops that compound — event triggers so it runs without you, and trace analysis so it gets better without you. This is the part almost nobody does, and it’s where the leverage is.
The mix is the whole game. In a well-built system, some nodes are fixed API calls, some are single model calls with no tools, and some are full agents doing open-ended work. Predictable where it needs to be, agentic where it pays off.
Harness engineering = what the model has and what it’s allowed to do. Fix behavior problems here.
Loop engineering = what repeats and when it stops. Fix cadence problems here.
Graph engineering = where model reasoning happens vs. where code decides. Fix path problems here.
A loop is a simple graph. A graph runs inside a harness. Nobody replaced anybody.
All three are the same underlying idea: put model reasoning in the right places, with the right context, at each step. The rest is naming.
Are you learning AI engineering?
For exclusive cheat sheets, prompt libraries and project guides, consider becoming a founding member
If you’d like a deep-dive into LLMs, Agents, RAG, Context Engineering, orchestration and multi-agent systems check out my Agentic Intelligence Guide
If you’re practicing for interview but don’t know how to prepare AI agents interview and case studies, check my Agentic AI Engineer Interview Bank (NEW)
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.