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. 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. What none of them specify is 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 rather than 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, which lays out the starter shape most people draw first: a planner splits a question into lanes, several researchers work in parallel, 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. What changed is that the work behind it was designed.
When a graph earns its place
Reserve the structure for work with multiple steps, multiple sources, paths that do not depend on each other, something that has to grade the output, real cost attached to being wrong, or a human sign-off. Brainstorming names does not need a graph. 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. 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 reason the skeptic exists at all is that 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. Nobody says what goes inside it.
Every worked example of a support graph, a content graph and a coding graph carries a checking step, and 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. The path of least configuration in every commonly named implementation 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, then answers the skeptic prompt. Same weights, ten minutes apart. 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, and 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, which sounds like it should help. In practice it does the opposite: the model is whatever the developer typed into the node, and the ordinary pattern is one model instantiated at the top of the file and reused in every node including the checker.
So the diagram most people are drawing this week is a diamond whose checker shares the writer's training data, its stale facts, its 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. It does not change 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 picked its own output about 70% of the time when acting as judge, 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 without pinning 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, 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. Collapsing them into a single claim about which model is least biased produces a recommendation that 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, 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. More agents means more noise and more coordination cost, and a graph that calls four labs at every node is mostly paying for the privilege of reading 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, because 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, which is 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, and 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. Treat missing verdicts as rejections and the merge step 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, which 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, and multi-agent frameworks have shipped this shape for years. The name is new, 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, which 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. If you have a preference beyond that, models that score near neutral when judging, rather than favouring their own output, 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. 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. 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. That is what makes the outcome so common. The framework makes no choice for you, the convention is a single model instantiated once and reused in every node, and the checker node quietly ends up on the same weights as the writer. Per-node model selection is fully supported. 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, because that is the only node where independence changes the answer.
Is graph engineering worth learning?
The vocabulary is worth an afternoon. Drawing one workflow you already run as jobs and arrows, then running it by hand once, is the exercise that pays. The trap is building a large automated graph before you have run the small manual one, which produces mediocre work faster.
Keep reading
Multi-Agent vs Multi-Model AI in 2026
AI builders use both terms interchangeably. They are different architectures with different strengths, and the difference matters most for the one job neither term usually advertises: catching AI errors before you publish.
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 category, and how to choose the right one for your work.
What Karpathy's AI Methods Don't Fix
In six weeks, Andrej Karpathy and the AI builder community shipped three viral reliability methods. Each is real and useful. None of them solves the verification problem for writers.
3 AI Stress Tests from Q2 2026
When top AI builders ran real experiments instead of demos in April 2026, the results were more interesting than the demos. Here is what each test reveals, and why none of them fully answers the question writers care about.
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 →