Graph engineering is the term going around for designing the work around an AI, instead of pouring it all into one chat. Prompt engineering is the wording, context engineering is the inputs, and graph engineering is the shape. Jobs connected by arrows, some running in parallel, a checking step, a human approval before anything expensive happens. The idea is sound, and the diagrams are genuinely useful.
Almost every version of the diagram has a skeptic node, a box whose only job is to attack what the researchers produced. None of them specify which model sits in that box, and the answer you arrive at by convention is the one that breaks it.
What is graph engineering?
Graph engineering is designing an AI workflow as a set of connected jobs, instead of a single prompt. Each job has one owner and one output, arrows show what has to finish before what, and a shared record carries state between them. The vocabulary comes from graph theory, but the shape is just how work already happens on a team.
The framing was popularised in a recent episode by Greg Isenberg on the Startup Ideas Podcast, and it lays out the starter shape most people draw first. A planner splits a question into lanes, several researchers then work in parallel, and a skeptic attacks the findings. A merge step turns the survivors into a recommendation, and a human approves before anything happens. The output is still a written report, and what changed is that the work behind it was designed.
When a graph earns its place
Reserve the structure for work with multiple steps and multiple sources, or paths that do not depend on each other. Or something that has to grade the output, or real cost attached to being wrong, or a human sign-off. Brainstorming names does not need a graph, and deciding whether to spend a year building something does.
This is a close cousin of the workflow patterns already documented in AI agent workflow patterns, where the parallel-then-merge shape shows up as fanout-and-synthesize. The vocabulary is new and the structure is not, and that is fine. A useful name for a thing people were already building has value.
The square the diagram leaves blank
Look closely at any graph-engineering diagram and you find the same admission written into it. The skeptic exists for one reason: the writer cannot be trusted to grade the writing.
A lot of AI research fails because the same model that writes the answer also grades the answer. That is like asking someone to write their own performance review and then being shocked when they describe themselves as a visionary. In a good graph, checking is its own job.
Greg Isenberg, Startup Ideas Podcast
That is correct, and it is where the argument stops. Checking gets its own box, the box gets a name, and nobody says what goes inside it.
Every worked example carries a checking step, across a support graph, a content graph and a coding graph. The punchline is always that the checker is not the writer. True, and insufficient: not the writer is not the same as not the model. One is a change to the org chart; the other is a change to who is actually looking.
What the defaults actually do
This would be a pedantic distinction if the tools made the other choice easy. They do not. Take the path of least configuration in every commonly named implementation, and it puts the same model in both boxes.
Level 1: manual lanes
You run each job as its own chat or doc, and you are the state. Whatever model you are subscribed to answers the research prompt, and then it answers the skeptic prompt. Same weights, ten minutes apart, and nothing in the workflow tells you this is a problem.
Level 2: file trails
Each step writes its own file, so plan.md, customer.md and review.md leave a paper trail you can compare later. The trail is a real improvement, but review.md is produced by the same assistant that produced customer.md. The file names imply an independence the setup does not have.
Level 3: orchestrated
Frameworks give the skeptic a real node, with retries, state checkpoints and human-in-the-loop gates. There is no graph-level model setting for that node to inherit. That sounds like it should help, and in practice it does the opposite. The model is whatever the developer typed into the node. The ordinary pattern is one model instantiated at the top of the file, then reused in every node, including the checker.
So the diagram most people are drawing this week is a diamond. Its checker shares the writer's training data, the stale facts and the blind spots, and a measurable pull toward its own output. The ceremony of review, with none of the independence.
A different job is not a different reviewer
Splitting one model into a researcher step and a checker step changes the job title, not the reviewer. The same weights that produced the claim now evaluate it, and two separate effects push that evaluation toward approval.
It prefers its own answers
In our own 80-prompt MT-Bench test, GPT acted as judge, and it picked its own output about 70% of the time, against a 33% baseline for impartial judging. Claude and Gemini came in near neutral at 32.5% and 31.25%. The published literature confirms the effect exists, but it does not pin it to a clean number. So treat the direction as the citable finding rather than the figure. More detail on why in why AI can't check its own work.
It cannot report a tilt it does not notice
The sharper problem is a bias the model does not disclose. Work on value leakage (arXiv:2607.14345) found models quietly shaping answers toward their own preferences, while their stated reasoning claimed neutrality. A checker running on the same weights inherits that tilt, and by construction, it cannot flag it. This is the argument for cross-vendor checking that has nothing to do with quality rankings.
Note that these two effects rank the vendors differently, which is why they get named separately. Answer self-preference and undisclosed value bias are different failures, and a model that does well on one can do badly on the other. Collapse them into a single claim about which model is least biased, and the recommendation contradicts itself.
Notice the pattern. The skeptic node exists because one model grading its own work is unreliable, and then the default config hands that node back to the same model. That is exactly what TrueStandard does differently. Paste a draft, and four frontier models from four different labs check it in parallel. Sixty seconds, every disagreement surfaced.
Where a second vendor earns its cost
Cross-vendor everything is the wrong lesson, because more agents means more noise and more coordination cost. A graph that calls four labs at every node mostly pays for one privilege: it gets to read four versions of the same paragraph. The distinction that matters is whether a node produces work or judges it.
| Node | Second vendor? | Why |
|---|---|---|
| Planner | No | Splitting a question into lanes is generation. One capable model is fine. |
| Researchers | Diversity, not judgment | Different vendors here widen coverage. Each brings different training data. Cheap and worth it. |
| Skeptic | Yes, strictly | The only node where the rule is absolute. It must never run on the vendor that produced the claim it is grading. |
| Merge | Prefer a neutral vendor | Merging decides what survives. Use a model that did not author most of the surviving claims. |
| Human gate | Not a model | The point of the gate is that a person decides. Adding a model here reintroduces the problem the gate exists to solve. |
Spend the second vendor at the skeptic node and you have bought most of the available reliability. Spend it everywhere and you have bought latency.
The cheapest version of this is one extra call. Take the claim your research step is most confident about, hand it to a model from a different lab, and ask it to refute rather than review. TrueStandard runs that pattern across four labs at once, the same move at four times the coverage.
Wiring the skeptic node
Four changes, none of them large, in rough order of how much they buy you.
1. Record who wrote each thing
Stamp the authoring vendor onto every research output, in front matter or a field. Without it you cannot route around the author later. This is the step people skip, because it feels like bookkeeping. It is the step that makes the rest possible.
2. Exclude the author, in code
Make the routing rule real rather than a note in a prompt. When the skeptic runs, filter the candidate models down to those that did not produce the claim, and fail loudly if that leaves nobody. A convention you hope the prompt honours is not a control.
3. Ask it to refute, not to review
Review invites a summary; refutation invites an attack. Tell the skeptic to default to rejecting when it is uncertain, and to end with one specific check a human could run this week. That last line is usually the most useful output of the whole graph.
4. Count votes against survival
A claim that came back unparsed or from a failed call has not survived. Silence is not agreement, so treat missing verdicts as rejections. The merge step then stops inheriting claims nobody actually checked.
One caveat worth keeping. Agreement across four vendors is the strongest signal this shape can produce, and it is still not proof. Models that share a blind spot agree confidently and are wrong together. That is why one AI checking another narrows the error bar without closing it. Cross-vendor checking buys you a better class of uncertainty, not certainty.
That is the whole fix. The skeptic node was already in your diagram; it just needed a model that did not write the thing it is grading.
Frequently Asked Questions
Is graph engineering just a new name for agent orchestration?
Largely, yes. Directed graphs of jobs with dependencies are how workflow engines, business process modelling and DAG schedulers have worked for decades. Multi-agent frameworks have shipped this shape for years. The name is new and the structure is not, and that is a fair objection. What the name does add is a reason to draw the workflow before automating it. That catches the mistake of automating a process you have never run by hand.
Which model should run the skeptic node in an agent graph?
Any model from a vendor other than the one that produced the claim being checked. That constraint matters more than which specific model you pick. Say you have a preference beyond that: then pick models that score near neutral when judging, rather than favouring their own output, because they make better graders.
Can I just run the same model twice with a critic prompt?
It helps with structure and obvious slips, and it is better than no check. It does not give you independence. Running the same weights again varies the wording rather than the underlying judgment, so a confident factual error tends to survive both passes.
What is the difference between a knowledge graph and an agent graph?
A knowledge graph maps how information connects, so a system can reason across relationships instead of retrieving the nearest-looking paragraph. An agent graph maps how work moves, so a task has steps, checks and handoffs. Graph engineering discussions usually mean the second, and mature systems end up using both.
How many models does a verification step need?
Two different vendors gets you most of the benefit, because the value comes from non-correlated errors rather than from headcount. Three or four raises confidence on claims that would be expensive to get wrong, and beyond that you are mostly paying for agreement you already had.
Do LangGraph and similar frameworks default the skeptic to the same model?
Not by default, because there is no default to speak of. LangChain's docs are explicit that nodes are just functions, so nothing is inherited. Each node either hardcodes a model or receives one through runtime context, and that is what makes the outcome so common. The framework makes no choice for you, and the convention is a single model instantiated once and reused in every node. The checker node quietly ends up on the same weights as the writer. Per-node model selection is fully supported, and nothing prompts you to use it.
Does cross-vendor checking make an agent graph much more expensive?
Less than most people assume, if you spend it in one place. Adding a second vendor at every node roughly multiplies cost. Adding one at the checking step alone adds a small number of calls, and captures most of the reliability gain. That is the only node where independence changes the answer.
Is graph engineering worth learning?
The vocabulary is worth an afternoon. Draw one workflow you already run as jobs and arrows, then run it by hand once. That is the exercise that pays. Build a large automated graph before you have run the small manual one, and you produce mediocre work faster.
Keep reading
Multi-Agent vs Multi-Model AI in 2026
AI builders use both terms as if they meant the same thing. They are different architectures with different strengths. The difference matters most for the one job neither term sells: catching AI errors before you publish.
Which AI Uses the Most Em Dashes? Six Models Counted
We gave six models from Anthropic, OpenAI and Google the same 35 writing jobs, three times each. Then we counted every em dash, and 22 other tells, in all 629 drafts.
Long Context vs RAG in 2026
Three things just changed about how AI handles your documents. Here is what works for content teams, and why better retrieval still does not mean better truth.
AI Agent Workflow Patterns: When Each One Works (and When It Fails)
Six patterns cover almost every agent you'll build. Five are routine. The sixth, verification, breaks when you wire it with a single model, and most teams wire it that way.
Every Type of AI, Explained
From large language models to coding agents: what each type of AI does, which tools lead each group, and how to pick the right one for your work.
The Checker Shouldn't Be the Writer
TrueStandard is the skeptic node, run properly. Paste your draft, and four frontier models from four different labs check it in parallel, surfacing every disagreement. Sixty seconds.
Start Verifying →