Graph Engineering: Anthropic Just Fixed Its Biggest Flaw

There's a new term going around called graph engineering, and it does more, faster, than any loop ever could.

Graph Engineering: Anthropic Just Fixed Its Biggest Flaw

There's a new term going around called graph engineering, and it does more, faster, than any loop ever could. It also has one serious flaw: a single error in one part of the graph can corrupt the whole output, and it's almost impossible to trace. Here's what graphs are, why they break, and the exact fix.

We build software, and we've been running agent workflows in production long enough to watch them evolve. First it was loop engineering, where you hand an agent a goal and it works toward it on its own. Now loops are turning into graphs, and graphs get the work done faster and cover far more ground at once. But they come with a problem that loops never had. One error in a small part of the graph disturbs the entire result that comes back, and it's hard to track down because all you get at the end is the finished output. This is the exact problem the verification approach below solves.

First, what a loop actually is

If you already know loops, skip ahead. A loop is a working cycle you hand to the agent. Instead of prompting it through every single step yourself, you give it the end goal and it gets there on its own, adjusting as it goes.

The limit is in how loops are built. A loop does a piece of work, then a verification step checks it, then the next step starts. Everything runs in a straight line, so every step waits on the one before it, even when the two have nothing to do with each other.

What a graph is, and why it's faster

Graph engineering fixes that straight line. Instead of running in sequence, a graph splits the main task into smaller parts and gives each part its own agent.

You get two things out of that. The first is speed, because several agents cover the work at once instead of one agent grinding through the whole thing. The second is some cost control per agent, because you get to pick which model each one runs on, so you stop burning your most expensive model on parts that never needed that much intelligence.

There's a catch, and it's a big one. That's the cost per agent, not the cost overall. A graph burns far more tokens than a single agent ever will, because you've got a whole set of them running at once. Expect your usage limits to hit much sooner than you're used to, which means you can't really run this on the $20 plans of Claude Code or Codex.

If you've used Claude Code, you've already seen a graph without calling it one: the dynamic workflow, which fans a task out across a set of sub-agents.

Takeaway: A graph trades tokens for speed and coverage. Use it when the work splits cleanly into parts, and don't try to run it on an entry-level plan.

Nodes and edges

Every graph is built out of two things.

A node is a single job out of the bigger task. It's an agent that does that job in its own isolated context window and reports back. An edge controls how data moves from one node to the next, so one agent's output lands with the right agent at the right point. Every node has to be tied into the rest of the graph somehow.

You can picture it with a set of agents all reviewing the same piece of work. None of them wait on each other, but they all start from the same input, and every one of their reports feeds into the same place at the end.

The shapes a graph takes

The diamond. One task at the top splits into several sub-agents running side by side, then they all narrow back down into a single agent that pulls everything into one answer. (We showed this shape on the channel before graph engineering was even a term, and we called it a loop at the time. It was actually a graph we were looping.)

Fan-in at a barrier. This is the shape you want when one thing has to be judged from several angles at once. The same problem goes out to a set of agents, each looking through a different lens. Nothing moves forward until every agent has reported back, and only then does it run their fixes.

There are other shapes too, but they all rest on the same thing: verification. Set those checks up wrong and every agent that comes after is just building on top of a mistake.

Why graphs break at scale

Once you're running a whole fleet of agents, things go wrong in ways they never do with one. The first problem is the sheer amount of work. Everything runs at once, so a huge pile comes back together and it's hard to review at the end. The second is visibility. When something goes wrong, you've got no clean way to tell what caused it.

Every agent verifies what it writes whether you ask it to or not. For code, that means running your tests and catching the errors that come back. But that only catches major errors. It doesn't check how the code is written, which matters, because sloppy code compounds into problems later.

Claude Code ships with a few built-in helps:

• The verify skill, which takes the code end to end and confirms it behaves the way it's supposed to.
• Tool chaining, where the agent runs the tools that check your work, reads the errors, and fixes them itself. It can work out your project's commands on its own, though writing them into your Claude.md file saves it the trouble every time.
• A code review skill, which checks code against a set of standards. Not every agent ships with one, but you can ask your agent to build you one.

The verification that works best, though, is the one you set up yourself instead of leaning entirely on the built-in stuff.

Build your own with Skill Creator

The fastest way to build a verification skill is the Skill Creator plugin in Claude Code (which also works in Codex). Run the plugin command, search for skill creator, and install it. You can install at user scope (available in every folder) or just for the current project. Since you'll use this constantly, user scope makes sense. Reload the plugins with the slash command and it's ready.

Then you tell it what to build. We mostly use a review skill that checks the finished work against what we asked for in the first place, and that matters more in a graph, because each agent only ever sees its own piece. This gives it a way to check that piece against the original requirements.

The judging node decides everything

A skill is only ever as good as the model you run it on. When we built the verification system for our community website's UI, we ran the reviewer on Haiku, because it's cheap and the job looked simple. It came back with a long list of issues, and going off the count alone, it looked great. Then we ran the same review on Opus, and it flagged far fewer things. That looked worse, right up until we read the reasoning. Most of what Haiku reported was stuff we'd left there on purpose. Opus had worked that out from the surrounding code, which Haiku missed completely. The cheap review hadn't saved us anything, because now the review itself needed reviewing.

Put that inside a graph, where a whole set of nodes are all checking their work with that same skill, and you'd have agents burning time and tokens fixing things that were never broken, with no way to tell which one started it.

Takeaway: The node that does the judging is the one place where saving tokens costs you everything. Put your best model there.

Three kinds of verification skill

How and when a skill gets invoked splits them into three kinds.

Standalone. Runs only when you trigger it yourself. It's built to go deep on something that already exists, so you don't want it firing after every run and burning tokens on work that isn't finished. A good example is a comprehensive code review that fans out a set of agents, each going through the code from a different security angle, with every finding landing in one place. Build these with Skill Creator rather than a raw prompt, because what comes back is tested and easier to trust. Tell it which area to review and say the review should be comprehensive, so it knows you want a deep pass.

Embedded. Fires as part of a workflow you're already running, without you asking. You could build one that kicks in whenever someone requests a new feature, checks that every component follows your rules, and won't let the implementation finish until it's been checked. You can't take a pre-installed skill and have it auto-invoke like this, because those instructions live inside the product. To build your own, tell Skill Creator to run verification steps after every feature implementation, testing the feature end to end so it catches whether new work broke anything that already worked. For UI, Claude verifies with browser testing by default, opening a full Chrome browser and taking screenshots. Chrome is heavy and slow to run over and over, so use Chrome headless shell, a stripped-down version that does the same thing much faster. Build that straight into the skill.

Second opinion. The agent that built something is the worst one to review it, because it's judging its own work off the same context it used to build it. A fresh Claude session hasn't seen any of that, so it gives an unbiased read. Second opinion starts another Claude session from inside the one you're running, using the -p flag (which fires off a separate Claude Code session in the background with a prompt to work on). Two things to know: it takes a while to come back because it's a whole separate session, and the model matters more here than anywhere, so tell Claude explicitly to start that session on Opus.

Chain them, then orchestrate

One skill can't cover everything. A proper review looks at the work from several angles, and each angle has its own way of measuring. Stuff every review type into one skill and the agent has too many directions at once, so the review gets worse, not better. Build a separate skill for each angle and chain them together.

Anthropic's own team works this way. They chain the code review skill with the simplify skill and the verify skill (all three now ship with Claude Code), and add their own design skill that checks the interface against the design.md file, the file that holds every design decision for the product. That's a review coming from four directions instead of one.

The last piece is an orchestrator skill whose only job is to run other skills. It spins up an agent for every review skill you've got, hands each one its skill, and lets them all review at the same time in their own context windows. Then it pulls every finding into one report the fixing agents can work from. When you build a graph, the only thing you have to say in the prompt is to use that one skill. Every node loads it, and the whole review fans out underneath on its own.

Takeaway: Don't cram every check into one skill. Build one per angle, then put an orchestrator skill above them so every node runs the full review by loading a single skill.

FAQ

What's the difference between a loop and a graph? A loop runs step by step in a straight line, each step waiting on the last. A graph splits the task across agents that run in parallel, which is faster and covers more ground, at the cost of far more tokens.

Why do graphs fail in ways loops don't? Because a single node's error corrupts the shared output, and with many agents running at once, you can't easily see which one caused it. Verification at each node is what keeps that from happening.

Can I run graphs on a $20 plan? Not really. A fleet of agents burns tokens fast, so your limits hit much sooner. Graphs assume a higher usage tier.

Which model should the reviewing node use? Your best available one. A cheap model on the judging node produces noisy reviews that cost more time to sort through than they save. Save tokens elsewhere, not there.

Standalone vs embedded vs second opinion? Standalone runs when you trigger a deep review of finished work. Embedded fires automatically inside a workflow. Second opinion launches a fresh, unbiased session (ideally on Opus) to review work the building agent is too close to judge.

Resource prompt

Paste this into Claude Code with Skill Creator installed to build an orchestrator that runs your review skills across a graph:

Using Skill Creator, build an orchestrator skill whose only job is to run my review skills in parallel.

It should:

1. Spin up a separate agent for each review skill I list below, each in its own context window.

Review skills: [e.g. code-review, verify, simplify, design-check]

2. Run them all at the same time, not in sequence.

3. Collect every finding into a single report that a fixing agent can act on.

4. Be safe to load on every node of a graph, so that referencing this one skill

fans the full review out underneath it.

Make the skill tested and self-contained, with references and scripts included.

The full verification playbook for graphs, plus every skill shown here, lives inside AI Labs Pro.