Task graph
Nodes execute work. Edges encode dependencies, conditions, handoffs and recovery paths.
- Answers
- What happens next?
- Persists
- Run state and checkpoints
- Fails through
- Bad routes, races, unbounded loops
2026 production handbook AI Graph Engineering Patterns
Execution topologies, knowledge memory substrates and retrieval dynamics - designed as one production system.
Use explicit graphs when a single agent loop can no longer make dependencies, recovery, memory and evidence predictable. This handbook shows which graph to build, how the patterns compose and what must be proven before production.
Graph engineering makes system structure explicit
AI graph engineering is the discipline of encoding execution paths, state transitions, dependencies, memory relationships and retrieval routes as inspectable structures. It shifts reliability from prompt wording into versioned topology, typed contracts and runtime evidence.
The first design decision:
Do not ask "Which graph database or framework should we use?" Ask "Are we structuring what the system does, what it knows, or both?"
Agents query and updateShared contractsMemory grounds execution
Knowledge graph
Nodes represent entities, facts or events. Typed edges carry relationships, provenance and time.
- Answers
- What does the system know?
- Persists
- Entities, facts and provenance
- Fails through
- Bad extraction, identity drift, stale facts
The abstraction ladder
Prompt engineering
Shape one model call.
Template and examplesContext engineering
Shape what the model sees.
Retrieval and token assemblyLoop engineering
Shape one agent's iteration.
Tools, observations and stop conditionsGraph engineering
Shape the whole system.
Nodes, edges, state, memory and evidenceGraph engineering does not replace prompt, context or loop engineering. It governs how those lower-level techniques compose across a system.
Seven execution topologies - and the control each one needs
Choose the lightest topology that makes the required behavior explicit. Complexity is justified by a control need, not by the number of agents on the diagram.
01
A -> B -> CSequential pipeline
- Use when
- A stable process where each stage requires the previous stage's output.
- Production control
- Typed handoff contract and a failure policy at every edge.
- Watch for
- Do not add an agent when a deterministic transform is sufficient.
02
A -> {B | C | D}Conditional router
- Use when
- Requests differ enough to justify specialist prompts, models or tools.
- Production control
- Versioned route predicates, confidence thresholds and a safe default path.
- Watch for
- Do not let a free-form model silently invent destinations.
03
A -> [B, C, D] -> EParallel fan-out / fan-in
- Use when
- Independent research, retrieval, evaluation or transformation tasks.
- Production control
- Concurrency limit, per-branch budget, reducer and partial-failure semantics.
- Watch for
- Do not parallelize tasks that mutate the same state without a reducer.
04
Generate -> Test -> ReviseEvaluator-optimizer loop
- Use when
- Quality can be tested and feedback can materially improve the artifact.
- Production control
- Explicit pass condition, hard iteration cap and escalation path.
- Watch for
- This is cyclic by design; do not call it a DAG unless the loop is bounded inside one node.
05
Lead -> specialist subgraphsHierarchical supervisor
- Use when
- A goal spans domains but local teams should retain narrow context and tools.
- Production control
- Delegation contract, child budgets and evidence returned to the parent.
- Watch for
- A supervisor that rewrites every result becomes a bottleneck and a hidden single agent.
06
Prepare -> Pause -> Approve -> ActHuman approval gateway
- Use when
- A tool call is high-impact, irreversible or outside standing authority.
- Production control
- Persist the exact state and evidence shown to the approver; bind approval to one run.
- Watch for
- A notification after execution is not an approval gate.
07
Goal -> governed subgraphs -> synthesisNested DAG network
- Use when
- A long process needs parallelism, specialization, predictable completion and reusable modules.
- Production control
- Acyclic dependency validation, node-level policy and network-level outcome tests.
- Watch for
- Keep open-ended exploration inside bounded nodes; keep the outer network schedulable.
What VDF AI means by a DAG agent network
A VDF AI DAG agent network is a multi-agent workflow in which nodes perform bounded work and directed edges encode dependencies. The outer graph is acyclic, so independent branches can run in parallel and completion, caching and re-execution remain predictable.
01GoalIntent decomposition
→
02ARetrievePrivate knowledge
02BAnalyzeSpecialist model
02CValidateRules and tests
→
03SynthesizeEvidence-bound result
A node is a policy boundary
| Node type | Production role |
|---|---|
| Agent | Reason, generate or judge with a defined model, prompt, tools and guardrails. |
| Multi-agent | Run a bounded subnetwork with its own decomposition and aggregation contract. |
| Data | Retrieve, filter, map, normalize or join enterprise information. |
| Control | Branch, wait, rate-limit, approve, retry, cache or aggregate. |
| Integration | Read from or write to an API, application, event bus or storage system. |
Networks v3 adds the operating layer
- Plain-language goal decomposition into inspectable nodes and connections.
- Sequential, parallel and conditional edges with explicit aggregation.
- Nested networks for reusable bounded subgraphs.
- Per-node models, prompts, tools, budgets and permissions.
- SEEMR routing under quality, cost, latency and energy objectives.
- RBAC, human approval gates, audit trails and on-premises deployment.
Published VDF AI benchmark
Routing and decomposition make energy an architectural variable
In a separate execution benchmark, the routed condition used 94.9% less predicted energy than a pinned frontier-model baseline while aggregate quality remained within a pre-registered non-inferiority margin. This is a benchmark result, not a universal workload promise.
Read methods and task-level exceptions →The graph is only as reliable as its state contract
A production graph carries a typed state object, not a continuously growing chat transcript. Nodes read only what they require and commit narrow updates under explicit merge rules.
A practical state schema
| Channel | What belongs there |
|---|---|
request | Normalized goal, initiating principal, risk tier and correlation ID. |
evidence | Source references and retrieval metadata - not an unbounded transcript. |
artifacts | Versioned drafts, structured outputs and tool results. |
decisions | Routes, approvals, policy outcomes and their reasons. |
control | Iteration count, budgets, deadlines, retry state and cancellation flag. |
quality | Test results, evaluator scores, abstention flags and unresolved defects. |
Five recovery rules
- 1Checkpoint at node boundaries
Persist the state and graph pointer after a successful commit, not halfway through a side effect.
- 2Make side effects idempotent
Use a run-scoped idempotency key so a resumed node cannot send, pay or write twice.
- 3Separate retry from compensation
Retry transient failures; compensate a completed action whose downstream transaction fails.
- 4Record reducer behavior
Parallel branches must append, merge or override state under an explicit and tested rule.
- 5Rehearse resume and replay
A checkpoint is not a recovery mechanism until operators have resumed a failed run from it.
Load checkpoint→Run node→Commit side effect→Persist state→Advance pointer
Failure test:
Terminate the worker after the external side effect succeeds but before the node reports success. A correct design resumes without duplicating the action.
Persistent memory needs time, identity and provenance
Flat vector stores are useful for semantic recall, but they do not inherently represent identity, typed relationships, contradiction or what was true at a point in time. A temporal knowledge graph can add those semantics.
- 01ObserveCapture an episode with provenance and event time.
- 02ExtractPropose typed entities, facts and relationships.
- 03ResolveMatch, create or escalate ambiguous identities.
- 04ReconcileSupersede, contradict or preserve prior assertions.
- 05ConsolidatePrune, summarize and re-index asynchronously.
- 06RetrieveApply identity, time, topology and provenance filters.
Record when it was true and when you learned it
A fact edge carries two independent clocks:
- Valid time
- The real-world interval during which the assertion was true.
- Transaction time
- When the system observed, extracted and stored the assertion.
Observed 02 AprCustomer - located in - StockholmValid 01 Mar to 15 Jul
Observed 20 JulCustomer - located in - BerlinValid from 16 Jul
The first edge is closed, not deleted. The graph can answer both "Where now?" and "Where on 1 June?"
Spend model calls only on ambiguous identities
High matchAuto-merge
Ambiguous bandLLM or human resolve
Low matchCreate candidate
Use lexical and vector retrieval first. Escalate only candidates in the uncertainty band, and preserve the evidence used for the decision.
Write-path controls
- Tenant and ontology scope before similarity search.
- Stable entity registry and merge history.
- Append-only episode provenance.
- Asynchronous consolidation for expensive summaries.
Research frontier, not default architecture
Content-addressed immutable "worlds" and Merkle-style graph histories, as proposed by WorldDB, are promising for structural isolation and auditability. Treat them as an evaluated design option, not a settled enterprise standard.
Use graph structure when the answer is not in one chunk
GraphRAG complements passage retrieval by representing entity relationships and precomputing community-level context. Its strongest case is global sensemaking: questions whose answer must be assembled from patterns across a corpus.
- Chunk the corpus into traceable text units.
- Extract entities, typed relationships and claims.
- Build a hierarchy of connected communities.
- Generate grounded reports for each community.
- Embed entities, text units and reports for retrieval.
Graph indexentities · relationships · text units · community reports
- Classify query intent.
- Select local, global or hybrid search.
- Assemble bounded evidence context.
- Generate with source references.
- Evaluate groundedness and completeness.
| Query mode | Best for | Execution |
|---|---|---|
| Local | A specific entity or relationship | Find anchors, traverse a bounded neighborhood and join source text. |
| Global | Themes across the whole corpus | Map over community reports, rank partial answers and reduce them into a synthesis. |
| Hybrid / DRIFT | Broad question with local evidence needs | Use community context to broaden the start, then retrieve and verify detailed evidence. |
Leiden community hierarchies
Microsoft GraphRAG uses hierarchical Leiden clustering and bottom-up community reports. It is established, documented and useful for global search.
Engineering risk: a 2026 preprint argues that modularity optimization on sparse knowledge graphs can yield many near-optimal partitions, reducing reproducibility across indexing runs.
Deterministic and constrained alternatives
Core-based hierarchy: deterministic density-aware communities proposed as an alternative for reproducible global retrieval.
Schema-constrained causal graphs: HCG-RAG reports 3-20x fewer nodes and 8-135x fewer build-time LLM calls than its most LLM-intensive baseline while matching entity-relation answer quality on the evaluated datasets.
The k-core and HCG-RAG results above are 2026 preprint findings. Validate them on your corpus, schema and query distribution before selecting a production index.
Route the query before you retrieve
Production systems rarely win by forcing every question through one index. Classify the answer shape, then choose an analytical query, a local subgraph or global graph search - and combine them only when the evidence requires it.
User queryintent · entities · scope · permissions
Analytical
Natural language -> constrained Cypher or SQL -> read-only execution.
Local subgraph
Vector or lexical anchors -> bounded traversal -> evidence expansion.
Global sensemaking
Community reports -> parallel map -> score and filter -> reduce.
Rerank and compresssemantic similarity + topology + recency + authority
Grounded answerbounded context · citations · abstention
The answer is a precise property, filter, count or aggregation.
Validate the parsed query against schema, operation and cost allow-lists before execution.
The answer depends on how named entities connect over a few hops.
Start with a two- or three-hop cap, then tune from measured recall and latency.
The question asks for themes, patterns or change across the whole corpus.
Budget by hierarchy level and require citations back to source text units.
Compression rule:
Merge overlapping triplets, remove duplicate entity descriptions and order the remaining evidence topologically before it enters the model context. Context quality matters more than raw subgraph size.
Match the pattern to the failure you need to control
A graph is justified when it makes a required property - dependency, recovery, specialization, temporal truth or corpus-wide reasoning - materially easier to test and operate.
| Primary need | Start with | Why |
|---|---|---|
| One bounded, unpredictable task | Single agent loop | Lowest structural overhead; retain stop conditions and tool limits. |
| Stable, multi-step process | Sequential task graph | Clear handoffs, deterministic recovery and simple observability. |
| Independent work can run together | Fan-out / fan-in DAG | Parallel speedup with an explicit reducer and predictable completion. |
| Output quality is objectively testable | Evaluator-optimizer | Feedback loop improves quality inside a hard budget. |
| Cross-domain work with isolated context | Supervisor + subgraphs | Specialists keep narrow tools and return bounded evidence. |
| Facts change and history matters | Bitemporal knowledge graph | Point-in-time answers and auditable corrections without destructive overwrite. |
| Multi-hop entity questions | Hybrid vector-graph retrieval | Semantic recall finds anchors; topology supplies relationships. |
| Whole-corpus themes | GraphRAG global search | Community summaries represent information no single chunk contains. |
| Auditable domain causality | Schema-constrained causal graph | Smaller graph, lower extraction cost and a reviewable ontology. |
One agent owns every decision
Routing, tools, memory and retries are implicit. The system is hard to reproduce, authorize and contain.
Every sentence becomes a node
Latency, state migrations and operational surface grow without adding a meaningful control boundary.
Each edge makes a promise
A dependency, policy, merge rule or recovery behavior is explicit enough to test independently.
Six gates from diagram to operated system
Do not promote a graph because a happy-path demo completed. Promote it when the team can produce the evidence at every gate.
- 01
Boundary
The team can explain why a graph is needed and which work remains deterministic code.
- 02
Contracts
Every node has typed inputs, outputs, side effects, timeout and error semantics.
- 03
Recovery
Resume, retry, cancellation and compensation have been exercised under failure.
- 04
Grounding
Retrieval returns accessible provenance and fails closed across permission boundaries.
- 05
Evaluation
Task, route, retrieval and end-to-end outcome tests are versioned and repeatable.
- 06
Operations
Owners can reconstruct, contain, roll back and cost one run without developer archaeology.
Build sequence
- Prove the task in one bounded loop.
- Extract deterministic stages and typed contracts.
- Add branches only where specialization or parallelism pays.
- Add checkpoints, idempotency and compensation.
- Attach retrieval and memory behind permission boundaries.
- Version evaluation sets before optimizing routes.
- Load test failure, not only throughput.
- Ship with a rollback topology and named owner.
Run record minimum
- Graph and node definition versions.
- Initiator, agent and workload identities.
- Route decisions and model selections.
- Checkpoint and retry history.
- Retrieved entities, text units and permissions.
- Tool inputs, side effects and idempotency keys.
- Evaluator results, approvals and final outcome.
- Latency, token, cost and predicted-energy attribution.
Take it into the architecture review
Get the lean PDF edition
The complete handbook in a print-ready format: topology catalog, state schema, memory lifecycle, GraphRAG flow, retrieval router, decision matrix and six production gates.
AI graph engineering - direct answers
What is graph engineering for AI agents?
Graph engineering is the discipline of making an AI system's execution paths, state transitions, dependencies, memory relationships and retrieval routes explicit. It moves reliability work from prompt wording into versioned system structure.
What is the difference between a task graph and a knowledge graph?
A task graph controls what happens next: its nodes execute work and its edges carry dependencies or routes. A knowledge graph represents what the system knows: its nodes are entities or facts and its edges are typed relationships with provenance and, when needed, temporal validity.
Is every agent graph a DAG?
No. A directed acyclic graph always moves forward and cannot revisit a node. Evaluator loops and state machines can contain cycles. A production design can still place a bounded cyclic subgraph inside one node of an outer DAG.
Why use a DAG instead of one autonomous agent loop?
Use a DAG when the workflow benefits from explicit dependencies, parallel branches, specialist nodes, predictable retries, caching, policy per node and a finite completion structure. Keep a single loop when one bounded agent can solve the task with less operational overhead.
When does GraphRAG outperform vector RAG?
GraphRAG is most useful for multi-hop entity questions and global sensemaking across a corpus. Vector RAG is usually simpler and cheaper for local passage lookup. Many production systems route between vector, graph and analytical retrieval instead of choosing one exclusively.
What is bitemporal graph memory?
Bitemporal memory records both when a fact was valid in the world and when the system learned or stored it. That allows point-in-time questions, late-arriving corrections and an audit trail without overwriting history.
How deep should a graph traversal be?
There is no universal depth. Two or three hops is a practical starting bound for many enterprise queries because it limits expansion and latency. Tune it using measured recall, context size and failure cases, with strict maximums.
How does VDF AI use DAG agent networks?
VDF AI Networks represents work as governed nodes and directed dependencies, including sequential and parallel branches, nested networks and explicit aggregation. Nodes can use different models, tools and policies, while SEEMR routes each stage under quality, cost, latency and energy objectives.
Research and implementation references
The source documents were reconciled against these official documentation pages, original papers and first-party VDF AI material. Preprint claims are labeled as such.
- LangGraph - Workflows and agents
- LangGraph - Graph API and state model
- LangGraph - Persistence and checkpointing
- Microsoft Research - From Local to Global: A Graph RAG Approach to Query-Focused Summarization
- Microsoft GraphRAG - Index and query documentation
- Hossain and Sariyuce - Core-based Hierarchies for Efficient GraphRAG (2026 preprint)
- Saouda et al. - Structure Over Scale: Schema-Constrained Causal Graphs for RAG (2026 preprint)
- Ganesan - WorldDB: A Vector Graph-of-Worlds Memory Engine (2026 preprint)
- Graphiti - Open-source temporal context graph engine
- VDF AI - The Energy Efficiency of Agent Networks
- VDF AI - Networks
Continue from pattern to platform
Architecture review
Bring one agent workflow. Leave with a graph boundary.
We will map the nodes, state, policies, retrieval modes and recovery semantics with your team - including which parts should remain ordinary deterministic software.