Graph Engineering: Stop Waiting on Agents That Don’t Need Each Other

Most agent demos look like a conga line. Step A finishes, step B starts, step C waits politely, and somewhere around step D you realize nobody needed the person ahead of them. You paid for serial latency on work that was always parallel.

That waste is not a model problem. It is an architecture problem.

I have spent the last few years drawing the line between Prototype and Shipped, and insisting on human gates before anything writes to a system of record. The same instinct applies to agent workflows: do not romanticize a loop that looks busy. Draw the graph. Stay the architect.

This post is inspired by — and builds on — @0xCodila’s Graph Engineering thread. I am rewriting the idea in product and advisory language, not pasting the thread.

The straight line is a tax

A straight-line agent workflow says: research → draft → review → synthesize. Fine for a single document with real dependencies. Terrible when you are auditing twelve route files for missing auth, or comparing three vendor options, or extracting fields from a batch of intake emails.

If step B does not consume a unique artifact from step A, the edge is fake. You are waiting for theater.

In product terms: every fake edge is idle time, context contamination, and a false sense of “the system is careful.” Careful is not the same as serial.

Loop Goodhart, and why graphs of loops beat one clever loop

Give a single agent a loop and a score, and it will optimize the score. That is Goodhart’s Law wearing a hoodie: when a metric becomes the target, it stops being a good metric.

One agent that writes code and then “verifies” its own work in the same chat will eventually learn to agree with itself. The loop looks rigorous. The evidence is circular.

The fix is not a smarter prompt. It is a graph of loops that watch each other:

• Workers fan out on independent units of work.
• A verifier runs with fresh context — not the worker’s chat history.
• Synthesis only sees verified findings, not vibes.

That is the same product pattern as a human approval gate on intake: the model proposes; a separate gate decides whether the proposal becomes truth.

Step 1 habit: real edges only

Before you add another agent node, ask one question: what artifact crosses this edge that the next node cannot get any other way?

If the answer is “shared vibe” or “so the pipeline looks complete,” delete the edge.

Real edges look like:

• File path → worker that only sees that file
• Worker finding → verifier that only sees the finding + the frozen rule set
• Verified findings → synthesizer that cannot invent new evidence

Fake edges look like:

• “Reviewer” that inherits the writer’s full transcript
• “Planner” that blocks unrelated parallel work
• “Final polish” that rewrites facts after verification

Draw the graph on a whiteboard. If two nodes have no data dependency, they should not wait on each other.

Fan-out, independent verifier, worker isolation

The pattern I keep returning to for audit-style work:

1. Fan-out. One worker per unit (file, route, ticket, property). Isolation beats a mega-context dump.
2. Independent verifier. Fresh context. Same frozen rules. No access to the worker’s chain-of-thought — only to claims and evidence.
3. Synthesize. Merge verified findings into a report a human can act on.

When the verifier reuses the executor’s chat, you get rubber stamps. That is the shared context trap: it feels efficient; it is how false confidence enters production.

In my interactive demo, you can flip that trap on and watch false positives climb. The simulation is honest about being a simulation — the lesson is not.

Worker isolation matters for the same reason feature flags matter. A bad worker should not poison the batch. Treat each unit of work like a blast radius you chose on purpose.

Anchors that refuse to move

Graphs without anchors drift. Anchors are the parts of the system that are not allowed to “improve” themselves mid-run:

• Tests that pass or fail without negotiation
• Evidence requirements (cite the line, cite the file, cite the log)
• Frozen rules for the verifier (auth must call requireUser, not “looks authenticated”)

Anchors are how you keep Prototype dem

When NOT to graph

Do not graph everything. Graphs cost coordination overhead, and overhead is a product decision.

Skip the graph when:

• There is one unit of work with a true sequential dependency
• Latency does not matter and a careful human is already in the loop
• You cannot name the artifact on each edge
• You are still discovering the problem (exploration beats orchestration)

A single well-instrumented loop with a human gate often beats a premature multi-agent diagram. Label it Prototype. Ship the smallest honest thing.

Product pattern: the human gate is a node

If you take nothing else: treat approval as a first-class node, not a UI afterthought.

In governed intake, that node is “Approve / Reject / Edit.” In graph engineering, that node is an independent verifier plus (often) a human synthesizer. Same idea: irreversible actions sit behind a gate that did not write the draft.

You stay the architect. The agents stay workers. The edges stay real.

Try it

I built a browser-only Prototype on the portfolio site: fan out over fake route files, toggle an independent verifier, and turn on the shared-context trap to see rubber-stamping in action.

Try the graph demo →

Related: governed intake demo · drjoshuaread.com

---

Inspired by / building on @0xCodila — Graph Engineering. Original prose; not a reprint of the thread.

os from pretending they are Shipped systems. The graph can be clever. The gate stays boring.

This is the same discipline as the intake triage demo: extract is allowed to be smart; write-to-store is not allowed until a human (or a hard policy) says yes.