Graph Engineering

1 Why a graph beats one long chat

A single long conversation forces every piece of a big task through one context: the research, the counter-arguments, the drafting, the corrections — all stacked into one history that fills up with material irrelevant to whatever the model is doing right now. Two costs follow:

• No parallelism — steps that don't depend on each other still happen one after another.
• Polluted focus — every answer is generated in view of everything said so far, including dead ends and earlier wrong guesses.

A graph splits the work into separate steps, each run by its own agent with a clean, focused context, wired together by their real dependencies. Independent steps run at the same time; each step sees only what it needs.

2 Nodes and edges

A node is one unit of work with defined inputs and outputs: "research competitor pricing → a table", "draft the intro from these bullet points → two paragraphs". Because inputs and outputs are explicit, nodes can be reasoned about, reordered and swapped independently.

An edge is a dependency: this node needs that node's output before it can start. Edges encode ordering — and, just as importantly, their absence encodes freedom: if there's no path between two nodes, nothing stops them running simultaneously.

How to apply it: when decomposing a task, write each step as "input → output" and then ask of every pair: does B actually need A's output? Be strict — a dependency you invent out of habit ("research before any drafting") serialises work that could have run in parallel.

3 The diamond pattern, end to end

The workhorse shape for "should we do X?" questions. Five stages — it fans out from one node and converges back to one, hence the name:

Worked example — "Should we launch a paid tier for the app?"

1. Planner decomposes into independent sub-questions: What do competitors charge? What does our usage data say people would pay for? What's the build cost? What's the churn risk to free users? Good decomposition is the whole game: overlapping sub-questions waste effort, and a gap here becomes a blind spot nobody was assigned.
2. Researchers take one sub-question each, in parallel, each with a fresh context (lesson 7).
3. Skeptic attacks the findings (lesson 4).
4. Merge reconciles everything into one recommendation (lesson 5).
5. Human gate — a person decides (lesson 5).

4 The skeptic

Models default to agreeing. Ask one to "review" a set of findings and it tends to validate them; a pipeline of agreeable agents converges on a confident answer nobody ever stress-tested. So criticism has to be the assigned task of a dedicated node.

The skeptic's prompt is explicitly adversarial:

That framing produces a genuinely different pass over the same material than "please review". The skeptic doesn't decide anything — its output is a list of attacks for the merge to weigh.

5 Merge and the human gate

Merge is real work, not stapling. Concatenating the researchers' outputs isn't a conclusion. The merge node must reconcile contradictions between researchers, weigh the skeptic's attacks against the evidence, state what remains uncertain, and produce one coherent recommendation with its reasoning visible.

The human gate comes last, on purpose. The graph produces a recommendation, not a decision — a person approves or rejects before anything is acted on. Putting the human at the end means they judge a synthesised, already-criticised case in one sitting, instead of supervising every intermediate step. That's both safer (nothing irreversible happens without sign-off) and a better use of the human's attention.

6 Fan-out, fan-in, and barriers

Fan-out: one node splits into many parallel ones (planner → researchers). Fan-in: many converge into one (researchers → merge).

A barrier is a point where every parallel branch must finish before the next stage starts. Barriers cost real time: the whole graph waits for the slowest branch, so every fast branch's head start is thrown away.

How to decide: a barrier is justified only when the next stage genuinely needs all the results together — deduplicating findings across branches, comparing them against each other, or an early exit ("zero issues found → skip verification entirely"). If each item can flow on independently, let it: item A can be in stage 3 while item B is still in stage 1. "The stages are conceptually separate" or "it's tidier" is not a reason to synchronise them.

7 Independence: fresh contexts

Each researcher gets its own fresh context — its sub-question and the material it needs, nothing else — rather than sharing one thread. Two reasons:

• Focus — a shared thread makes every agent wade through everyone else's output; irrelevant material degrades attention.
• Anchoring — agents that can see an earlier agent's conclusion tend to echo it. Whatever was said first drags every later answer toward it. Separate contexts give you genuinely independent evidence — which is exactly what makes the skeptic's job, and any voting scheme, meaningful.

This is also why researchers run in parallel rather than in sequence: parallel isn't just faster, it guarantees no researcher saw another's answer.

8 Verification: votes and lenses

Findings from any single agent include some that are plausible but wrong. Two patterns to filter them:

Majority vote. Send each finding to N independent verifiers, each prompted to refute it (same logic as the skeptic — "try to confirm" produces agreement). Three verifiers, two say it's wrong → drop it. Don't keep it because one supported it, and don't re-run until they agree — disagreement is the signal.

Diverse lenses. Three identical verifiers share blind spots — they mostly repeat each other's misses. When a finding can fail in more than one way, give each verifier a different angle instead: one checks correctness, one security, one whether it actually reproduces. Diversity catches failure modes redundancy can't.

How to choose: identical refuters when there's one question ("is this bug real?"); diverse lenses when failure has several flavours.

9 Loops: discovering an unknown number of things

How many bugs are in this codebase? Nobody knows — so any fixed plan ("run 10 finder rounds") either stops early or wastes rounds. The loop-until-dry pattern lets the work decide: keep launching finder rounds until several consecutive rounds return nothing new, then stop. A single empty round isn't enough — finders are stochastic, and one dry round can be luck.

The classic bug in these loops is deduplication. Each round you must dedupe new findings against everything ever seen — not just the findings you kept. Dedupe against kept-only, and every finding your verifiers rejected gets rediscovered next round, re-verified, re-rejected... forever. The loop never converges.

10 Honesty, cost, and when not to bother

Report what you didn't do. If the graph reviewed 20 of 200 files, the output must say "180 files not reviewed". Silent truncation is the dangerous failure: a partial review reads as a complete one, and the human gate approves on a false premise. Any bound — top-N, sampling, skipped retries — gets surfaced.

The trade-off is real. A diamond might run a dozen agents where a chat runs one: many times the tokens and coordination overhead, bought back as coverage, independence, and stress-tested conclusions. That's worth it when the unknowns are genuinely parallel and being wrong is expensive.

So don't graph everything. "Summarise this email" through a diamond inherits all the overhead and none of the benefit. Rule of thumb: multiple independent unknowns + real cost of being wrong → graph. One obvious step → just ask.

▶ Good things to watch

Multi-agent orchestration is young, so there's no single canonical video course yet — these are the strongest starting points: