A practical breakdown of why single-agent loops fail at scale and how graph-based multi-agent architectures solve context rot, error cascading, and observability problems.
Adapted from @kirillk_web3# Kimi K3 - From Loops to Graphs: How I Cut AI Agent Costs by 70% Your agent has been running for forty minutes. The token counter keeps climbing. The output isn't getting better. You've hit the ceiling of the loop. > Bookmark this article, before you forget. ## The Thing Everyone Discovered at the Same Time On July 17, Peter Steinberg — founder of OpenClaw — posted on X: "Are we still talking about loops, or have we already moved on to graphs?" He's the same person who coined "loop engineering" a few months earlier. The pushback was immediate. David Khourshid, author of XState, and other senior engineers pointed out that nodes, edges, and state machines are not new — computer science has been doing this for decades, and purposeful sub-agents are already a graph by another name. That criticism is correct. And it misses the point. Whether the term is new and whether the shift is real are two different questions. The term will be replaced by the next buzzword within months. The shift underneath it won't. ## Five Layers, Not Five Replacements The job of making AI systems work reliably has been renamed five times. Each layer solves what the previous one couldn't reach — and each one assumes the ones below it are already in place. Prompt engineering — how to phrase the request so the model outputs accurately. Context engineering — what to put in the model's window. Retrieved documents, memory, tool definitions, conversation history. Harness engineering — the structure around the model. Which tools are available, which guardrails can't be crossed, how state persists across sessions. Loop engineering — how an agent discovers, plans, executes, and verifies on its own without a human prompting each step. Boris Cherny's line captures it: "I don't prompt Claude anymore. I run loops, and those loops prompt Claude." Graph engineering — how to organize multiple execution nodes into a system. The division of labor in one sentence: loop engineering solves how to keep a single agent working continuously. Graph engineering solves how to organize multiple agents, tools, and humans into something observable, recoverable, and scalable. Loops didn't die. They became the inside of a node. ## Five Ways a Loop Breaks Context rot. Every round of thinking, every tool call, every observation goes back into the same window. Round one: 2,000 tokens. Round ten: 18,000. The original goal drowns in the model's own reasoning, and it starts analyzing its own output instead of the task. Error cascading. A tool throws an error. The model retries with different parameters. Fails again. Tries something else. Tens of thousands of tokens later, the answer is still wrong — because detecting and breaking out of a failure loop from inside the same chain of reasoning is genuinely hard. Tool overload. Equip a single agent with fifteen to twenty tools and selection accuracy drops sharply. Two tools with similar descriptions and the model picks the wrong one. No control. You can't pause a subtask for approval. You can't assign a different model to a different step. You can't run an independent quality check mid-run. The loop either completes or you kill it. No observability. You know what it thought, what it called, what it retrieved. You don't know why it branched where it did, or which decision produced the final error. ## And One Failure Mode That's Worse Goal blindness. The loop can only see the metric it was given. So it optimizes that metric — including in ways that betray the metric's original intent. A team building an AI support agent optimized for ticket resolution rate. The curve went up for five straight months. Then churn doubled at renewal. The agent had learned to resolve tickets by closing conversations quickly, discouraging follow-up questions, and marking abandoned issues as resolved. The better the loop performed, the closer the business got to failure. Goodhart's Law, executed with perfect efficiency. None of these five flaws — or goal blindness — get fixed by making the loop bigger. The root cause isn't inside a single loop. It's in the relationships between links that don't exist yet. ## The Real Diagnosis Strip away everything else and the core failure is this: The model is both the athlete and the referee. It executes the task, then evaluates its own execution, using the same reasoning that produced the output in the first place. If the reasoning was flawed, the evaluation inherits the flaw. The graph's answer is structural: split execution and verification into two independent nodes. One agent draws conclusions. Another — the validator — exists specifically to overturn them. That validator is the highest-leverage node in the entire system. ## What an Executable Graph Actually Is Not a flowchart. A flowchart is for humans to look at — it describes how we hope things will go. An executable graph is for machines to run. Tasks, dependencies, state, permissions, budgets, failure recovery, human approvals — all of it has to actually execute. Formally, four parts: V — vertices. Units of work. One input, one output, one job. Can be a specialized agent or a deterministic code step. E — edges. Routes between nodes. Answers "where next." Direct path, conditional branch, fan-out, fan-in, or a loop. S — state. The object everyone reads and writes as it flows along edges. Tasks, evidence, budgets, artifacts, checkpoints. This is what binds independent agents into one system. P — policy. Constraints on who can create nodes, call tools, modify the graph. Think of it as a small company that runs itself. A company doesn't have the same person doing research, writing the proposal, and reviewing it. It splits the roles and lets work flow between them. The graph turns an agent from a loop into an org chart. Two things it is not: It's not a knowledge graph. A knowledge graph organizes what a system knows. This organizes who makes up the system and how work flows through it. (More on how they connect below.) It's not a flowchart with better branding. Only when nodes execute independently, edges carry real state, and the process can be inspected, paused, resumed, and traced does it become a system structure. ## The Topologies Worth Knowing Three patterns cover most production systems. The diamond — fan-out, fan-in. The most common shape. Take writing an article: one agent reads the source posts, another translates the official docs, a third scans community discussion. All three start simultaneously without waiting on each other — that's fan-out. Results come back, get deduplicated and categorized by code, then hand off to a single writer — that's fan-in. Connect the two and you get a diamond. Supervisor-worker. A supervisor agent handles scheduling, delegating to specialized workers for research, coding, review, while it focuses on planning and synthesis. This is the core pattern in Anthropic's research system — the master agent analyzes the problem, forms a strategy, spawns sub-agents that collect information in parallel, then aggregates their output into the final answer. Pipeline. A task decomposed into fixed steps, each processing the previous one's output, with programmatic checkpoints between them. Trades latency for accuracy, because each call becomes a simpler task. Anthropic's Building Effective Agents guide adds two more: https://www.anthropic.com/engineering/building-effective-agents Routing — classify the input first, then direct it to specialized downstream handling. Useful when input types vary enough that optimizing a single prompt for one type hurts another. Evaluator-optimizer — one agent generates, another evaluates and scores, iterating until it clears the bar. Useful when evaluation criteria are clear and iteration measurably helps. These aren't competing framework choices. They're building blocks that nest. Production systems commonly run a supervisor wrapping several diamonds, with pipelines inside those diamonds. ## Where Kimi K3 Fits as a Node A node's job is to do one thing, autonomously, and return clean output. Three things about Kimi K3 map directly onto that. If you're interested, I've already written a detailed article about this model Kimi K3 below. 1M context means a node can hold the whole task. Not the whole session — the whole task. A research node that fans out across a dozen sources, a code node that needs the full module in context. The node doesn't truncate its own inputs. KDA makes long nodes affordable. Kimi Delta Attention delivers up to 6.3x faster decoding at million-token contexts. A node that routinely processes large inputs is the difference between "technically possible" and "runs in production." Long autonomous runs are the design target. Moonshot's own demonstration: K3 was given the implementation of Attention Residuals and one objective — make it faster on H200 without changing numerical behavior. Twenty hours of experiments, zero human intervention, 1.6x speedup. That's the exact profile of a node that thinks for a long time and returns a result. Which is the whole argument for graphs. Kimi K3 makes each node stronger. Only the structure makes the system reliable. ## The Validator: Use a Different Model This is where most people build their graph wrong. If your executor is Kimi K3 and your validator is also Kimi K3, you've recreated the athlete-and-referee problem one layer up. Same model, same training, same blind spots. It will miss the same things twice. Run different models in different nodes. Executor on Kimi K3 — long context, cheap decoding, sustained work. Validator on Opus 5 — different training, different failure modes, and an effort dial you can turn up specifically for the check. The validator node is small. It doesn't need to hold the whole task, just the conclusion and the evidence. So you pay premium rates on a fraction of your tokens while your bulk work runs cheap. This is the same routing principle from running Kimi K2.7 alongside Opus 4.8 — default to cheap, escalate where it matters — except now the escalation is structural instead of a judgment call you make each time. Three validation patterns: 1. Adversarial — send several independent skeptics to refute the same conclusion. It stands only if the majority fail to overturn it. 1. Multi-perspective — check different dimensions separately. Correctness, security, reproducibility, each its own pass. 1. Jury — run multiple solutions in parallel, score them, pick a winner, then fold the best elements of the runners-up into it. How hard to check depends on how much the task matters. That calls for a router — a triage desk that sends work down different inspection paths by importance. ## Anchoring: Code and Reality Agents checking each other isn't enough. Certainty comes from two places. Code. Anything with a deterministic answer — format validation, running tests, deduplication, sorting — belongs in code, not in a model. The industry phrasing is worth memorizing: > The model's judgment lives in the nodes. The code's reliability lives in the edges. Reality. If every node in your graph is just referencing conclusions generated by models, and not one node touches the real world, you've built a very sophisticated machine talking to itself. Real anchors are facts that can't be argued with. The tests passed. The user stayed. The money arrived. And what "better" means has to be defined by a human, because every loop in the graph presupposes it. ## Where the Knowledge Graph Comes In This connects to something I wrote about previously — and it's the cleanest solution to the validator problem. A knowledge graph stores facts and their relationships: entities, typed edges, evidence attached to every claim. When your validator node checks a conclusion, it doesn't check it against another model's opinion. It checks it against the graph. Does this claim trace to a path in the graph? Which nodes support it? Does the evidence exist? That's external verification with no model in the loop. The graph is the referee, and it isn't guessing. It also solves state. The long-term state layer of your orchestration graph — what the system remembers across runs, not just across steps — is a knowledge graph. Answers get written back as new facts, and the next run starts smarter. Two different graphs, two different jobs: the orchestration graph is who does the work. The knowledge graph is what the system knows. They plug into each other at exactly two points — verification and long-term state. ## The Frameworks, and What They Cost Graph engineering isn't a concept waiting for tooling. LangGraph, Google ADK, and Microsoft's AutoGen were building agents from nodes, edges, and shared state two years before the term existed. The 4x spread between LangGraph and AutoGen is worth understanding. It comes from the graph structure turning inter-agent dialogue into state transitions — eliminating all the redundant chatter where agents restate context to each other. At Kimi K3's output pricing, run that task a thousand times: roughly 2M tokens versus 8M. About $30 versus $120 for identical work. Scale that across a production system and the architecture choice costs more than the model choice. That spread is also why LangGraph became the enterprise default. LangGraph's killer feature is persistent execution. Attach a checkpointer when compiling the graph and it snapshots state at the end of every super-step. Four capabilities follow: - Human-in-the-loop — pause at any node, wait for review or approval, resume from the breakpoint - Memory — context preserved across interaction rounds - Time-travel debugging — return to any historical checkpoint, replay, or fork a new path - Fault tolerance — a node fails, restart from the last successful step instead of the beginning Plus a detail called pending writes: when one node fails inside a super-step, the successful outputs of sibling nodes are preserved. You don't re-run what already worked. Those engineering details are what separate a demo from a production system. One caution from Anthropic's own guidance: frameworks add abstraction that obscures the underlying prompts and responses, making debugging harder and tempting you to overcomplicate. Their recommendation is to start with the model API directly — many patterns are a few lines of code — and if you do adopt a framework, understand the code underneath it. ## The Concrete Comparison Same task, two architectures. Daily research briefing: read several sources on a topic each morning, write a one-page summary, verify it, email it. As a loop. One agent does everything. It stuffs all search results into context, drafts the briefing, then reviews its own draft. By review time, the context is a mess — raw search results, half-written sentences, and its own prior reasoning, all jumbled together. It's reviewing itself inside the same context where it wrote the draft. That's asking the author to grade their own paper, and it almost always passes. And because loops are sequential, it reads one source at a time, so it's slow. As a graph. Three nodes, state flowing cleanly between them. The researcher node fans out across sources, searches in parallel, and returns only structured notes. The writing node receives clean notes — never the messy raw pages — and produces a briefing. The review node sees only the briefing, in a fresh context, with no knowledge of how it was written. If it fails, a conditional edge sends it back for a rewrite. If it passes, the briefing ships. Same task. The difference is that the reviewer isn't the author, and the writer never sees the mess. ## "Isn't This Just Old Workflows?" The most common objection from senior engineers, and it deserves a real answer. Old workflows had rigid paths. Every node hard-coded, like a fixed assembly line — no adaptation when something unexpected showed up. ReAct went to the opposite extreme: let the model think and act throughout. Flexible, but the entire control flow drowned in the model's own conversation. Ask why it did something and you're digging through a conversation log like an archaeologist. Hard to reproduce, hard to audit, easy to lose control of. Graphs separate stability and flexibility into two layers instead of forcing a choice. Edges and structure are fixed, so the system can be governed and audited. Nodes retain autonomy internally, so they stay flexible enough for specific problems. This echoes Anthropic's own definition: a workflow is orchestrated through predefined code paths; an agent is a system where the model dynamically determines its own process. A graph is the fusion — predefined edges framing dynamic nodes. It returns to the form of the old workflow. The core is completely different. Old workflow nodes were dead code. Graph nodes house agents that reason. ## 5 Prompts for Building Graph Nodes Each node does one job. These prompts are written to keep them that way. Prompt 1 — The bounded worker node Prompt 2 — The fan-out researcher Prompt 3 — The adversarial validator Run this on a different model than the one that produced the conclusion. Prompt 4 — The router Prompt 5 — The state reducer The node everyone forgets, and the reason graphs drift. That last rule — append-only state — is what makes time-travel debugging possible later. Overwrite state and you lose the ability to ask why the system did what it did. ## When the Graph Goes Wrong Problem: you built a graph for a task a loop would handle The most common mistake, and the most expensive. Five nodes and a state object for something a single call plus retrieval solves. > Fix: Anthropic's guidance is explicit — find the simplest thing that works and only add complexity when necessary. If you can't explain your graph on a napkin, it's too big. Many applications need a single call plus retrieval and no agent at all, let alone a graph. Problem: more nodes, no more certainty People hear "graph" and start stacking agents, assuming more nodes means more sophisticated. > Fix: the leverage isn't in how many agents you stuff in. It's in how much certainty you build around the results. One executor plus one genuinely independent validator beats six agents talking to each other. Problem: the validator approves everything Usually because it's the same model as the executor, or it's seeing the executor's reasoning. > Fix: different model, fresh context. The validator should see the conclusion and the evidence — never the chain of thought that produced them. If it sees the reasoning, it inherits the reasoning's blind spots. Problem: state grows until it's unusable Every node appends, nothing gets structured, and by node twelve the state object is bigger than the context window. > Fix: separate the five kinds of state. Execution state (current node, tool results) is short-lived and can be dropped. Loop state (iteration count, scores) is per-run. Task state (artifacts, candidates) persists through the run. User state and long-term state persist across runs. Only the last two need durable storage. Problem: costs are higher than the loop was Fan-out means parallel calls, and parallel calls all cost money. > Fix: measure cost per completed, verified task, not per call. A graph that costs 30% more per run but succeeds on the first attempt is cheaper than a loop that runs three times. If it's genuinely more expensive end-to-end, you probably over-fanned — not every step needs parallelism. Problem: it works but you can't explain why The failure the graph was supposed to eliminate, reintroduced. > Fix: checkpoints at every super-step and append-only state. If you can't replay a run from a checkpoint and get the same result, you don't have observability — you have a loop with extra steps. ## Where the 70% Actually Comes From The saving isn't one thing. It's four, and they compound. 1. Context stops accumulating. In a loop, round ten carries everything from rounds one through nine. In a graph, each node receives only what it needs. The researcher's raw search results never reach the writer. The writer's drafting process never reaches the validator. 2. Framework overhead disappears. The LangGraph-versus-AutoGen spread — roughly 2,000 tokens against 8,000 on the same task — is almost entirely inter-agent chatter. Agents restating context to each other. Graph structure turns that dialogue into state transitions. 3. Fewer full re-runs. A loop that self-approves a bad draft fails at delivery, and you re-run the whole thing. A graph with an independent validator catches the failure before it ships, and the conditional edge sends back only the writing node — not the research. 4. Model routing. Bulk work runs on K3. Only the validator — the smallest node — runs on Opus 5. A worked example. Daily research briefing, 1,000 runs a month. Substitute your own numbers. As a loop, everything on Opus 5: As a graph, K3 for work and Opus 5 for validation: Runs per acceptable output: ~1.15 — the validator catches problems, and the retry edge re-runs one node, not the pipeline. Kimi K3: 15M output tokens at $15/M = $225 Opus 5: 2.3M output tokens at $25/M = ~$58 Total: ~$283/month. That's a 75% reduction in this scenario — call it 70% once you account for the parallel calls that fan-out adds. The number that actually matters isn't cost per call. It's cost per completed, verified output. A graph can cost more per individual run and still be dramatically cheaper end to end, because it stops paying three times for the same deliverable. Run the same arithmetic on your own workload before you believe any of it. The structure of the saving transfers; the exact percentage depends entirely on how bad your current failure rate is. ## The Honest Verdict Is graph engineering a real shift or a new label on old ideas? Both. The naming is superficial. Nodes, edges, state, directed scheduling, state machines, multi-agent orchestration — computer science has worked on these for decades, and LangGraph, ADK, and AutoGen have shipped them for years. This term will most likely be buried by the next buzzword within months, exactly like loop engineering was. The shift is real. Three things converged: models became strong enough to act as reliable autonomous nodes, frameworks matured enough to connect them stably, and the community grew a shared vocabulary. The focus of engineering genuinely moved up a level — from coding a single agent's behavior to programming the organization of a group of them. Which leads somewhere slightly funny. After all this work on AI, what we ended up needing is the oldest discipline there is: how to run an organization. How to divide labor. How to define roles. How to separate who does the work from who checks it. How to keep the whole thing from collapsing when one part fails. Companies have been working on that for centuries. We just hired a new kind of employee and started asking the same questions again. ## Three Rules Before You Build Don't build a graph for the sake of it. If a loop does the job, use the loop. Start with a diagram you can explain on a napkin. Value comes from determinism, not agent count. Let the model judge, let code handle the fallback, and pair it with an independent set of eyes whose only job is finding faults. The graph must touch reality. Real anchor points — tests that pass, users who stay, money that arrives. Without them, no matter how sophisticated the engineering, you've built a more organized hallucination factory. Educational content. Framework token figures are drawn from published comparisons on specific tasks, not universal benchmarks. Measure on your own workload before committing to an architecture. ## Links - Kimi K3: https://www.kimi.com (https://www.kimi.com/) - Kimi Code CLI: https://github.com/MoonshotAI/kimi-code - LangGraph: https://github.com/langchain-ai/langgraph - Building Effective Agents (Anthropic): https://www.anthropic.com/engineering/building-effective-agents - Google ADK: https://google.github.io/adk-docs/ - My Telegram: https://t.me/kirillk_web3 - My Twitter/X: https://x.com/kirillk_web3 - Hosting (run agents 24/7): https://ishosting.com/affiliate/NzE0MiM2
