Graph Engineering: Execution Graphs vs. Context Graphs

Graph Engineering for AI Agents Needs Two Graphs - HydraDB Architecture Benchmarks Pricing Use Cases Resources Documentation Log In Sign Up Architecture Benchmarks Pricing Use Cases Resources Documentation Log In Sign Up Aug 13, 2026 12 min Graph Engineering: Execution Graphs vs Context Graphs Manveer Chawla Updated on : Aug 13, 2026 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, permiss [truncated for AI cost control]