{"slug": "graph-engineering-execution-graphs-vs-context-graphs", "title": "Graph Engineering: Execution Graphs vs. Context Graphs", "summary": "LangChain's blog post on graph engineering distinguishes execution graphs, which coordinate agent workflows, from context graphs, which represent shared domain knowledge, arguing that durable agent state requires an application-owned ontology. The post cites a Chroma study of 18 models, including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3, showing performance becomes unreliable with longer input lengths, and introduces HydraDB as a tool for extracting relationships or ingesting application-supplied graphs.", "body_md": "12 min\n\n# Graph Engineering: Execution Graphs vs Context Graphs\n\nManveer Chawla\n\nUpdated on :\n\nPeter Steinberger asked, “Are we still talking loops or did we shift to graphs yet?” [LangChain replied](https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph): “Graph engineering isn't a new idea. It's the latest name for a well-established approach to building reliable agents.”\n\nGraph engineering means representing agent execution as explicit nodes and edges. It extends rather than replaces prompt engineering, context engineering, harness engineering, and loop engineering.\n\nModern 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.\n\nAn 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.\n\nNot every agent needs both. The distinction matters when multiple workflows, applications, or teams must interpret and update the same changing domain state.\n\n## Key Takeaways\n\nPrompt 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.\n\nAn execution graph answers what runs next. A context graph represents what the system knows across entities, sources, workflows, and time.\n\nPersisting 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.\n\nA 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.\n\n## How Graph Engineering Relates to Prompt, Context, Harness, and Loop Engineering\n\n### Prompt engineering shapes one inference\n\nPrompt engineering steers a single inference. Role definitions, few-shot examples, output constraints, and task decomposition all shape what the model does with that request.\n\nThe 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.\n\n### Context engineering determines what the model sees\n\nContext 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.\n\nIn a [study of 18 models](https://www.trychroma.com/research/context-rot), 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.\n\nReliability 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.\n\n### Harness engineering enforces runtime behavior\n\nHarness 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.\n\nThe application still has to define what each file, commit, and checkpoint means.\n\n### Loop engineering sustains iterative work\n\nLoop engineering replaces repeated human prompting with an automated plan, execute, observe, verify, and retry cycle. [Addy Osmani wrote](https://addyosmani.com/blog/loop-engineering/): “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.\n\nA 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.\n\n### Graph engineering coordinates execution\n\nGraph 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.\n\n## Execution Graphs and Context Graphs Solve Different Problems\n\nAn execution graph and a context graph can use the same database or runtime, but their nodes and edges represent different things.\n\nDimension | Execution graph | Context graph |\n|---|---|---|\nPrimary question | What runs next? | What does the system know? |\nTypical nodes | Agents, tools, steps, routers, approvals | Customers, contracts, incidents, claims, policies |\nTypical edges | Routing, branching, retry, dependency | Owns, governs, caused, approved, supersedes |\nState | Checkpoints and branch results | Facts, relationships, sources, decisions, history |\nMeaning comes from | Workflow definition | Application-owned ontology |\nTypical lifetime | Run, thread, or long-running workflow | Sessions, workflows, applications, and frameworks |\n\nA 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.\n\n## Persistence Does Not Create a Domain Contract\n\nState category | Typical mechanisms | Primary purpose | What still needs explicit design |\n|---|---|---|---|\nExecution state | Graph checkpoints, workflow histories, retry metadata | Resume and coordinate work | Domain identity, validity, and cross-workflow semantics |\nSession state | Conversation stores, thread history, scratchpads | Preserve interaction continuity | Canonical facts, deduplication, and authority |\nAgent memory | Facts, preferences, summaries, episodic records | Influence future agent behavior | Provenance, conflict rules, permissions, and application-wide consistency |\nDurable 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. |\n\n[LangGraph](https://docs.langchain.com/oss/python/langgraph/persistence) uses Checkpointers for thread snapshots and Stores for application-defined data across threads. [Temporal](https://docs.temporal.io/workflow-execution/event) reconstructs workflow state from ordered Event History. [OpenAI Agents SDK Sessions](https://openai.github.io/openai-agents-python/sessions/) retain conversation items. [Google ADK MemoryService](https://adk.dev/sessions/memory/) provides searchable knowledge across sessions. [CrewAI Memory](https://docs.crewai.com/en/concepts/memory) extracts facts with scopes and source tags.\n\nThese frameworks can persist state beyond a process lifetime. Some also offer in-memory implementations.\n\nA 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.\n\nA domain-state contract answers five questions:\n\nCan two agents update the same entity safely?\n\nCan the system identify the same customer across CRM, support, and billing?\n\nCan it distinguish current truth from historical truth?\n\nCan every consequential claim be traced to a source?\n\nCan state move to a different framework without replaying every transcript?\n\nAgent memory is one part of application state. The [CoALA taxonomy](https://arxiv.org/abs/2309.02427) 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.\n\n## What Breaks When Workflow State Becomes Domain State\n\nCheckpoints 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.\n\n### State loss on restart\n\n[LangGraph's MemorySaver and InMemorySaver](https://docs.langchain.com/oss/python/langgraph/persistence) 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.\n\n### Session history mistaken for domain state\n\nA customer approval stored only in a transcript is history, not a structured domain record. An [OpenAI Agents SDK SQLiteSession](https://openai.github.io/openai-agents-python/sessions/) 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.\n\n### Concurrent writes without convergence rules\n\nTwo agents update the same shared block, and both complete successfully. Under last-writer-wins semantics, one intent disappears.\n\n[Letta](https://docs.letta.com/guides/core-concepts/memory/memory-blocks) 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.\n\n### History destroyed by unversioned updates\n\nIf 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.\n\n### Unbounded context bloat\n\nPassing 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](https://activewizards.com/blog/langgraph-state-management-checkpointing-recovery-and-the-persistence-layer-decision/) 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](https://www.postgresql.org/docs/current/datatype-json.html). Updating one shared JSON row can increase contention when many agents write to it.\n\n## The Ontology and Guarantees Behind Durable Agent State\n\nA 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.\n\nThe 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.\n\n### Stable entity identity\n\nCRM, 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.\n\n### Typed relationships\n\nAn 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.\n\n### Temporal validity\n\nThe 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.\n\n### Provenance\n\nEach 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.\n\n### Concurrency semantics\n\nMulti-agent writes require reducers, disjoint ownership, version checks, transactions, or conflict detection. [LangGraph requires a reducer](https://docs.langchain.com/oss/python/langgraph/errors/INVALID_CONCURRENT_GRAPH_UPDATE) when parallel branches can update the same state key. Without one, the runtime raises `InvalidUpdateError`\n\n. Every fan-out and fan-in design needs explicit write and convergence semantics.\n\n### Permissions\n\nAccess 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.\n\n### Framework independence\n\n[LangGraph](https://docs.langchain.com/oss/python/langgraph/persistence) persists state through its saver and Store abstractions. [CrewAI Memory](https://docs.crewai.com/en/concepts/memory) uses its own schema and defaults to LanceDB. Neither storage model is a cross-framework domain contract.\n\nEntity 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.\n\nCommon fields in a durable fact record include:\n\nTenant and subject identity\n\nEntity type and stable ID\n\nValue or relationship\n\nSource reference\n\n`observed_at`\n\n,`valid_from`\n\n,`valid_to`\n\n,`recorded_at`\n\nA superseded-record pointer\n\nAuthor or agent identity\n\nRun and tool-call IDs\n\nApproval and access policy\n\nSchema version\n\nConfidence, stored separately from provenance\n\nDon’t let the structure of a transcript or checkpoint determine the domain schema.\n\n## When a Separate Context Graph Is Worth It\n\nNot every agent needs a separate durable state layer.\n\n[Anthropic's multi-agent system](https://www.anthropic.com/engineering/multi-agent-research-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.\n\n[Cognition initially favored single-threaded agents](https://cognition.com/blog/dont-build-multi-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.\n\nUse 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.\n\nProduction 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](https://pages.temporal.io/rs/250-WIU-007/images/Temporal-AI-Enterprise-WP.pdf?version=0). In a [two-part](https://www.mabl.com/blog/how-we-built-a-system-for-ai-agents-to-ship-real-code-across-75-repos) [engineering report](https://www.mabl.com/blog/how-we-built-a-system-for-ai-agents-to-ship-real-code-across-75-repos-part-2), 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%](https://www.mabl.com/blog/how-we-built-a-system-for-ai-agents-to-ship-real-code-across-75-repos), effectively using those tools as an external state layer.\n\n## How to Add a Context Graph Without Replacing Your Orchestrator\n\n### Step 1: Audit what you persist today\n\nWalk 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.\n\n### Step 2: Externalize one critical entity\n\nPick 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.\n\n### Step 3: Add provenance to one decision path\n\nChoose 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](https://hydradb.com/blog/ai-agent-decision-traceability-auditability) connects the evidence, policy, approval, and action so the decision can be reconstructed later.\n\n## How HydraDB Supports Application-Owned Ontologies\n\nHydraDB provides [graph-native context infrastructure](https://hydradb.com/blog/ai-context-graph-ontology-infrastructure) beneath the orchestrator without imposing a fixed application ontology. By default, it [extracts relationships during ingestion](https://docs.hydradb.com/essentials/v2/context-graphs) and stores them as `source → relation → target`\n\ntriplets. Queries can return the relevant graph paths alongside ranked chunks, so applications receive both retrieved content and the relationships around it.\n\nWhen an application already maintains a curated knowledge graph, ontology, or database export, [Bring Your Own Graph](https://docs.hydradb.com/essentials/v2/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`\n\nresponse as extracted relationships.\n\nThe application owns the ontology. It defines what entity types and predicates such as `CUSTOMER`\n\n, `CONTRACT`\n\n, `OWNS`\n\n, or `SUPERSEDES`\n\nmean, how records from different systems resolve to canonical entities, and which constraints govern updates.\n\n## Graph Engineering Still Inherits Distributed-Systems Problems\n\nAgent systems inherit distributed-systems failures, then add probabilistic reasoning, context limits, and semantic ambiguity.\n\nRetry 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.\n\nEngineers already know the tools: idempotency, event sourcing, schema evolution, optimistic concurrency, transactions, access control, and lineage.\n\nNo ratified, broadly adopted interoperability standard defines a shared domain model for agent memory. The [current Model Context Protocol specification](https://modelcontextprotocol.io/specification/2026-07-28/basic) defines interoperability for context exchange, including tools, resources, and prompts. It does not define a shared memory model. Early drafts, including the [memorywire preprint](https://arxiv.org/abs/2606.01138) and the [Agent Memory Protocol](https://agentmemoryprotocol.io/), cover parts of the problem but remain fragmented.\n\nUntil 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.\n\nKeep your orchestrator. Add a graph-native context layer beneath it. [Start building an application-owned context graph with HydraDB](https://docs.hydradb.com/get-started/v2/introduction).\n\n## FAQ\n\n### What is graph engineering for AI agents?\n\nGraph 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.\n\n### How is graph engineering different from loop engineering?\n\nLoop 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.\n\n### How do prompt, context, harness, loop, and graph engineering differ?\n\nPrompt 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.\n\n### What is the difference between an execution graph and a context graph?\n\nAn 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.\n\n### Can LangGraph persist durable domain state?\n\nLangGraph 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.\n\n### When do AI agents need an ontology?\n\nAgents need an ontology when several workflows or applications must interpret the same entities and relationships consistently. The ontology defines what concepts such as `CUSTOMER`\n\n, `CONTRACT`\n\n, and `POLICY`\n\nmean and how relationships such as `OWNS`\n\n, `APPROVED_BY`\n\n, or `SUPERSEDES`\n\nshould be interpreted. It supplies shared meaning, while the state layer supplies durability and operational guarantees.\n\n### When does an AI agent need a separate context graph?\n\nA 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.\n\n### How does HydraDB support application-owned ontologies?\n\nHydraDB 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.", "url": "https://wpnews.pro/news/graph-engineering-execution-graphs-vs-context-graphs", "canonical_source": "https://hydradb.com/blog/graph-engineering-ai-agents-context-graph", "published_at": "2026-08-14 02:16:40+00:00", "updated_at": "2026-08-14 02:40:54.874004+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure"], "entities": ["LangChain", "Peter Steinberger", "Chroma", "GPT-4.1", "Claude 4", "Gemini 2.5", "Qwen3", "HydraDB"], "alternates": {"html": "https://wpnews.pro/news/graph-engineering-execution-graphs-vs-context-graphs", "markdown": "https://wpnews.pro/news/graph-engineering-execution-graphs-vs-context-graphs.md", "text": "https://wpnews.pro/news/graph-engineering-execution-graphs-vs-context-graphs.txt", "jsonld": "https://wpnews.pro/news/graph-engineering-execution-graphs-vs-context-graphs.jsonld"}}