Graph Engineering: AI Architect’s Guide to Reliable Agents

The internet is currently selling graph engineering as a magic file, a secret Anthropic doctrine, or a way to summon a hundred engineers from one terminal.

That is not the useful version of the idea.

No official Anthropic source I reviewed calls graph engineering an Anthropic standard. The closest first-party terms are dynamic workflows, multi-agent systems, orchestrator-worker patterns, subagents, and agent teams. OpenAI talks about agent orchestration, handoffs, agents-as-tools, sessions, tracing, guardrails, and harness engineering. Google, xAI, Nous Research, LangChain, Temporal, and the graph-retrieval community each expose different parts of the same systems problem.

The emerging term is still valuable—if we define it with enough precision to outlive the trend.

Graph engineering is the discipline of designing, versioning, running, observing, and improving explicit graphs that coordinate agent loops, tools, state, evidence, human decisions, and recovery paths.

This is the field guide I wish the viral diagrams had shipped with.

The short version

• Loop engineering improves one agent’s repeated cycle: gather context, act, observe, verify, and continue.
• Graph engineering composes one or more loops into a governed system of typed work, state, evidence, approvals, and recovery.
• A production agent system usually contains three coupled graphs: an execution graph, a context graph, and a control graph.
• The real engineering object is not the visual diagram. It is the set of contracts governing nodes, edges, state, permissions, evidence, budgets, and failure.
• Do not reach for a graph because it looks advanced. Use it when work branches, parallelizes, crosses trust boundaries, survives context windows, or requires auditable proof.
• Start with the smallest topology that can meet the service level. Anthropic’s own guidance repeatedly warns that extra autonomy and coordination increase cost and latency.

Use the orchestration pattern decision guide when the immediate question is topology. Use Six Primitives of Every AI Agent to inspect the worker itself, and AI Architecture 2026 before making the vendor, trust, orchestration and runtime decisions that become expensive to undo.

The nine-part field guide

Start here for the shared architecture, then jump to the guide that matches the decision in front of you. Each part keeps one boundary clear so execution graphs, coding harnesses, curricula, and inference runtimes do not collapse into the same idea.

Return to this guide whenever you need the common contract model; use the other parts when the implementation or research layer matters.

Why the term appeared now

The original agent abstraction was a loop:

1. the model receives a goal and context;
2. it chooses an action or tool;
3. the environment returns an observation;
4. the model evaluates progress;
5. the cycle repeats until completion or a stop condition.

That loop remains foundational. Anthropic’s Claude Code documentation describes essentially this gather-context, act, verify, repeat cycle. OpenAI’s agent stack likewise revolves around a model loop that calls tools, produces results, and continues under an orchestration policy.

The abstraction becomes insufficient when a system must do several things at once:

• route different requests to different capabilities;
• fan work out and synthesize it;
• preserve state across long runs or process restarts;
• retrieve only the context a node is allowed to see;
• require evidence before a result advances;
• pause for human approval before side effects;
• repair one failed branch without replaying everything;
• compare competing solutions;
• remember facts that change over time;
• learn from traces without silently changing production behavior.

At that point, “improve the prompt” is the wrong altitude. You are engineering a system.

The 2026 paper Graph Engineering in the Era of LLM Agents gives the emerging field a broad research vocabulary. Vendor documentation supplies the deployable primitives. Graph engineering is the useful umbrella between them—but that umbrella is an interpretation, not a vendor certification.

Two new signals sharpen the boundary. Anthropic’s Claude Code team now explicitly defines loop engineering as repeated agent cycles ending at a stop condition. Stanford’s tentative Fall 2026 CS329Z: Engineering AI Agents treats decomposition, components, data, evaluation, safety and operations as one build discipline. Neither source calls that discipline graph engineering.

Stanford’s June 2026 M* serving system is the more literal loop-to-graph example—but at a different layer. M* models components inside a composite multimodal model as nodes and tensor edges, then lets a small state machine select named subgraphs called Walks. That is an inference-runtime graph, not a business-agent workflow. Similar vocabulary does not create identical contracts.

Loop engineering versus graph engineering

The cleanest mental model is:

A loop is a unit of agency. A graph is a system of agency.

Graph engineering does not abolish the loop. Every worker node may contain one. An evaluator may run its own loop. A recovery edge may launch a repair loop. The graph gives those loops boundaries and consequences.

The three graphs you are actually engineering

Many teams draw only the execution topology. That is why their demonstrations look convincing and their production systems feel haunted.

1. The execution graph

The execution graph answers: what can run next?

Its nodes may be:

• an agent or specialist subagent;
• a deterministic function;
• a retrieval operation;
• a test suite;
• a human decision;
• a deployment, message, payment, or other side effect.

Its edges carry control and data. They can represent delegation, conditional routing, fan-out, merge, retry, timeout, compensation, escalation, or completion.

Anthropic’s effective-agent patterns—routing, parallelization, orchestrator-workers, evaluator-optimizer, and autonomous agents—are execution-graph patterns even though Anthropic does not use that umbrella term. Claude Code’s dynamic workflows make branching, loops, barriers, and intermediate results executable in JavaScript. OpenAI’s Agents SDK orchestration expresses dynamic ownership through handoffs and manager-owned specialists through agents-as-tools.

2. The context graph

The context graph answers: what does this node know, from where, and as of when?

It connects:

• people, accounts, products, concepts, and entities;
• source documents and extracted claims;
• files, commits, issues, tests, and deployments;
• memories and their validity intervals;
• decisions, owners, and superseding decisions;
• citations and provenance.

This graph may live in a graph database, but it does not have to. File paths, relational tables, object storage, vector retrieval, and link-rich Markdown can implement parts of it. The defining property is not the database. It is the explicit relationship and retrieval policy.

Anthropic’s context-engineering guidance recommends just-in-time retrieval rather than preloading every possible detail. Graphiti adds bi-temporal facts and provenance for knowledge that changes. Microsoft GraphRAG and Neo4j GraphRAG build retrieval structures from corpora. Those are context-graph technologies, not general agent workflow engines.

3. The control graph

The control graph answers: what must be true before the system may continue?

It includes:

• input and output validation;
• permission checks and least-privilege boundaries;
• token, time, and monetary budgets;
• test and evaluation gates;
• adversarial review;
• human approval;
• retry and backoff policy;
• recovery and compensation;
• stop conditions;
• release and rollback.

This is the plane most demos omit and most businesses eventually need. OpenAI guardrails and human-in-the-loop approvals, Claude Code hooks and permissions, Temporal retry and durable workflow semantics, CI checks, policy engines, and audit trails all belong here.

The substrate: state

State is not a fourth decorative graph. It is the substrate beneath all three.

For every piece of state, specify:

• its schema and version;
• its owner;
• who can read and write it;
• whether it is ephemeral, session-scoped, task-scoped, or durable;
• its retention and deletion policy;
• its source of truth;
• its checkpoint and replay behavior.

Anthropic’s long-running-agent work emphasizes external artifacts, progress files, commits, clean handoffs, and end-to-end verification. Its managed-agent architecture separates the model brain, execution environment, and durable session event log. OpenAI’s harness-engineering account makes the same organizational move: humans shape environments, intent, and feedback loops while agents execute within them.

The graph contract

You do not have a production graph because a library can draw one. You have one when every node and edge has a testable contract.

Node contract

Every non-trivial node should declare:

Edge contract

An edge is not “then the next agent takes over.” It should define:

• the event or condition that activates it;
• the payload schema;
• the guard or policy that permits traversal;
• the timeout and freshness window;
• the evidence carried forward;
• the state transition;
• the retry, fallback, and compensation route;
• the trace relationship to the parent work.

Here is a small TypeScript shape—not a framework, just the minimum discipline:

type Evidence = {
  source: string
  capturedAt: string
  claim?: string
  checksum?: string
}

type NodeContract<I, O> = {
  id: string
  version: string
  input: (value: unknown) => I
  run: (input: I, ctx: RunContext) => Promise<O>
  output: (value: unknown) => O
  requiredEvidence: (output: O) => Evidence[]
  budget: { turns: number; seconds: number; costUsd?: number }
  sideEffect: "none" | "idempotent" | "compensatable" | "approval-required"
}

type EdgeContract<O> = {
  from: string
  to: string
  when: (output: O, state: GraphState) => boolean
  project: (output: O) => unknown
  onFailure: "retry" | "repair" | "escalate" | "stop"
}

The critical move is separating model judgment from system authority. A model can recommend an edge. Code, policy, or a human should authorize consequential transitions.

Nine production patterns

1. Route and act

A classifier or policy node selects one specialist path. Use it when requests fall into meaningfully different contracts, tools, or risk classes. Do not create five specialists that differ only by persona.

2. Fan out and synthesize

Independent workers explore separate sources, files, markets, or hypotheses; a synthesis node combines results. This is where multi-agent parallelism earns its cost.

Anthropic’s research system reported materially better performance on its internal evaluation, but also about 15× the token usage of ordinary chat. Parallelism is an investment, not free leverage.

3. Orchestrator and workers

An orchestrator decomposes a task dynamically, dispatches workers, and integrates their artifacts. This works when decomposition cannot be fully specified in advance. The orchestrator should produce explicit work packets—not inspirational prose.

4. Evaluator and optimizer

One node creates; another scores against a rubric; the creator repairs until it passes a threshold or exhausts a budget. Keep the evaluator independent enough to disagree.

5. Adversarial verification

A reviewer tries to falsify the output: find unsupported claims, security defects, missing tests, contradictory state, or unsafe side effects. The objective is not stylistic criticism. It is evidence of failure.

6. Generate and filter

Create several candidates cheaply, apply deterministic filters, then spend expensive reasoning only on survivors. This is useful for naming, design exploration, query generation, and solution search.

7. Checkpoint and resume

Write durable state at meaningful boundaries. On failure, resume from the last valid checkpoint rather than replaying every model call. Node code must be idempotent or compensatable when the runtime can restart work.

8. Event-driven supervisor

Repository events, CRM changes, content approvals, or scheduled triggers start bounded workflows. GitHub’s Agentic Workflows, Temporal, and issue-to-agent supervisors such as OpenAI Symphony illustrate different versions of this pattern.

9. Knowledge-grounded action

Before a consequential node acts, it retrieves the smallest authoritative context, records provenance, and binds the evidence to the decision. The context graph does not merely answer questions; it constrains action.

When not to use graph engineering

Use a single loop or deterministic function when:

• the task is short, linear, and reversible;
• every step needs the same context;
• the output can be validated immediately;
• parallel workers would edit the same artifact;
• coordination cost exceeds the expected quality gain;
• no durable state or audit trail is required.

Anthropic’s multi-agent report explicitly notes that broad research parallelizes better than many coding tasks with tight dependencies. Its compiler experiment eventually used 16 agents across roughly 2,000 Claude Code sessions and about $20,000 in API usage—but also encountered duplicated work, merge conflicts, and agents overwriting one another. The lesson is not “use sixteen.” The lesson is “make the work separable before you parallelize it.”

The repository and runtime landscape

These tools solve different graph planes. Treating them as one popularity ranking is an architectural error. This is the adoption call as of 24 August 2026:

My default production composition is LangGraph for explicit graph semantics plus Temporal for durability. In a Google-native estate, pilot ADK 2.0 plus Temporal. Use the OpenAI Agents SDK when the problem is fundamentally a compact tool or handoff loop.

Do not install every layer by reflex. A small service may need only deterministic TypeScript and one agent SDK. Add LangGraph when graph state and interrupts are the product. Add Temporal when elapsed time, process failure, messages and side effects become architectural concerns. Add Graphiti only when facts changing over time are a separate requirement.

The repositories I would create

Do not create a separate architecture repository for every model vendor. Keep the graph contract stable and make runtimes replaceable.

agent-systems/
  packages/
    graph-contracts/       # node, edge, state, evidence, budget schemas
    runtime-adapters/      # Codex, Claude, Hermes, Grok, deterministic tools
    observability/         # trace IDs, spans, cost, latency, evidence lineage
    policy/                # permissions, approvals, risk classes
  workflows/
    content-pipeline/
    repository-delivery/
    client-onboarding/
    product-research/
  skills/
    research-source-ledger/
    claim-verification/
    architecture-review/
    release-gate/
  evals/
    fixtures/
    rubrics/
    adversarial-cases/
    regression-suites/

The model-facing files—AGENTS.md, CLAUDE.md, project rules, or vendor-specific plugins—should remain thin adapters into this system.

The Codex and Claude Skills you actually need

A Skill is a node procedure, not the graph itself. A good reusable Skill declares:

• trigger conditions;
• required inputs and unavailable-input behavior;
• permitted tools and data;
• a stepwise method;
• invariants and safety boundaries;
• the artifact or structured output contract;
• evidence requirements;
• termination and escalation conditions;
• validation or tests.

Build skills around stable work contracts, not vendor features:

1. graph-intake — converts a business objective into a bounded workflow hypothesis;
2. graph-contract-compiler — produces typed node, edge, state, and evidence schemas;
3. parallel-work-packet — creates separable tasks with exclusive artifact ownership;
4. evidence-ledger — records claims, sources, freshness, rights, and confidence;
5. adversarial-verifier — attacks a result against a declared rubric;
6. checkpoint-handoff — serializes progress, next actions, state version, and recovery notes;
7. graph-eval-runner — scores final outcomes and path-level operational metrics;
8. incident-replay — reconstructs why a path was taken and whether retry is safe;
9. runtime-adapter-review — checks whether a vendor harness satisfies the graph contract.

Anthropic advises keeping CLAUDE.md concise and moving procedures into Skills; deterministic constraints belong in hooks, settings, permissions, and sandboxes. The same separation applies to Codex: instruction files shape behavior, but code, schemas, approvals, tests, and environment boundaries enforce authority.

Applying graph engineering across the business

The best first graphs are not the most theatrical. They are recurring processes with clear artifacts, expensive mistakes, and observable outcomes.

Start where all three planes are already visible informally. A process held together by Slack messages, browser tabs, and one person’s memory is usually a better candidate than a clean one-step automation.

A 30/60/90-day adoption plan

Days 1–30: map and measure

• Inventory ten recurring agent or human-agent loops.
• Select two with measurable value and reversible failure.
• Draw the execution, context, and control graph separately.
• Define a canonical event envelope and state version.
• Baseline quality, lead time, cost, retries, and human interventions.
• Create the graph-contract package before choosing a fleet size.

Days 31–60: pilot one thin graph

• Implement three to five meaningful nodes, not thirty personas.
• Give each mutable artifact one owner at a time.
• Add a durable checkpoint before any expensive or consequential branch.
• Require evidence at the merge.
• Add one independent verifier and one human approval for irreversible actions.
• Trace every model call, tool call, state transition, and edge decision.

Days 61–90: harden and reuse

• Test restarts, duplicate events, timeouts, stale state, and partial failure.
• Add cost and latency budgets per path.
• Package successful node procedures as Skills.
• Introduce a second runtime adapter to prove the graph contract is portable.
• Run adversarial evals against the final state, not only the expected path.
• Publish an internal graph registry with owners, versions, dependencies, and service levels.

Metrics that matter

Do not optimize for number of agents. Measure:

• task success and acceptance rate;
• evidence coverage and citation validity;
• human override and escalation rate;
• recovery success after injected failure;
• duplicate or conflicting work;
• time and cost to a verified outcome;
• state staleness and provenance gaps;
• permission denials and unsafe action attempts;
• path distribution and bottlenecks;
• regression by node, edge, model, skill, and workflow version.

The most important graph metric is often verified outcome per unit of coordination, not raw model quality.

What the viral screenshots get wrong

The supplied examples were useful visual references, but several claims do not survive primary-source review:

• I found no official Anthropic “$3.4M leaked file” that creates a free engineering team in the company’s engineering publications, product documentation, or public repositories reviewed for this guide.
• A configuration file may cost nothing; running multi-agent models does not. Anthropic’s parallel compiler experiment used about $20,000 in API spend.
• I found no official Anthropic paper titled Graph Engineering: Opus 5 Edition. Anthropic’s actual current materials use dynamic workflow, harness, and loop terminology.
• The social attribution naming “Anatoli Kopadze” as Head of Claude Code conflicts with official Anthropic material identifying Boris Cherny in that role.
• Anthropic says its role-based Claude certification exams are proctored and identity-verified; they are not awarded for merely attending a free course.
• I found no first-party source for the claim that 85% of Anthropic engineers run dozens or hundreds of agents. Anthropic’s own multi-agent guidance argues for starting with one agent and earning the extra coordination cost.

The accurate story is already powerful. It does not need counterfeit authority.

Verification receipt

I audited 125 unique primary URLs for this field guide: official documentation, first-party engineering reports, original papers, release pages, and canonical repositories. I separated shipped capability from preview, roadmap, benchmark, and social claim in the accompanying evidence ledger. I did not run every external runtime, so the adoption matrix stays explicit about adopt, pilot, watch, and not for core calls.

FAQ

Is graph engineering an official Anthropic concept?

No first-party Anthropic source reviewed for this guide uses it as an official doctrine. Anthropic uses terms such as workflows, dynamic workflows, multi-agent systems, orchestrator-workers, subagents, and agent teams. “Graph engineering” is an emerging external umbrella.

Is graph engineering the same as LangGraph?

No. Graph engineering is a discipline. LangGraph is one implementation family for stateful agent graphs. You can graph-engineer with Temporal, an Agents SDK, Claude workflows, deterministic code, queues, databases, and human gates—or with LangGraph.

Is it the same as GraphRAG?

No. GraphRAG primarily engineers a graph for retrieval and context. A full agent system also needs an execution graph and a control graph.

Do I need multiple agents?

No. A single agent with explicit state, tool boundaries, verification, checkpoints, and human gates can be graph-engineered. Add specialists only when their contracts or contexts are meaningfully different.

Must the graph be a DAG?

No. Build and data pipelines are often DAGs. Agent systems commonly require cycles for evaluation, repair, negotiation, and recovery. Cycles need budgets and termination conditions.

Do I need a graph database?

No. Use one when relationship traversal, temporal facts, or ontology-driven retrieval justifies it. PostgreSQL, files, object storage, vector search, and explicit links may be sufficient.

How many agents should I start with?

The minimum that creates genuine separation. Anthropic’s agent-team guidance suggests roughly three to five teammates initially and warns against same-file edits. “Hundreds” is a capability ceiling in some workflow products, not a recommended default.

Can CLAUDE.md or AGENTS.md be the graph?

No. Those files provide context and instructions. They do not provide durable workflow history, typed state transitions, deterministic authorization, idempotency, or recovery by themselves.

The architect’s conclusion

Loop engineering taught us to improve the model’s immediate cycle.

Graph engineering moves the unit of design outward: from the cleverness of one answer to the reliability of an entire path through work, knowledge, authority, and proof.

The graph is not a swarm. It is not a screenshot. It is not a vendor logo connected to five pastel boxes.

It is a promise:

• this node knows what it is allowed to do;
• this edge carries a valid artifact;
• this state can survive failure;
• this claim can be traced to evidence;
• this action cannot cross its authority boundary unnoticed;
• this system can explain, recover, and improve.

That is the version worth engineering.

Primary sources and further study

• Graph Engineering in the Era of LLM Agents
• Awesome Graph Engineering companion repository
• Anthropic: Building effective agents
• Anthropic: How we built our multi-agent research system
• Anthropic: When to use multi-agent systems
• Anthropic: Agent Harness Design
• Anthropic: Loop engineering
• Anthropic: Effective context engineering for AI agents
• Anthropic: Effective harnesses for long-running agents
• Anthropic: A harness for every task—dynamic workflows in Claude Code
• Stanford CS329Z: Engineering AI Agents
• Stanford SAIL: M* Walk Graph
• M* paper
• Stanford SPRINT
• SPRINT paper
• Stanford AgentFlow
• AgentFlow paper
• ReAct
• LLMCompiler
• StateFlow
• GraphFlow
• MAST multi-agent failure taxonomy
• OpenAI Agents SDK: Orchestration
• OpenAI: Harness engineering
• Temporal: OpenAI Agents SDK integration