Updated July 26, 2026. This article was prepared by the AI Dawn editorial team based on primary technical sources and the original X Article.
Graph Engineering, or AI agent graph engineering, is the design of one or more agents as an executable graph: nodes perform limited tasks, edges pass data and define real dependencies, checks filter out errors, and external signals confirm the result. This approach is not for every prompt. It pays off when a task can be split into at least two independent streams, run in parallel, and then combined in a controlled way.
The main advantage of a graph is not "more intelligence," but controlled breadth: less unnecessary waiting, separate contexts, explicit contracts, and a visible point of failure. The main risk is mistaking agents’ internal agreement for truth. That is why a good graph relies on tests, documents, transactions, expert approval, and other external anchors, and also has limits on time, cost, and number of attempts.
In short: first map the current process, remove false edges, identify the critical path, give each node an input and a structured output, add an independent verification step, and only then increase the number of agents.
Contents
- Why everyone is talking about Graph Engineering
- What an AI agent graph is
- Graph Engineering, loop engineering, and prompt engineering
- False-edge test
- Critical path: where the speedup comes from
- Diamond pattern: fan-out, reduce, verify, synthesize
- Node contract
- Why the executor should not verify itself
- External truth anchors
- Where graphs break down
- When a graph is not needed
- Observability and cost control
- Bun case study: 64 agents and the cost of extreme parallelism
- How to build your first graph in 7 steps
- Three ready-to-use specifications
- How to choose a tool
- FAQ
- Bottom line
Why everyone is talking about Graph Engineering
In July 2026, the new term spread after a brief remark by developer Peter Steinberger about moving from loops to graphs. Anatoly Kopadze expanded the idea in a long X Article on Graph Engineering: he explained nodes and edges, introduced the "false-edge test," showed the diamond pattern, and warned about the cost of agent fleets.
The name is new, but the engineering foundation is not. Dependency graphs have been used for decades in compilers, schedulers, ETL, CI/CD, and business process management systems. The novelty in 2026 is different: LLM agents have become autonomous enough to serve as executors for individual nodes, and orchestration tools have learned to create and coordinate those nodes dynamically.
Anthropic described the same building blocks earlier: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. In the official guide Building Effective AI Agents the company recommends adding complexity only when it measurably improves results. Microsoft Agent Framework, in turn, explicitly defines a workflow as a system that connects executors and edges in a directed graph.
That is why Graph Engineering is useful to think of not as new magic or as a replacement for loops. It is a convenient name for a discipline that makes the following explicit:
- task decomposition;
- dependencies and parallelism;
- state transfer format;
- roles of executors and verifiers;
- external criteria of truth;
- retries and stopping conditions;
- budget, access rights, and human approval gates.
What an AI agent graph is
A graph consists of nodes and edges.
A node is one limited task. For example: collect a competitor’s official prices, check a link, run tests, classify a request, or write a report section.
An edge is a dependency that passes a result or control signal from one node to another. If node B cannot start without A’s output, there is an edge A → B. If B does not use A’s result, the sequence may be a habit rather than a dependency.
In practice, it helps to add four more concepts:
| Concept | Meaning | Example |
|---|---|---|
| State | data from a specific run | a list of found documents and their dates |
| Transition condition | the rule for choosing the next edge | if confidence is below 0.8, send it for recheck |
| Gate | an automatic or human decision | publish only after editor approval |
| Anchor | an external verifiable signal | HTTP 200, passed test, CRM record, bank transaction |
Not every graph is a DAG. DAG stands for directed acyclic graph, a directed acyclic graph with no return to a previous node. It is suitable for a finite pipeline: research → brief → draft → audit → publish. If the verification result goes back to the executor for correction, a cycle appears. A production workflow often combines a top-level DAG with local loops inside individual stages.
You can use the same LLM provider in every node and still have a graph. Conversely, ten agents in one shared chat do not necessarily form a good graph: without explicit contracts, isolation, and transitions, it may just be one long conversation with several voices.
Graph Engineering, loop engineering, and prompt engineering
These approaches answer different questions and do not cancel each other out.
| Level | Main Question | Design Unit | When It’s Useful |
|---|---|---|---|
| Prompt engineering | how to phrase a single instruction | prompt | limited single response |
| Context engineering | what data and rules to give the model | context | a complex task in one session |
| Loop engineering | how to repeat an action until the readiness criterion is met | the action → verification → correction cycle | one mutable artifact or open-ended search |
| Graph Engineering | which tasks depend on each other and who reviews them | a network of nodes, edges, and gateways | a broad process with parallel branches |
A loop is great for the task “keep fixing the code until the tests pass.” A graph is needed when backend, frontend, security, and documentation are all being checked at the same time, and then the results come together in a single release decision.
Inside a graph, cycles almost always remain. A researcher may repeat a search until they find two independent primary sources. A coder may fix an implementation based on test results. A reviewer may send a finding back for rework. Graph Engineering defines how several such loops are connected, where they can run in parallel, and what condition stops them.
False-Edge Test
The most practical point from Anatoly Kopadze’s original article is to test every sequential pair with the question:
Does the next step need the actual result of the previous one?
If yes, the edge is real. If not, the waiting is probably artificial.
Suppose the process is written like this:
- check file A for vulnerabilities;
- check file B for vulnerabilities;
- check file C for vulnerabilities;
- compile the report.
Checks A, B, and C do not use each other’s results. There are no edges between them; they can start at the same time. The real edges go from each check to the merge node.
But you can’t apply this test only to prompts. Two nodes may not exchange text and still depend on each other through a shared resource.
| Hidden Dependency | What Can Happen | Correct Solution |
|---|---|---|
| one file or Git branch | overwriting changes | separate worktrees or a sequential merge |
| shared API rate limit | a cascade of 429 errors and retries | global semaphore and backoff |
| one database record | race condition | transaction, lock, or queue |
| shared budget limit | unpredictable overspend | centralized budget gate |
| dependent business invariant | two locally correct solutions conflict | shared contract and integration test |
So the expanded test sounds like this: Does the next node use the result, mutable state, limit, or resource of the previous one? If yes, the dependency is real, even if no data is passed in the message.
The Critical Path: Where the Speedup Comes From
A graph does not make every node faster. It reduces total wall-clock time through parallelism.
For a linear chain, the time is roughly equal to the sum of durations:
Tlinear = T1 + T2 + ... + Tn
For an ideal parallel layer, the time approaches the slowest node plus overhead:
Tlayer ≈ max(T1, T2, ... Tn) + Toverhead
The total time of the graph is determined by the critical path — the longest chain of real dependencies in time. That is what should be optimized first.
Consider an estimated scenario, not a measured benchmark. Four research tasks take 60, 80, 90, and 120 seconds, verification takes 40 seconds, and synthesis takes 60 seconds.
- linear run:
60 + 80 + 90 + 120 + 40 + 60 = 450 seconds; - parallel research:
max(60, 80, 90, 120) + 40 + 60 = 220 seconds; - theoretical speedup: about
2.05×excluding orchestration overhead.
The promise that any 40 steps can be sped up from five minutes to fifteen seconds is not valid without profiling. If 35 steps truly depend on one another, the graph will help very little. If 35 are independent but the external API allows only five concurrent requests, the limit will be set by the rate limit. A graph shows potential parallelism; it does not remove physical constraints.
The diamond pattern: fan-out, reduce, verify, synthesize
The basic form of a useful graph looks like a diamond:
PLAN → FAN-OUT → REDUCE → VERIFY → SYNTHESIZE → HUMAN GATE
Plan
The orchestrator breaks a goal into independent angles. For market research, these could be demand, competitors, pricing, regulations, and technical constraints. The angles must be mutually distinct; five identical prompts create expensive voting, not broad research.
Fan-out
Worker nodes run in parallel. Each one gets only the minimum context it needs, its own role, and a structured response format. This approach reduces cross-contamination from assumptions and does not flood the main session with raw data.
Reduce
Deduplication, sorting, counting, and schema validation are better handled in regular code when the operation does not require judgment. An LLM is not needed to remove exact duplicate URLs, check required fields, or count the number of results.
Verify
A separate node tries to disprove the finding: it opens the source, checks the date, and verifies that the citation matches the claim. For code, this node can be a test runner or static analyzer. For finance, it can be a reconciliation with the accounting system. For content, it can be a fact-checker with access to primary sources.
Synthesize
The final agent receives not the entire raw stream, but verified and normalized results. Its job is to assemble a single answer without adding unconfirmed facts.
Human gate
A human approves a risky action: publishing, a payment, a production change, sending to a client, deleting data, or a legally significant decision. Automating preparation does not mean automating final accountability.
Node contract
A node becomes composable when it has a contract. A minimal contract answers nine questions.
| Field | Question |
|---|---|
| Job | what single job does the node perform? |
| Input | what fields does it receive and from where? |
| Output | what schema must it return? |
| Tools | which tools and data does it have access to? |
| Success | what counts as success? |
| Timeout | how much time is allowed? |
| Retry | which errors should be retried, and how many times? |
| Side effects | what can the node change? |
| Evidence | what external signal is attached? |
Example of a pricing research node:
| Field | Value |
|---|---|
| Job | get the public price for one plan |
| Input | competitor, official_url, currency |
| Output | price, period, currency, source_url, checked_at, confidence |
| Tools | browser, read-only |
| Success | price and period found on the official page |
| Timeout | 90 seconds |
| Retry | one retry on network error |
| Side effects | none |
| Evidence | page URL and verification date |
Free-form text remains useful inside a node, but it is better to emit a typed object on the edge. If a field is missing, the orchestrator can rerun the node or mark the result incomplete. If a "wall of text" is passed along the edge, the next agent is forced to guess the structure again, and the graph loses determinism.
For nodes with side effects, idempotencyis required: a retry should not charge money twice, create a duplicate order, or send the same email. Usually this is handled with an idempotency key, a unique run ID, checking current state, and a log of completed actions.
Why the executor should not check itself
Separating the executor from the verifier lowers risk, but the statement "they should never share context" is too absolute. The problem is not context transfer itself, but correlated error: the verifier accepts the executor's original assumptions and evaluates plausibility instead of the result.
Practical rule:
- the verifier does not receive the executor's hidden reasoning or belief history;
- it receives a verifiable artifact, criteria, and the minimum necessary source data;
- it independently calls tools and opens sources;
- uses a different prompt, role, or model when possible;
- returns evidence, not just
PASS.
For text, three independent lenses are useful:
- Correct — does the statement match the source?
- Current — are the date, version, and price up to date?
- Credible — is this a primary source, and does it actually exist?
Majority vote does not turn an opinion into a fact. Three LLMs can make the same mistake. That is why a verifier has to rely on an external signal: open the URL, run the test, reproduce the calculation, compare the record with the source system.
External truth anchors
A graph can be perfectly consistent and completely wrong. This happens when all nodes verify reports produced by the same pipeline.
Truth anchor — a signal outside the model’s reasoning that cannot be improved with prettier wording.
| Area | Weak check | Strong anchor |
|---|---|---|
| Code | “the implementation looks correct” | the test actually ran, exit code 0 |
| SEO | “keywords are naturally integrated” | valid HTML, canonical, schema, and a public HTTP 200 |
| Sales | “the lead is qualified” | the customer confirmed the need or paid |
| Finance | “the amounts match in the agent’s report” | reconciliation with the bank and accounting system |
| Support | “the response should help” | the ticket is closed with no repeat contact during the specified period |
| Research | “the source is authoritative” | the primary document contains a specific claim |
Some constraints must be immutable for the optimizer: no publishing without a human, a spending cap, a list of unavailable secrets, and no changing tests just to get a green result. If an agent can loosen the criterion by which it is judged, it can optimize the metric instead of the goal.
That is exactly why, when implementing AI in business processes the first step is to define the boundaries and the outcome metric, and only then choose the model and orchestrator.
Where graphs break down
1. Context collapse at fan-in
One thousand worker nodes can produce more text than the final synthesizer can accept. The solution is hierarchical aggregation: split results into batches, normalize each one, create intermediate summaries, and only then perform the final merge. Raw evidence is stored separately and available via links.
2. False independence
Agents work in the same directory, update the same record, or compete for the API limit. The solution is workspace isolation, file ownership, transactions, queues, and global concurrency caps.
3. Silent node loss
One of 200 workers fails, but the final report looks complete. The merge step must know expected_count, received_count, the list of missing items, and the completeness policy. If a required node did not return, the system has no right to call the set complete.
4. Retry cascade
When a temporary error occurs, 50 nodes all retry three times and intensify the overload. You need exponential backoff, jitter, a shared circuit breaker, and a limit on simultaneous retries.
5. Uncontrolled loop
The verifier sends the work back for correction, but the success criterion is unreachable or vague. You need max_iterations, a deadline, a cost limit, and a NEEDS_HUMANstate.
6. State drift
Different nodes use different versions of the source data. You need an immutable snapshot, schema version, timestamp, and lineage: which input produced a specific output.
7. Boundary failure
Each node passes validation locally, but the overall system does not work. Contracts must be supplemented with integration and end-to-end tests. Quality of parts does not guarantee quality of composition.
8. Prompt injection through sources
The researcher reads a web page that contains instructions for the agent. External content must be treated as data, not commands; tools, the network, and secrets must be restricted on a least-privilege basis. Anthropic separately emphasizes the importance of sandboxing and filesystem and network isolation.
9. Automation of the wrong goal
The graph perfectly optimizes the number of tickets handled, but customer satisfaction gets worse. Metrics should include outcome quality, cost of error, and negative guardrail metrics.
When a graph is not needed
Graph Engineering creates overhead: orchestration code, schemas, state storage, tracing, retries, conflict resolution, and extra token spend.
Keep one agent or a simple loop if:
- the task is small and isolated;
- all steps are truly sequential;
- you are still exploring the problem and often changing direction;
- there is no objective quality criterion;
- the coordination cost is higher than the time for manual work;
- each stage requires a human decision;
- there is not enough data for a stable contract.
Use a graph if:
- there are at least two independent branches;
- one context cannot fit the task;
- different roles or access permissions are needed;
- the result can be automatically verified;
- missing a separate branch must be detected;
- audit trail and reproducibility matter;
- the time or quality gain outweighs the extra cost.
| Situation | Recommended form |
|---|---|
| fix one small bug | one agent + test |
| improve text to editorial quality | evaluator-optimizer loop |
| check 100 independent files | fan-out → verify → merge |
| investigate an unknown problem | orchestrator-workers with a limit |
| make a payment | deterministic workflow + human gate |
| prepare a report from five sources | diamond graph |
Observability and cost control
Without tracing, a graph turns into an expensive black box. For each run, save:
run_id, goal, and graph version;- input snapshot and run owner;
- start, end, and latency for each node;
- selected model and number of tokens;
- node cost and total run cost;
- retry count and failure reason;
- prompt version and output schema;
- edge transitions;
- expected/received counts at merge;
- verifier evidence;
- human decisions;
- final status: success, partial, failed, cancelled.
Four budgets are useful:
- Concurrency cap — the maximum number of concurrent nodes.
- Token/cost cap — the ceiling for tokens or dollars per run.
- Time cap — the overall deadline and node timeout.
- Iteration cap — the maximum number of loopbacks.
Parallelism reduces calendar time, but it usually does not reduce the amount of work. Sometimes spend even rises because of retries and verification. Economically, a graph makes sense when the value of shorter time, greater completeness, or lower risk is higher than the additional inference cost and orchestration overhead.
Model routing helps: a cheap model for classification and extraction with a strict schema, a stronger one for ambiguous judgment and synthesis, and regular code for deterministic operations. For more on controlling inference cost, see our article how to control LLM spend.
Bun case: 64 agents and the price of extreme parallelism
The most notable example in July 2026 was the port of the Bun JavaScript runtime from Zig to Rust. In the official Bun analysis of the project, about 535,496 lines of Zig were ported using roughly 50 dynamic workflows, up to 64 Claude instances worked in parallel, and the effort took 11 days. Before merge, 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads were used; the API-price equivalent was estimated at about $165,000.
This case should not be retold as “64 agents rewrote a million lines by themselves.” The important conditions were:
- the source system already had behavior that needed to be preserved;
- there was a large test suite and more than a million assertions;
- the Rust compiler and tests provided external signals;
- the work was prepared with porting instructions and conventions;
- a human designed the workflow, monitored it, and handled failures;
- mechanical porting is different from building a product with uncertain requirements;
- the quality and volume of AI-generated code drew public professional criticism.
The port is notable not for the number of agents, but for the role of the harness. When the task is split by file, the compiler quickly returns errors, tests lock in behavior, and workers are isolated, a broad graph can sharply reduce wall-clock time. Without those anchors, 64 agents scale uncertainty, not productivity.
Additional technical details, including token statistics, the test harness, and porting constraints, are covered in the Bun team’s original analysis linked above.
How to build your first graph in 7 steps
Step 1. Choose one measurable process
Don’t start with “automate marketing.” Pick a finished deliverable: a comparison report on five competitors, an audit of twenty route files, or a draft article with verified sources.
Record the baseline: how long the process takes, how much it costs, and where errors occur. Without a baseline, you cannot prove the graph is useful.
Step 2. Map the current chain
Write each step as a verb and noun: “collect queries,” “open documents,” “check dates,” “group findings.” Do not assign agents yet.
Step 3. Audit the edges
For each pair, ask whether the result, state, resource, or limit of the previous step is needed. Put independent nodes in one parallel layer. Mark hidden dependencies separately.
Step 4. Identify the critical path
Estimate node latency and find the longest dependent chain. Do not parallelize everything blindly: first remove delays on the critical path.
Step 5. Write the contracts
Define the input/output schema, tools, permissions, timeout, retry, success criteria, and evidence. One node — one job. If the description contains five independent verbs, split it.
Step 6. Add a verifier and a human gate
The verifier receives the artifact and verifiable criteria in a fresh working context. Risky side effects stay behind human approval.
Step 7. Run a limited pilot
Set caps: for example, 5 workers, 20 objects, 2 retries, 15 minutes, and a fixed budget. Compare latency, cost, completeness, and error rate against the baseline. Expand the graph only after you win at small scale.
Pilot Rule for the AI Dawn: start with one process, one owner, one external success criterion, and one safe stop path.
Three Ready-Made Specs
Below are not magic prompts, but compact technical requirements. They need to be adapted to the tool and access permissions.
1. Research Graph
| Field | Specification |
|---|---|
| Goal | prepare decision-grade research on the topic |
| Fan-out | 5 non-overlapping angles, one researcher per angle |
| Contract | each point: claim, source_url, source_type, date, confidence |
| Reduce | remove duplicate URLs and group identical claims with standard code |
| Verify | independently open the source and try to disprove the claim |
| Fan-in | combine only confirmed points, keeping the links |
| Gate | a human approves the conclusions before external delivery |
| Caps | 5 workers, 2 retries, 30 minutes, fixed budget |
2. SEO Graph
| Field | Specification |
|---|---|
| Goal | prepare a publish-ready article on the topic |
| Fan-out | keyword intent, SERP, competitors, content gaps |
| Merge | a brief with a unified structure and source plan |
| Draft | one writer creates a coherent draft |
| Verify | links, dates, numeric claims, title promise, schema |
| Audit | CORE-EEAT gate: SHIP/FIX/BLOCK |
| Gate | publishing is allowed only after SHIP and human approval |
| Evidence | the public page returns 200 and contains an H1 |
That is exactly how the current seo-pipeline-v2: it connects research, writing, GEO optimization, metadata, schema, and audit, but does not allow publishing when FIX or BLOCK.
3. Repository Audit
| Field | Specification |
|---|---|
| Goal | find route files without authorization checks |
| Discovery | list files deterministically |
| Fan-out | one read-only reviewer per file in an isolated context |
| Output | file, route, auth_check, evidence_lines, severity |
| Verify | a separate reviewer confirms the finding |
| Merge | compare expected and received file count |
| Side effects | no changes |
| Gate | a human selects the fixes |
This kind of graph is safer than the request “find and fix all security issues”: first it produces a verifiable report, and code changes become a separate controlled run.
How to Choose a Tool
Graph Engineering is an architectural approach, not a specific product. You can start with a simple script and a task queue.
| Level | Suitable for | Limitation |
|---|---|---|
| One script + LLM API | pilot, fixed DAG | state and retries must be implemented |
| Claude Code subagents / agent teams | research and repository work | sandbox, worktree, and permission controls are required |
| Microsoft Agent Framework / AutoGen GraphFlow | typed multi-agent workflows | additional infrastructure and a learning curve |
| LangGraph and similar runtimes | stateful graphs, branching, checkpoints | the risk of premature complexity |
| Temporal, Airflow, Dagster + LLM nodes | critical business processes and mature ops | LLM-specific logic has to be added manually |
When choosing, look not at the pretty canvas, but at the capabilities:
- durable state and resume after failure;
- type/schema validation;
- retries, timeouts, and cancellation;
- human-in-the-loop;
- concurrency and rate limits;
- tracing and cost attribution;
- secrets and role-based access;
- sandbox/workspace isolation;
- graph and prompt versioning;
- data export without vendor lock-in.
If a company is only getting familiar with agents, it is useful to first understand where AI agents deliver business impact and where they remain hype. The orchestrator will not fix a poorly chosen process.
FAQ
What is Graph Engineering in simple terms?
It is designing AI work as a dependency map. Nodes perform separate tasks, edges pass results, independent branches run in parallel, and checks plus humans control transitions.
How is an AI agent graph different from a regular chain?
A chain is a special case of a graph where each step waits for the previous one. A full graph removes false dependencies, allows branching, parallel nodes, correction loops, and multiple merge points.
Does Graph Engineering replace loop engineering?
No. Loop engineering manages repetition of one task until a readiness criterion is met. Graph Engineering connects multiple tasks and loops. In a production system, they are usually used together.
Do you have to use multiple models?
No. Different nodes can call the same model with different roles and contexts. Using multiple models can help with cost and reduce correlated errors, but the graph structure is determined by dependencies, not by LLM brands.
Why does the reviewer need separate context?
So it does not inherit the executor’s beliefs and can re-check the artifact against the criteria from scratch. It still needs the source data and evidence, but not the self-justifying history of the worker node.
Are multiple reviewers always more reliable than one?
No. Multiple LLMs can repeat the same mistake. Reliability comes when verification uses different methods and external anchors: a test, the source document, a transaction, or an expert decision.
How do you know a task is worth parallelizing?
Find at least two steps that do not need each other’s outputs or mutable resources. Then check that the cost of coordination is lower than the expected gain in time or quality.
How many agents should you run?
Start with 3–5 workers and a hard budget. The optimal number is constrained by the real width of the task, rate limits, the verifier’s ability to handle the stream, and cost. 64 agents from the Bun case is an extreme example, not a starting point.
How do you avoid overflowing the context during merge?
Use hierarchical fan-in: normalize the results, merge them in batches, create intermediate summaries, and store raw evidence separately with addressable links.
Can a graph be allowed to publish or change production?
Technically yes, but for high-risk actions it is safer to require a human gate, minimal permissions, staging, logging, and reversible deployment. Preparing the result and releasing it irreversibly are different nodes.
Which metrics show that a graph pays off?
Compare against the baseline: end-to-end latency, cost per successful run, completeness, error rate, number of manual interventions, and incident cost. Speed without quality and cost control is not success.
Bottom line
Graph Engineering is a useful name for work that has long been familiar but has become sharply more relevant: designing not one “smart prompt,” but a system of dependencies, contracts, checks, and permissions.
A graph has three real advantages:
- independent work runs in parallel;
- context and accountability are separated by node;
- failure, cost, and proof of result become observable.
And three limitations:
- a graph increases coordination and token costs;
- internal consistency does not guarantee truth;
- scaling without isolation and anchors scales errors.
Start not with an army of agents and not with a new framework. Draw the current process. For each edge, ask exactly what is being passed along it. Remove false dependencies. Identify the critical path. Assign one node a contract, add an independent verifier and an external success criterion. Then run a small, limited pilot.
If it is measurably faster, more complete, or more reliable than the previous process, you have a graph worth expanding. If not, the simple loop remains the better engineering solution.