The prompt was never the hard part. The graph is.
Agent engineering is becoming a real discipline, with real design decisions and real failure modes. Here is the shape we keep coming back to — and why it works the same way for a hiring loop as it does for a release pipeline.
TL;DR
Graph engineering is the discipline of splitting a problem across multiple AI agent context windows instead of one: deciding how work fans out, who verifies it, and how it converges. The reliable shape is five layers — orchestrate, fan out to parallel researchers, adversarially verify each finding, judge and deduplicate, then synthesize. It's the same loop whether you're screening candidates or reviewing a pull request.
There is a lot of noise right now about needing a framework, an orchestration layer, a DAG runner — some new piece of infrastructure — before you can put AI agents to work in parallel. For most teams that is backwards. The runtime is the easy part, and it is already sitting inside the tools you have. What is scarce is knowing which graph to run, and being able to tell a good one from a plausible-looking one.
That skill has a name now, and it is a direct descendant of something engineers have been doing for a while.
From prompts to graphs
Andrej Karpathy pushed the industry off the word "prompt engineering" for a reason:
"+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step."
— Andrej Karpathy, June 2025
Context engineering is what you do inside one context window. Graph engineering is what you do when you have many — how you split a problem across contexts, what each one is allowed to see, how their outputs get challenged, and how they collapse back into a single answer. It is the same discipline, one level up.
The primitives already have names. Anthropic's Building Effective Agents catalogues them: prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer. The graph below is mostly two of those composed together. Their finding on their own research product is the reason it is worth the trouble: a lead agent delegating to parallel subagents outperformed the same model working alone by 90.2% on their internal research evaluation.
Their conclusion about frameworks is worth quoting too, because it cuts against most of what is being sold right now:
"The most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."
— Anthropic, Building Effective Agents
The shape
Five layers and one feedback edge. Nothing here requires infrastructure you don't already have.
- Orchestration — decompose & dispatch. One agent turns a vague ask into N independent, non-overlapping sub-questions, decides how many are worth running, and assigns each a distinct angle. This is where quality is actually determined. Four agents given four genuinely different angles beat twelve agents given the same prompt twelve times — and cost a third as much.
- Research — fan-out — breadth. N agents work simultaneously, each in its own context window. The parallelism buys speed, but the real gain is compression: each agent burns through a large volume of raw material and returns only what matters, so the noise never reaches the main thread. This is the layer that scales, so it is the layer where model cost actually shows up.
- Adversarial verification — precision gate. Each finding goes to an agent whose only job is to break it. Not "review this" — refute this. The asymmetry matters: a weak researcher costs you a missed finding, which more researchers can recover. A weak refuter lets a false finding through with a verification stamp on it, which nothing downstream can recover. And a model checking its own family's output shares its blind spots — the most useful refuter is not the strongest one, it is the one that fails differently.
- Judging & dedup — the only real barrier. Everything that survived arrives here at once, because this is the one step that genuinely needs the full set: to merge duplicates found by different routes, to rank what is left, and to notice what nobody covered. If the kill rate was high or a whole angle is missing, it fans out again. Without that loop you have a pipeline, not a system.
- Synthesis — the answer. Compose the surviving material into the decision, the document, the plan. Everything discarded upstream is the reason this step is short.
Why this particular shape
Because it is the structure of a good decision, and it has been for a long time: generate options, try to kill them, commit to what survives.
Research is divergence — you want the widest possible set of candidates, including the ones you don't like. Verification is destruction, and it is the step humans skip, because we are much better at defending an idea we have already formed than at attacking it. Judging is convergence. The graph does not make the model smarter; it forces a sequence that keeps a single confident wrong answer from walking straight to the output.
Most bad AI output isn't a model failure. It's a missing verification step, dressed up as an answer.
The same loop, in six departments
Once you see the pattern as validate → challenge → commit, the domain stops mattering. What changes is what a "finding" is and what "breaking it" means.
Hiring
Fan out across candidates and signals. The refuter argues the case against each shortlisted profile. What survives is a shortlist with its objections already written down.
Marketing
Generate positioning angles in parallel; refute each against the actual market, the competitors, and the claims you can defend. Kill the ones that only sound good.
Sales
Research an account from several directions at once; the refuter attacks the qualification — wrong buyer, no budget signal, stale trigger — before anyone spends a call on it.
Project execution
Break a plan into workstreams, then run a pre-mortem agent per workstream whose job is to explain how it slips. Dependencies and risks surface before the kickoff, not after.
Software
Explore a codebase in parallel by subsystem; verify each finding adversarially before anything is written. Reviewing is cheaper than reverting.
Strategy
Several independent takes on the same decision, a contrarian one on purpose, then a judge that scores them. You get the runner-up's best argument instead of losing it.
What actually makes it work
The topology is the easy half. The parts that decide whether it produces something you can act on are unglamorous, and they are where the engineering lives:
What the verifier receives. Hand a refuter the researcher's full reasoning chain and you have anchored it — it now has to find a hole in an argument that already sounds finished. Hand it the claim and the raw sources only, and it has to reconstruct the path itself. Same graph, completely different output quality. This one detail moves results more than any model upgrade.
Knowing when not to fan out. Multi-agent runs consume roughly 15x the tokens of a single chat. That is worth it for high-value, open-ended, read-heavy problems, and it is pure waste for a task with one obvious path. Half of this discipline is recognising which one you have.
Where the barriers go. Every point where the graph waits for all branches is wall-clock you are choosing to spend. Some are necessary — judging is. Most aren't, and each unnecessary one makes the whole run as slow as its slowest branch.
Knowing what a run cost you. If you can't see which branch produced which claim and what it spent, you can't improve the graph — you can only regenerate it and hope.
None of this is new thinking. Fan-out/fan-in, idempotency, backpressure, designing for the failure case instead of the happy path — this is distributed systems engineering, and the instincts transfer almost intact. That's the part we didn't have to learn from scratch at Rather Labs: we had spent years building systems where correctness had to be structural rather than hoped for, and it turns out that is exactly the muscle these graphs require. The models are new. The discipline isn't.
The hard question was never can we run agents in parallel. It is which of your loops deserves it — which decisions in your company are made often enough, cost enough when they go wrong, and have a verifiable enough answer to be worth putting through a graph like this.
That question is specific to how a business actually operates, and it is by far the most interesting part of the work. If you're mapping it out for your own team, we're always up for comparing notes.
Frequently asked questions
What is graph engineering?
Graph engineering is the practice of designing how a problem is split across multiple AI agent context windows: how work fans out, what each agent is allowed to see, how outputs get challenged, and how they converge into one answer. It's a direct extension of context engineering, one level up — context engineering optimizes what goes into a single context window, graph engineering optimizes how many windows you use and how they connect.
What is the standard multi-agent pattern for AI systems?
A reliable shape is five layers: an orchestrator that decomposes the task and fans out to N parallel agents, a research layer that gathers findings in breadth, an adversarial verification layer whose only job is to try to break each finding, a judging layer that deduplicates and decides what survives (looping back to research if coverage is thin), and a synthesis layer that composes the final answer from what's left.
When is a multi-agent AI system worth the extra cost?
Multi-agent runs use roughly 15x the tokens of a single chat, so they pay off for high-value, open-ended, read-heavy problems — research, due diligence, code review, hiring decisions — where being wrong is expensive and there's enough material to make parallel exploration worthwhile. For a task with one obvious path, a single agent is faster and cheaper.
Get posts like this in your inbox