Your Agent Doesn't Have a Model Problem
Harness, loop, graph, context engineering. Four terms everyone uses and almost nobody defines. Here is what each one means, which layer your system is actually failing at, and what it takes to get to something that ships work without you typing a prompt every time.
Think of a restaurant. The cook is the model: it decides what to do next. The kitchen is the harness: the stove, the knives, the pantry, the walk-in, who is allowed to touch the till. The tasting spoon and the thermometer are the loop: the dish goes back if it is not right, and there is a rule for how many times before someone gets called. The ticket rail is the graph: which station gets the order, what runs at the same time, and what has to be signed off before it leaves the pass. And what is actually written on the ticket that reaches each station, no more and no less, is the context.
Almost every failure people blame on the cook is actually an empty pantry, a broken thermometer, or a ticket that went to the wrong station.
If you only read that, you already have the idea. The rest of this is the same thing with the real names attached, in the order you need them, ending with what it actually takes to get a system that does work while you are asleep.
The one-screen version
Here are the four terms side by side, plus the two they are usually confused with, and the symptom that tells you which layer is actually your problem.
That table is the article. Everything below is detail, in increasing order of how much you need to care.
The diagnosis that starts all of this
The framing comes from a long-form piece by @0xwhrrari, published in late July 2026, which has done about 750,000 views. Its opening diagnosis is the part worth keeping:
The tools are unreliable. The state disappears between runs. The agent retries without learning anything. The workflow branches in ways nobody can inspect. And then every failure gets blamed on the model.
That last sentence is the expensive one, because the response to a misdiagnosis is always the same: upgrade the model, spend more, and get the same failure back with better prose. A better cook does not fix an empty pantry.
The piece compresses the separation into one line, and it is the best short definition of all three layers I have seen:
A harness lets it act.
A loop makes it prove the result.
A graph controls what is allowed to happen next.
These are not competing architectures you pick between. They are layers of one architecture, and in a small prototype all three are buried in the same script, which is exactly why people think they are the same thing.
First, the one everyone skips: prompt vs context
Before the three layers, the distinction underneath all of them, because it is the one that changed what the job is called.
Prompt engineering, in Anthropic's own words, is writing and organising instructions for optimal outcomes. Context engineering is curating and maintaining the optimal set of tokens during inference, including everything that lands in the window that you did not type: history, retrieved material, tool definitions, tool results, state. The line is between designing the instructions and managing everything the model is shown. Note that prompts are not necessarily throwaway — a system prompt, a stored template or a versioned policy is a prompt too.
In the kitchen: the prompt is the order. The context is the recipe, the allergy note, what is actually in the walk-in, and the prep notes from the shift before.
The reason this matters more than it sounds is an empirical effect that Anthropic addresses head-on, under the name context rot: as context grows longer and more crowded, the model's ability to accurately recall information from it degrades. Be precise about what that is and is not. It is an observed, model- and task-dependent tendency involving distractors and where information sits in the window. It is not something you can derive from the transformer's quadratic attention cost, which is a statement about compute and memory rather than about recall. And a bigger maximum window is not itself harmful. Filling it with low-signal tokens is. Dex Horthy's practitioner version is a dumb zone in the middle of a large window where recall degrades well before the window is full.
So the target is not the biggest window you can buy. It is, in Anthropic's phrasing, the smallest possible set of high-signal tokens that maximises the likelihood of the outcome you want. Four techniques do most of the work:
Layer 1: the harness
A raw model turns input into output. It cannot hold project state, run your test suite, write a file safely, enforce a permission, or pick up tomorrow where it stopped today. The harness is everything that supplies those.
The single best test for what counts, and it takes ten seconds:
What is left over falls into six buckets. If you are building one deliberately, this is your checklist.
The harness is your problem when the agent cannot reach a capability it needs, loses progress between sessions, holds permissions wider than its task, behaves differently on your machine than in CI, cannot be paused and resumed, or produces a failure nobody can reconstruct afterwards. None of those are fixed by a better prompt and none of them are fixed by a better model.
This is the layer where the tooling conversation actually lives. Claude Code and the Claude Agent SDK are harness products: hooks, scheduled runs, isolated worktrees, subagents, permission modes, skills. MCP is a standard for the action-surface bucket. Sandboxes are the safety bucket. None of them decide your boundaries for you.
One warning that people learn expensively. The best harness is almost always smaller than the first one you build. Every extra tool raises the chance of picking the wrong one, every irrelevant document competes for attention, and every broad permission widens the blast radius of a mistake. Stock the kitchen for the menu you actually serve.
Layer 2: the loop
Every tool-using agent already has a small internal loop: think, call a tool, read the result, think again. Loop engineering starts when you deliberately design cycles around that, to turn a one-shot attempt into a managed process.
One precision worth having up front, because the slogan below compresses it away. A loop is just repeated execution under a continuation and stopping condition. Looping does not verify anything by itself; a loop that regenerates, polls or retries proves nothing. What turns a cycle into verification is the evidence gate you put inside it.
The whole discipline compresses into one line, and if you take a single thing from this article take this:
"The agent says it is finished" is not proof. "The tests pass, the sources resolve and the reviewer approved the diff" is proof.
A model reporting that it is done is just another model output. It has the same failure modes as the work it is reporting on, which is why self-assessment is the weakest possible gate.
A production loop needs seven parts. Most of the broken ones I have seen are missing the last three.
Loops also stack, and it helps to name which one you are talking about. The agent loop does the work. The verification loop checks the work. An event loop wakes the system when new work arrives. And an improvement loop reads production traces and changes the harness itself, which is the least common of the four and probably the one with the most value left in it.
Anthropic's evaluator-optimizer pattern is loop engineering under a different name: one model generates, another evaluates, the feedback drives the next attempt. Their guidance on when it pays is worth repeating, because it is a real constraint. It works when you have clear evaluation criteria and when iterative refinement produces measurable value. If you cannot state the criteria, you do not have a loop, you have a retry.
And loops cost money. Every retry, grader and reviewer adds latency and spend. The rule is simple: add a loop when the expected cost of failure is higher than the cost of verification. An unbounded retry is not reliability, it is an invoice with no stopping condition.
The cleanest statement of why this is a bigger discipline than prompting: a prompt defines what should happen during one model call. A loop defines what the system does after that call.
Layer 3: the graph
Graph engineering asks a different question from the other two. Not how should the agent work, but what is allowed to run next.
Work becomes nodes. Allowed transitions become edges. State moves through the structure. That gets you fixed sequences, conditional branches, parallel fan-out, joins, bounded cycles, recovery paths and human interrupts, all written down instead of implied by control flow scattered through a script.
The decisions a graph forces you to make are the useful part, even if you never draw one:
Use a graph when the process has meaningful branches, parallel specialists, approvals, recovery routes or stateful handoffs. Do not reach for one just because a workflow has several steps. If one capable agent with three tools can do the job, a graph adds structure without adding value.
The failure mode here is specific and it is worth quoting, because it is the most common expensive mistake in this entire space:
The prescription: start with a simple harness. Study real traces. Formalise only the paths that turn out to be stable. Trace first, formalise second.
On tooling, the practical split is worth knowing. LangGraph models agents as stateful graphs with typed state, and when you configure it with a persistent checkpointer it saves state at super-step boundaries, which is what gives you crash recovery, replay and time travel, and a genuine pause-for-human-approval. The durability is opt-in, not automatic. OpenAI's Agents SDK is deliberately lighter, built around a small set of primitives — agents, handoffs, guardrails — with sessions for persistence, and points at external durable-execution infrastructure for crash recovery rather than building it in. AutoGen has GraphFlow. None of them tell you whether your graph describes the right work.
Where the canonical patterns fit
Anthropic's Building Effective AI Agents is the text most of this descends from, and it draws the line in a different and arguably better place. Workflows are systems where models and tools are orchestrated through predefined code paths. Agents are systems where models dynamically direct their own processes and tool usage. That distinction is about who controls the execution path, code or model, and it cuts across the three layers rather than mapping onto them. Either kind of system can contain loops and graphs. Worth holding alongside the harness/loop/graph split rather than instead of it.
Its five named patterns are the actual vocabulary of the field, and each one lands in a layer:
And the counterweight to this entire article, from the same source, which you should take seriously precisely because it comes from the people selling the models:
Their explicit guidance on when not to build an agent: when a single call with retrieval and good examples solves it, when the latency and cost are not justified, or when you have no clear evaluation criteria. Start with direct API calls. If you use a framework, understand the code underneath it.
How they nest, in one system
Take a research-and-publishing agent that produces a factual briefing. All four layers are present and each one is doing a different job.
The nesting is the payoff. The graph runs inside the harness. The loops run inside parts of the graph. The harness supplies the tools, state and evidence those loops need. Which is the restaurant again at a bigger scale: the building and the equipment are the harness, the ticket rail is the graph, the tasting and the thermometer are the loops, and every station gets only the part of the order it needs.
The actual question: how do you stop writing prompts?
Here is the honest answer. The prompt does not disappear. It gets promoted.
It stops being something you type each time and becomes a durable artifact inside the harness: a skill, a policy file, a checked-in operating procedure, a tool description, the instruction attached to a graph node, an evaluator's rubric. You write it once, test it, version it, and the system re-enters it when a trigger fires.
Anthropic's Agent Skills are the clearest productised version of this, and the mechanism is worth understanding because it solves the obvious objection. A skill is a folder with a SKILL.md file in it, plus optional scripts, references and assets. It loads by progressive disclosure: only the name and description sit in context at startup, the body loads when the task matches, and the reference material loads only if the work actually needs it. Anthropic's own framing of why that matters is the useful bit — a skill's body loads only when it is used, so long reference material costs almost nothing until you need it. That is what makes a library of them viable rather than a context tax. An ad hoc prompt you type is gone when the session ends. A skill is a file, so it can be versioned, reviewed and reused.
So what actually replaces manual prompting is four substitutions, and you can check yourself against them:
That is what autonomy actually looks like in practice: a bounded, repeatable class of work that the system can complete without anyone composing a fresh prompt or watching every step. It does not mean no humans. It means humans at the escalation points instead of humans in the loop for every cycle.
The most useful reality check on all of this comes from Dex Horthy's 12-Factor Agents, drawn from interviews with more than a hundred founders and AI engineers. The recurring pattern he found: teams adopt a framework, get to 70 or 80 percent of what they want, hit a ceiling, and then have to reverse-engineer the framework's own prompts and control flow to go further. His conclusion is the least glamorous and most useful sentence in the field:
The highest-leverage factors in practice: own your context window, own your control flow, contact humans with tool calls, and reduce the agent to explicit state transitions.
The five expensive mistakes
What to actually work on, in order
If you are an engineer trying to decide where to spend the next month, this is the ordering I would defend. It is roughly the reverse of how most teams do it.
The ordering exists to stop your architecture outrunning your understanding. Evals tell you what fails. Traces tell you why. Context and harness fixes remove the environmental causes. Loops add controlled correction. Graphs formalise the behaviour that has earned the right to become infrastructure.
Six things worth arguing with
2. More autonomy requires more explicit boundaries, not fewer. Reliable independence comes from permissions, budgets, evidence gates, stopping rules and escalation paths. The systems that run unattended are the ones with the most constraints written down.
3. Deterministic code in an agent system is not an admission of failure. Use the model for judgment under ambiguity and ordinary code for the conditions you already understand precisely. The best production agents are mostly the second thing.
4. Retries can lower reliability. A retry with unchanged state and no new evidence raises your bill while hiding the original defect. It looks like resilience and behaves like a leak.
5. The graph should describe behaviour before it dictates behaviour. Structure imposed too early makes wrong assumptions harder to see, because now they are in a diagram somebody is proud of.
6. Prompts get more important the moment you stop typing them. Once an instruction becomes a skill or a policy file, it needs versioning, evals, an owner and change control. It stopped being a message and became infrastructure.
The short version, again
Harness engineering makes the model operational. Loop engineering makes the work iterative and verifiable. Graph engineering makes complex execution explicit and controllable. Context engineering decides what the model can see while all of that happens. Evals and traces tell you whether any of it deserves to ship.
None of them substitutes for the others. A perfect graph cannot save an agent that loses its state. A perfect harness still burns money if the loop has no evidence and no stop rule. A strong loop becomes unoperable when the branches and approvals are hidden in ad hoc code.
So next time something fails, resist the reflex. Find the layer that owns the failure and fix that layer. If the dish comes back wrong, check the recipe, the kitchen, the thermometer and the ticket rail before you go looking for a different cook.
Yegge Built a City for His Agents. Then He Asked If They Were People. — what all three layers look like when one person pushes them as far as they go.
Proof of Loop — a working autonomous harness, and what it took to make the loop actually close.
The Context Wall — context engineering when the knowledge base outgrows the window.
The Expensive Part Is Remembering — what the loops and the harness actually cost, measured.
