Graph Engineering: Verification Is the Hard Part

There's a new piece of vocabulary spreading through AI-adjacent corners of the internet: graph engineering. If you've been half-following the agent workflow discourse, you've probably clocked it. And like most terms that emerge from practitioner communities before they get formalized, it's genuinely describing something real—while also carrying a fair amount of hype in its luggage.

A recent video from the AI Labs channel breaks the concept down in a way that's worth unpacking, because the interesting part isn't the graph structure itself. It's the verification problem that comes with it. That's where things get complicated, and where Anthropic has apparently been doing some thinking.

From Line to Web

To understand graph engineering, you need to understand what it replaced: loop engineering. The loop model is exactly what it sounds like. You hand an agent a goal, it does a piece of work, checks that work, then moves to the next step. Sequential. One thing at a time. As AI Labs describes it: "Everything runs in a straight line. So every step sits there waiting on the step before it even when the two have nothing to do with each other."

That sequential bottleneck is the problem graph engineering is designed to solve. Instead of one agent working through a task step-by-step, a graph splits the task into smaller pieces and assigns each piece its own agent—a node. Nodes run simultaneously. What connects them is an edge, which controls how data moves between nodes so each agent's output reaches the right place at the right time.

The speed gains are real. If you're building something that involves, say, simultaneously writing copy, reviewing design specs, running code tests, and checking against a style guide, a loop runs those sequentially. A graph runs them in parallel. The time difference can be significant.

The cost picture is more nuanced. AI Labs is upfront about this: you can save money per node by assigning cheaper models to tasks that don't require heavy reasoning. But the total token burn across a whole graph of simultaneously running agents is substantially higher than running a single agent through the same task. If you're on a subscription plan, your usage limits will arrive faster than you expect. On API pricing, the economics of graphs need careful consideration.

Two common graph shapes get explained in the video: the diamond, where one task fans out to parallel sub-agents that then funnel back into a single synthesis agent; and the fan-in at a barrier, where the same problem gets sent to multiple agents each examining it from a different angle, and nothing advances until all of them have reported back. Anyone who's used Claude Code's dynamic workflows has already encountered graph-style execution—the video notes this directly, pointing out that dynamic workflows are essentially graphs that people were running before they had the vocabulary for it.

The Part That Actually Decides Whether Any of This Works

Here's where the conversation gets interesting, and where the AI Labs video spends most of its runtime.

When you're running a single agent in a loop, catching errors is relatively manageable. The agent runs tests, reads error outputs, fixes them. But in a graph, errors compound in ways that are genuinely hard to trace. You get a finished result at the end, and if something's wrong, you don't necessarily know which node introduced the problem. "One error in a small part of the graph disturbs the entire output that comes back," as the video puts it, "and it's hard to track down because all you get at the end is the finished result."

This is the flaw the video's title references Anthropic addressing—and the fix, as detailed here, is less a single feature and more a philosophy: build your own verification, don't rely on defaults.

Claude Code ships with some built-in verification tools—a verify skill that checks code behavior end-to-end, tool chaining that lets agents run checks and fix errors they catch, and a code review skill that checks code against defined standards. These aren't nothing. But they have limits: they catch functional failures better than they catch quality problems, and they can't cover the full surface area of what "correct" means for a given project.

The deeper approach the video advocates is building custom verification skills using Claude Code's Skill Creator plugin, then deploying them strategically. Three types of skills come up:

Standalone skills run manually on finished work—deep, comprehensive reviews you trigger yourself once something is complete, not after every incremental step. The point is to go broad and thorough when it actually matters, not to fire a heavy review on half-finished output.

Embedded skills fire automatically as part of a running workflow. You build them to trigger after specific events—like a new feature implementation—so verification happens without requiring you to remember to ask for it. The catch: pre-installed skills have their logic locked inside the product. If you want automatic invocation, you build it yourself.

Chained skills with an orchestrator are what you end up with when you acknowledge that no single review covers everything. Each skill examines the work from a different angle—correctness, simplicity, style, design consistency. An orchestrator skill sits above them, spins up a separate agent for each, and consolidates the findings into one report. AI Labs notes that Anthropic's own team reportedly works this way, chaining code review, simplification, and verification skills together, plus a design skill that checks against a project's design specifications.

The Model Choice Is Not a Detail

The most practically useful part of the video is a case study from AI Labs' own work building a community website UI. They ran a review skill using Claude Haiku (Anthropic's smaller, faster, cheaper model) on the UI. It came back with a long list of flagged issues—looked thorough. Then they ran the same review with Opus (Anthropic's larger, more capable model). Fewer findings.

The naive reading: Opus did worse. The actual reading: Haiku had flagged things that were intentional design choices. It lacked the contextual reasoning to distinguish "problem" from "deliberate decision." Opus had read the surrounding code, understood the intent, and correctly left most of those things alone.

"So the cheap review hadn't saved us anything," the video observes, "because now the review itself needed reviewing."

Scale that to a graph with multiple nodes each running the same under-specified review skill, and you get a cascade: agents spending time and tokens fixing things that were never broken, across parallel contexts you can't easily inspect. "The node that does the judging is the one place where saving tokens costs you everything."

This is a real tension in agentic AI systems, and it doesn't resolve cleanly. The whole appeal of graphs is efficiency—faster, parallelized, cost-controlled per node. But the verification layer that makes graphs reliable is precisely where cutting costs backfires. You can't cheap out on the judge.

There's also an interesting epistemological point buried in the discussion of the "second opinion" skill—a custom skill that launches a fresh Claude session with none of the original context to review finished work. The reasoning: "The agent that built the thing is the worst possible one to review it. It's judging its own work off the same context it used to build it." A context-free second session has no prior commitments to the original decisions. It can actually evaluate rather than rationalize.

That's not a new insight—it's basically why code review exists as a practice in software engineering. But the implementation detail matters: the -p flag in Claude Code specifically launches a separate session in the background with no inherited context. It's slow, and the video is clear that model choice matters a lot here since you want the reviewer to be genuinely capable. But it's a concrete mechanism for the "fresh eyes" problem that plagues any self-reviewing system.

What to Make of All This

Graph engineering, as a paradigm, is real and the efficiency gains are genuine. The vocabulary is new; the underlying idea—parallelizing work across multiple agents—has been in practice long enough that people were doing it before they had a name for it.

The more interesting question is what the verification problem reveals about agentic AI systems in general. The harder you push on parallelization and autonomy, the more you need robust ways to catch errors that don't themselves become sources of noise. And those verification systems have to be built thoughtfully, tested on real work, and staffed with models capable of genuine contextual reasoning—not just pattern-matched against a checklist.

Anthropic's contribution here, at least as described in this breakdown, is less a breakthrough and more a formalization: here are the tools, here are the patterns, here's how the team that built the thing actually uses it. That's genuinely useful, even if it doesn't resolve the underlying tension between speed and reliability that defines the tradeoff at the heart of every graph.

The faster AI systems move in parallel, the more consequential it becomes to know which node got it wrong.

---

Yuki Okonkwo is the AI & Machine Learning Correspondent at Buzzrag.