Graph Engineering: Execution Graphs vs Context Graphs

Peter Steinberger asked, “Are we still talking loops or did we shift to graphs yet?” LangChain replied: “Graph engineering isn't a new idea. It's the latest name for a well-established approach to building reliable agents.”

Graph engineering means representing agent execution as explicit nodes and edges. It extends rather than replaces prompt engineering, context engineering, harness engineering, and loop engineering.

Modern graph frameworks can also persist checkpoints, memory, workflow events, and application-defined data. That persistence can resume a run or preserve information across sessions. It does not define whether two records identify the same customer, what a relationship means, which source is authoritative, or what was true when an agent acted.

An execution graph defines how work moves through the system. A context graph can represent application entities, relationships, sources, and history for domains that require consistent shared meaning. It can be grounded in an application-defined ontology.

Not every agent needs both. The distinction matters when multiple workflows, applications, or teams must interpret and update the same changing domain state.

Key Takeaways

• Prompt engineering shapes one inference. Context engineering determines what the model sees. Harness engineering constrains the runtime, loop engineering sustains iterative work, and graph engineering coordinates branches between agents and tools.
• An execution graph answers what runs next. A context graph represents what the system knows across entities, sources, workflows, and time.
• Persisting checkpoints, transcripts, or application data does not create a shared domain contract. Durable agent state still needs an application-owned ontology, stable identity, temporal validity, provenance, permissions, and safe update semantics.
• A separate context graph becomes useful when multiple workflows or applications share changing domain facts. HydraDB can extract relationships automatically or ingest an application-supplied graph without imposing a fixed ontology.

How Graph Engineering Relates to Prompt, Context, Harness, and Loop Engineering

Prompt engineering shapes one inference

Prompt engineering steers a single inference. Role definitions, few-shot examples, output constraints, and task decomposition all shape what the model does with that request.

The model can also draw on knowledge encoded in its weights. Retrieval for current information, memory for continuity, iteration for sustained work, and a persistence layer for durable state all depend on the surrounding system.

Context engineering determines what the model sees

Context engineering decides what the model sees on the next inference. RAG pipelines, token budgeting, retrieval ranking, memory selection, and context compression bring current application data into that request.

In a study of 18 models, including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3, Chroma found that performance became increasingly unreliable as input length increased, even on deliberately simple retrieval and question-answering tasks.

Reliability is only half the problem. Putting information in a context window doesn’t make it durable or authoritative. A retrieved document can be stale, and a compressed summary can lose the details that made it trustworthy. A transcript can preserve text without ever resolving it to a stable domain entity. None of these mechanisms determines which record the application should treat as canonical.

Harness engineering enforces runtime behavior

Harness engineering controls the environment around an agent. It can enforce runtime constraints independently of the model, set verification gates, scope available tools, and preserve progress across sessions. A harness can keep plans in files, use git to record changes, run tests before accepting work, and stop an agent when it enters an unproductive loop.

The application still has to define what each file, commit, and checkpoint means.

Loop engineering sustains iterative work

Loop engineering replaces repeated human prompting with an automated plan, execute, observe, verify, and retry cycle. Addy Osmani wrote: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Building that system usually means propose-run-check-retry cycles, verifier separation, tool use, and explicit stop conditions.

A loop can save progress to files, git, databases, or framework memory. But persistence isn’t verification. Osmani also wrote: “Verification is still on you.” An unattended loop can repeat errors without human intervention, and persisting those errors does not make them trustworthy.

Graph engineering coordinates execution

Graph engineering makes control flow explicit. Nodes and edges support routing, parallelism, fan-out and fan-in, node-level scoping, conditional transitions, and human approval as a step in the workflow. A Researcher can feed a Writer, whose work is checked by a Reviewer, without placing the entire workflow in one linear context.

Execution Graphs and Context Graphs Solve Different Problems

An execution graph and a context graph can use the same database or runtime, but their nodes and edges represent different things.

Dimension	Execution graph	Context graph
Primary question	What runs next?	What does the system know?
Typical nodes	Agents, tools, steps, routers, approvals	Customers, contracts, incidents, claims, policies
Typical edges	Routing, branching, retry, dependency	Owns, governs, caused, approved, supersedes
State	Checkpoints and branch results	Facts, relationships, sources, decisions, history
Meaning comes from	Workflow definition	Application-owned ontology
Typical lifetime	Run, thread, or long-running workflow	Sessions, workflows, applications, and frameworks

A workflow graph can coordinate five agents successfully while all five write inconsistent representations of the same customer. The application still has to reconcile their results into one canonical domain model.

Persistence Does Not Create a Domain Contract

State category	Typical mechanisms	Primary purpose	What still needs explicit design
Execution state	Graph checkpoints, workflow histories, retry metadata	Resume and coordinate work	Domain identity, validity, and cross-workflow semantics
Session state	Conversation stores, thread history, scratchpads	Preserve interaction continuity	Canonical facts, deduplication, and authority
Agent memory	Facts, preferences, summaries, episodic records	Influence future agent behavior	Provenance, conflict rules, permissions, and application-wide consistency
Durable domain state	Application databases, event logs, temporal models, context graphs	Represent business truth across systems and time	Schema ownership, migration paths, and framework independence. Typically chosen for the workload.

LangGraph uses Checkpointers for thread snapshots and Stores for application-defined data across threads. Temporal reconstructs workflow state from ordered Event History. OpenAI Agents SDK Sessions retain conversation items. Google ADK MemoryService provides searchable knowledge across sessions. CrewAI Memory extracts facts with scopes and source tags.

These frameworks can persist state beyond a process lifetime. Some also offer in-memory implementations.

A LangGraph Store can hold a customer record, a Temporal Workflow can carry business data, and a file in git can represent an approved plan. If the orchestrator's internal schema is the only system of record, domain state inherits the runtime's namespacing, lifecycle, concurrency model, and migration constraints.

A domain-state contract answers five questions:

• Can two agents update the same entity safely?
• Can the system identify the same customer across CRM, support, and billing?
• Can it distinguish current truth from historical truth?
• Can every consequential claim be traced to a source?
• Can state move to a different framework without replaying every transcript?

Agent memory is one part of application state. The CoALA taxonomy describes working memory plus three long-term memory types: episodic, semantic, and procedural. Agent-memory products differ substantially in how they handle provenance, temporal validity, permissions, and concurrent writes. Cross-session recall still does not guarantee those properties.

What Breaks When Workflow State Becomes Domain State

Checkpoints resume work. Transcripts preserve conversation continuity. Vectors support semantic recall. Event logs preserve history. Problems start when an application uses a checkpoint as a fact store, a transcript as an approval record, or a vector index as an event log.

State loss on restart

LangGraph's MemorySaver and InMemorySaver keep checkpoints in RAM, so a process restart loses them. Using an in-memory saver when restart recovery is required is a deployment error. Persistent backends are available, but their scope and backing-store guarantees must be chosen explicitly.

Session history mistaken for domain state

A customer approval stored only in a transcript is history, not a structured domain record. An OpenAI Agents SDK SQLiteSession lets another workflow read the stored conversation items. It doesn’t extract an approval object, deduplicate facts, define which source is authoritative, or tell downstream systems how to enforce the approval. A preference buried in turn 47 is persisted, but another system still needs a defined way to identify, validate, and apply it.

Concurrent writes without convergence rules

Two agents update the same shared block, and both complete successfully. Under last-writer-wins semantics, one intent disappears.

Letta replaces an entire shared memory block during a direct modification and resolves concurrent modifiers with last-writer-wins semantics. When lost updates are unacceptable, successful task completion is not enough. The write path needs ownership, version checks, or conflict detection.

History destroyed by unversioned updates

If an application overwrites a fact without preserving its previous value, source, and validity interval, it can’t reconstruct what was recorded at the time of a decision. A credit score, contract status, or policy value can remain current while its decision-relevant history disappears. Storage exists, but the update destroyed the history.

Unbounded context bloat

Passing growing execution-history payloads between nodes increases serialization cost and can increase latency. Token use rises only when those payloads are inserted into model context. ActiveWizards recommends keeping state bounded and storing large payloads externally while passing references through workflow state. This bounding matters because PostgreSQL locks the entire row when an update changes a JSON document. Updating one shared JSON row can increase contention when many agents write to it.

The Ontology and Guarantees Behind Durable Agent State

A domain model or ontology is the shared vocabulary that defines which kinds of entities, relationships, properties, and rules exist. It gives records consistent meaning across agents and applications. It does not have to be a formal OWL or RDF model. A versioned application schema with typed relationships can be enough for a bounded domain.

The ontology supplies meaning, not durability. The state layer still needs stable identity, temporal validity, provenance, concurrency semantics, permissions, and a lifecycle independent of any one orchestrator. Required guarantees depend on the workload.

Stable entity identity

CRM, support, and billing may assign different source IDs to the same customer. The domain model needs a stable identity that resolves those records across systems, frameworks, and time.

Typed relationships

An account has contracts, contacts, incidents, deployments, and prior decisions. Those connections carry domain meaning. Key-value and document stores can encode them, but the application must supply the relationship model and traversal semantics.

Temporal validity

The system needs to distinguish what is true now, what used to be true, and what superseded what. Bi-temporal modeling separates valid time, when a fact applied in the domain, from transaction time, when the system recorded it. Applications need both dimensions when they must reconstruct domain validity and the information available to an agent at a past decision point. Simpler workloads may need only one.

Provenance

Each consequential claim should record where it came from and which transformation or approval produced it. That's provenance, and it's easy to confuse with confidence. Confidence describes how sure a model was, while provenance identifies the source and lineage of the information, so store them separately.

Concurrency semantics

Multi-agent writes require reducers, disjoint ownership, version checks, transactions, or conflict detection. LangGraph requires a reducer when parallel branches can update the same state key. Without one, the runtime raises InvalidUpdateError. Every fan-out and fan-in design needs explicit write and convergence semantics.

Permissions

Access control may need to operate at field, entity, source, tenant, and purpose level. A support agent should not necessarily see the same customer data as a billing agent, even when both operate on the same entity.

Framework independence

LangGraph persists state through its saver and Store abstractions. CrewAI Memory uses its own schema and defaults to LanceDB. Neither storage model is a cross-framework domain contract.

Entity records link to sources, decisions, policies, actors, permissions, and validity intervals. The resulting model is often graph-shaped even when relational tables or a hybrid system store the data. When relationship traversal, cross-source identity, provenance, and scoped access dominate the workload, graph-native context infrastructure can reduce the application code needed to maintain those connections.

Common fields in a durable fact record include:

• Tenant and subject identity
• Entity type and stable ID
• Value or relationship
• Source reference
• observed_at, valid_from, valid_to, recorded_at
• A superseded-record pointer
• Author or agent identity
• Run and tool-call IDs
• Approval and access policy
• Schema version
• Confidence, stored separately from provenance

Don’t let the structure of a transcript or checkpoint determine the domain schema.

When a Separate Context Graph Is Worth It

Not every agent needs a separate durable state layer.

Anthropic's multi-agent system (Opus 4 lead, Sonnet 4 subagents) outperformed a single-agent baseline by 90.2% on breadth-first research without a shared domain model, but used about 15 times the tokens and was a poor fit for tasks with many shared dependencies.

Cognition initially favored single-threaded agents, then found multi-agent works when writes stay single-threaded and auxiliaries contribute intelligence without mutating shared state. The Ralph pattern carries progress in files and git with fresh model passes; a one-shot agent may never need bi-temporal modeling.

Use a separate context graph or equivalent durable domain-state model when multiple sessions, applications, or teams must identify, authorize, and update the same changing business facts consistently. An agent that processes customer renewals across CRM, billing, and support needs a stable customer identity, current contract state, access rules, source lineage, and safe update semantics.

Production teams already combine several state stores. Replit runs each agent as a Temporal Workflow and isolates failure-prone work in Activities, according to a Temporal case study. In a two-part engineering report, mabl described using Jira labels, Git history, pull requests, repository instructions, and MCP integrations to preserve context across repositories. mabl reported that context drift fell from roughly 40% of failures to under 5%, effectively using those tools as an external state layer.

How to Add a Context Graph Without Replacing Your Orchestrator

Step 1: Audit what you persist today

Walk through checkpoints, session stores, memory services, files, and vector databases. For each record, ask whether a different workflow in a different framework could query it and obtain a useful, trustworthy answer. If not, identify the runtime-specific assumption that prevents it: schema, identity, lifecycle, provenance, or access.

Step 2: Externalize one critical entity

Pick the entity agents interact with most, such as a customer, ticket, deployment, or account. Give it a stable identity, an entity type, a schema, and an application-owned home outside the orchestrator's internal state. Define the relationships that connect it to sources, decisions, policies, and other entities.

Step 3: Add provenance to one decision path

Choose one consequential agent action, such as a refund, escalation, or code merge approval. Record the source, timestamp, approving actor, policy version, relevant inputs, and resulting action. The resulting decision trace connects the evidence, policy, approval, and action so the decision can be reconstructed later.

How HydraDB Supports Application-Owned Ontologies

HydraDB provides graph-native context infrastructure beneath the orchestrator without imposing a fixed application ontology. By default, it extracts relationships during ingestion and stores them as source → relation → target triplets. Queries can return the relevant graph paths alongside ranked chunks, so applications receive both retrieved content and the relationships around it.

When an application already maintains a curated knowledge graph, ontology, or database export, Bring Your Own Graph accepts caller-supplied entities and relations instead of running LLM graph extraction for that source. Entities can include a type, namespace, and external identifier. Relations can include an application-defined predicate, supporting context, and temporal details. The supplied graph persists across re-ingestion and appears in the same graph_context response as extracted relationships.

The application owns the ontology. It defines what entity types and predicates such as CUSTOMER, CONTRACT, OWNS, or SUPERSEDES mean, how records from different systems resolve to canonical entities, and which constraints govern updates.

Graph Engineering Still Inherits Distributed-Systems Problems

Agent systems inherit distributed-systems failures, then add probabilistic reasoning, context limits, and semantic ambiguity.

Retry an ambiguous tool call with an idempotency key. Protect shared-record updates with isolation or merge semantics. Migrate state schemas deliberately. Treat a successful write followed by a failed acknowledgment as a partial failure.

Engineers already know the tools: idempotency, event sourcing, schema evolution, optimistic concurrency, transactions, access control, and lineage.

No ratified, broadly adopted interoperability standard defines a shared domain model for agent memory. The current Model Context Protocol specification defines interoperability for context exchange, including tools, resources, and prompts. It does not define a shared memory model. Early drafts, including the memorywire preprint and the Agent Memory Protocol, cover parts of the problem but remain fragmented.

Until a shared contract emerges, keep durable domain state behind an application-owned interface instead of embedding it in one framework's internal schema. Frameworks change, and the state contract should survive the migration.

Keep your orchestrator. Add a graph-native context layer beneath it. Start building an application-owned context graph with HydraDB.

FAQ

What is graph engineering for AI agents?

Graph engineering is the practice of representing agent execution as explicit nodes and edges. Nodes perform work, call tools, or run agents, while edges define routing, branching, retries, joins, approvals, and stop conditions. It makes the structure of an agent workflow inspectable and controllable.

How is graph engineering different from loop engineering?

Loop engineering designs the cycle that lets an agent plan, act, observe, verify, and retry until it reaches a stop condition. Graph engineering connects one or more of those loops through explicit branches, dependencies, parallel paths, and convergence points. A loop sustains work; a graph coordinates how work moves through the larger system.

How do prompt, context, harness, loop, and graph engineering differ?

Prompt engineering shapes one model response. Context engineering determines what information the model receives. Harness engineering controls the tools, permissions, verification gates, and runtime around the agent. Loop engineering automates repeated work, while graph engineering coordinates multiple steps, loops, agents, and approval paths.

What is the difference between an execution graph and a context graph?

An execution graph represents control flow: which agent or tool runs next, where work branches, and how results converge. A context graph represents domain state: entities, relationships, sources, decisions, and changes over time. The execution graph coordinates work, while the context graph gives that work a shared model of the domain.

Can LangGraph persist durable domain state?

LangGraph Checkpointers persist thread snapshots, and LangGraph Stores can hold application-defined data across threads. Those mechanisms can store domain records, but the application must still define canonical identity, schema, temporal validity, provenance, permissions, and conflict rules. Framework persistence can be part of a durable-state architecture without becoming the domain contract itself.

When do AI agents need an ontology?

Agents need an ontology when several workflows or applications must interpret the same entities and relationships consistently. The ontology defines what concepts such as CUSTOMER, CONTRACT, and POLICY mean and how relationships such as OWNS, APPROVED_BY, or SUPERSEDES should be interpreted. It supplies shared meaning, while the state layer supplies durability and operational guarantees.

When does an AI agent need a separate context graph?

A separate context graph is useful when multiple sessions, agents, or applications must read and update the same changing business facts. One-shot agents and isolated coding workflows can often rely on files, framework state, or a conventional schema. Cross-system workflows need stronger identity, history, provenance, permissions, and concurrency semantics.

How does HydraDB support application-owned ontologies?

HydraDB can extract entities and relationships automatically during ingestion or accept caller-supplied entities and relations through Bring Your Own Graph. Applications control their entity types, namespaces, predicates, and relationship meanings. HydraDB stores and retrieves that graph without requiring every application to adopt the same ontology.