A prompt that fails gives you a bad answer. A loop that fails does something worse: it keeps going. It cannot distinguish finished from stuck, so it does not stop, and it does not error — it just spends tokens until someone notices the bill.
That asymmetry is the reason "prompt engineering is dead" has been wrong every time someone has said it. Prompt engineering did not die. It hit a ceiling, and two more floors got built on top of it, each one buying capability by giving up a different kind of control.
Recent research lets us be specific about all three floors and, unusually, about what each one costs.
Floor one: the prompt still pays rent
The prompt layer covers a single call — structuring the instruction, supplying the minimal information that fully specifies the expected behavior, and nothing more.
The temptation is to treat this as solved and move up. Evidence from July says otherwise. When LangChain shipped deepagents 0.7.0, it cut input tokens on default-agent turns from 5,395 to 1,895 — a 65% reduction — and tool-description tokens from 4,005 to 2,302 [3]. The stated cause: the authored base prompt now starts empty, and "tool-usage prose that duplicated tool schemas has been trimmed" [3].
A mature framework was sending nearly three quarters of its default prompt for nothing, because English descriptions duplicated structured tool schemas the model already receives. That is a prompt-layer defect, discovered in 2026, in a project whose entire purpose is agent orchestration.
The floor beneath you does not stop mattering when you build above it. It just stops being where you are looking.
Floor two: the loop, and the artifact nobody writes down
Above the prompt sits the loop — how a system repeatedly observes, acts, verifies, and recovers.
A June 28 paper gives this layer its first real vocabulary. It introduces loop specifications as structured artifacts comprising five components: triggers, goals, verification steps, stopping rules, and memory [1]. The framing is explicit that loop engineering complements prompt engineering rather than replacing it, and that a loop specification is not the same thing as a program loop.
The empirical contribution is a hand-coded corpus of fifty real loops — a Loop Library — analyzed by verification level. Two findings from that corpus [1]:
- Seventy percent of loops verify in the autonomous zone of the paper's verification ladder.
- Seventy-four percent name their terminal states.
Read the second figure as its complement. One in four real, working loops cannot say what "done" looks like.
That is the silent-failure mode. A loop without a named terminal state has no mechanical test for completion, which means it cannot detect its own absence of progress. It will retry a failing operation, re-read the same file, re-attempt the same fix — and every iteration looks locally reasonable. Nothing throws. The loop is not broken in any way your monitoring recognizes; it is simply never finishing.
This is why the five components are worth treating as a checklist rather than a taxonomy. Triggers and goals are the parts everyone writes, usually implicitly, in the prompt. Verification, stopping rules, and memory are the parts that get skipped — and they are precisely the parts that convert an expensive infinite loop into a bounded operation.
The paper organizes its taxonomy by verification level, which is the right axis [1]. Verification is what distinguishes a loop that can run unattended from one that merely runs unattended. A loop whose verification is "the model says it looks done" is in a different category from one whose verification is "the test suite exits zero," even though both will happily execute without a human present. Seventy percent of the corpus sat in the autonomous zone of that ladder — meaning most real loops have verification strong enough to justify running unsupervised, which is more encouraging than the terminal-state number suggests.
The honest caveat: this is a single-author paper describing a corpus its author assembled and coded by hand. The 70% and 74% figures describe those fifty loops, not the industry. What generalizes is the framework and the failure mode, not the percentages.
Floor three: the graph, and what it costs
The top floor is many agents — orchestration across a system rather than iteration within one.
The best public economics on this layer is still Anthropic's engineering writeup on its multi-agent research system — a piece from June 2025, now over a year old. Nothing has superseded it, which says something about how rarely anyone publishes real numbers here.
The headline: a multi-agent system with Claude Opus 4 as lead agent and Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2%" on an internal research evaluation [2].
Then the price. "Agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats" [2].
And then the line that should govern every architecture decision at this layer: on BrowseComp, "token usage by itself explains 80% of the variance" in performance, with three factors together explaining 95% [2].
Sit with that. Four fifths of the performance difference is accounted for by how many tokens you spent. Which means a large share of what looks like architectural cleverness at the graph layer is, measurably, buying results with budget.
Anthropic says the implication out loud rather than hiding it: "For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance" [2]. Good fits are "valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools." Bad fits are domains "that require all agents to share the same context or involve many dependencies between agents" — and the example given for the bad case is coding [2].
That last detail is the one most teams should notice. The single most popular multi-agent use case is named, by the company that published the 90.2%, as a poor fit for multi-agent architecture.
The pattern: each floor up trades control for capability
Stack the three and a consistent trade appears.
The prompt is the most controllable layer and the least capable. You know exactly what goes in, you pay once, and failure is legible — a bad answer you can read. Its ceiling is that it only handles what fits in one call.
The loop buys persistence and recovery. It pays for them with observability. Its failure mode is not a wrong answer but an unbounded one, and it is bounded only by rules you remembered to write. The 26% of loops without named terminal states are not exotic — they are what happens when you build a loop by adding retries to a prompt.
The graph buys parallelism and scale. It pays with cost, and the 80%-of-variance figure means you cannot cleanly separate "our architecture is good" from "our architecture is expensive." Its failure mode is a correct answer that cost ten times what it should have.
Notice that each layer's failure gets harder to see. A bad answer is obvious. A loop that never terminates shows up in a bill. A graph that overpays for a result it could have achieved with one agent shows up nowhere at all — the output was fine.
The obvious pushback
"Prompt, loop, graph" could easily be another layer cake invented to sell a methodology. Three named tiers, an implied maturity model, and a consulting engagement at the end.
The defense is that each layer is defined by a distinct failure mode with distinct instrumentation, not by a vibe. You detect prompt-layer waste by counting tokens per turn against what the model already receives. You detect loop-layer failure by checking whether your terminal states are mechanically testable. You detect graph-layer waste by comparing cost per completed task against a single-agent baseline. Three different measurements, three different dashboards. That is a real distinction.
The weaker part of the framing is that these floors are not strictly sequential in practice. Plenty of production systems run a graph of agents whose individual prompts are bloated and whose loops have no stopping rules — skipping straight to floor three without finishing floor one. Which is arguably the strongest argument for naming the layers at all.
Which floor is your problem on
The diagnostic is short.
If your agent gives wrong answers on tasks it should handle in one shot, you have a prompt problem, and the first thing to check is whether you are describing your tools twice.
If your agent produces good work but occasionally burns an unreasonable amount of budget without finishing, you have a loop problem. Write down the five components for your main loop. If you cannot state, in a form a machine could test, what "done" means, that is the bug — and it is not in your prompt.
If your agent works reliably and costs more than the task is worth, you have a graph problem, and Anthropic already told you the fix: check whether the task actually involves heavy parallelization and context that exceeds one window. If it does not, you are paying 15× for coordination you do not need.
The industry keeps announcing that the previous layer is obsolete. It never is. What actually happens is that a new floor opens, most people move up before finishing the one below, and then spend a quarter debugging something on a floor they stopped looking at.
References
[1] Sandeco Macedo — Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting — (2026-06-28). Paper
[2] Anthropic — How we built our multi-agent research system — (2025-06-13). Blog
[3] LangChain — LangChain Python releases changelog: deepagents v0.7.0 — (2026-07-24). Documentation