Each graph type answers a different question
A knowledge graph answers what the system knows about the world. A workflow graph answers what should run next and under which conditions. A reasoning graph answers why a conclusion was chosen. A state and memory graph answers what happened and what should persist. Each models a different set of relationships, carries its own invariants, queries, and failure modes, and belongs on the simplest substrate that can answer it.
The short version
Graph engineering is the practice of designing systems that show relationships between data. The practice grew from graph theory and now supports semantic data, workflow systems, AI search, and agent memory. The four-part model on this page provides a starting taxonomy and build guide for using graphs in your projects.
Example A graph can represent a driver and a car as entities and connect them
with a DRIVES relationship. A graph-aware search system can use that relationship
to answer which car the driver uses.
Start with the relationship your system needs
The logical graph defines the relationships your system must understand. The substrate stores or runs that graph. PostgreSQL, JSON event logs, workflow engines, RDF stores, and graph databases can all support graph-shaped systems.
Related terms and their roles
- Graph neural network
- A model architecture that learns from graph-structured data. Its role is graph machine learning. Knowledge and workflow graphs describe different system responsibilities.
- Computation graph
- A graph of mathematical operations used for execution and differentiation inside ML systems.
- Vector index graph
- A structure such as HNSW that accelerates nearest-neighbor search. It organizes retrieval paths. Application records and governed relationships provide domain meaning.
- Graph visualization
- A view of nodes and links. The picture displays a graph. Graph engineering defines the model, rules, and operation behind it.
The field converged from several histories
Graph engineering combines practices that matured at different times. Graph theory created the foundation. Semantic data, workflow systems, AI search, and agent memory expanded how engineers use the model.
- 1736
A route became nodes and edges
Euler reduced the Seven Bridges of Königsberg problem to places and connections. The abstraction mattered more than the map and became a foundation of graph theory.
Oxford Academic ↗ - 1999
Relationships became web data
The W3C published RDF as a way to represent machine-readable statements and relationships on the web. RDF graphs express subject-predicate-object triples.
W3C ↗ - 2000s
Property graphs made traversal application-friendly
Property-graph databases put properties on both nodes and relationships. Neo4j's vendor history dates its model to 2000 and its first open-source release to 2007.
Neo4j history ↗ - 2012
Knowledge graphs entered mainstream search
Google's Knowledge Graph popularized search over entities and their relationships. Search could connect things and their meaning as well as matching strings.
Google ↗ - 2023
LLM systems made reasoning and memory graph-shaped
ReAct, Tree of Thoughts, Graph of Thoughts, and generative-agent memory systems made actions, alternatives, evidence, reflection, and persistent experience explicit system structures.
Graph of Thoughts ↗ - 2024+
Standards matured while AI graph patterns expanded
ISO published GQL for property graphs, while GraphRAG joined knowledge graphs with LLM retrieval. The data foundations are mature; many AI reasoning and memory patterns are still evolving.
ISO GQL ↗
Four graph types share one repeatable build method
Each graph type answers a different system question. Choose a type to see its nodes, edges, use cases, build steps, invariants, verification queries, and failure modes.
Knowledge graph
Represent durable entities, claims, events, concepts, and the meaningful relationships among them.
- Primary question
- What does the system know about the world?
- Typical lifetime
- Long-lived
- Starter nodes
- Entity · Claim · Event · Concept · Source
- Starter edges
RELATES_TO · MENTIONS · SUPPORTS · CONTRADICTS · DERIVED_FROM
Use it when
- Relationships have domain meaning beyond one process run.
- Questions require multi-hop traversal, entity resolution, or provenance.
- Users need to connect evidence across many sources.
Choose another approach when
- The data is naturally tabular and every useful query is a shallow join.
- The team cannot define stable identities or meaningful relationship types.
Build this graph Recipe, invariants, queries, risks
Minimal implementation recipe
- Write the five questions the graph must answer before designing a schema.
- Define stable entity IDs, alias rules, and merge/split behavior.
- Name a small set of precise relationship types and their direction.
- Attach source, time, confidence, and validation to every assertion.
- Build extraction and entity-resolution paths, then test them on reviewed examples.
- Measure answer quality and graph quality separately.
Required invariants
- Every claim or relationship has provenance.
- Extraction confidence remains separate from verified truth.
- Time-varying facts preserve prior versions when they change.
- Identity rules produce the same canonical entity for the same input.
Verification queries
- Which sources support or contradict this claim?
- Which entities connect these two topics within two hops?
- Which aliases remain unresolved or conflict with each other?
Suitable starting substrates
- PostgreSQL tables
- RDF + SPARQL
- Property graph
- SQLite for a bounded local graph
Common failure modes
- Entity duplication
- Vague predicates
- Lost provenance
- Ontology before questions
Execution / workflow graph
Represent tasks, states, gates, dependencies, retries, joins, approvals, and recovery paths.
- Primary question
- What should run, in what order, and under which conditions?
- Typical lifetime
- Per definition and per run
- Starter nodes
- Task · Gate · Run · Approval · Artifact · Terminal state
- Starter edges
DEPENDS_ON · ON_SUCCESS · ON_FAILURE · RETRIES · WAITS_FOR · PRODUCES
Use it when
- The system has branches, retries, waits, parallel work, or human approvals.
- A run must resume after process failure or interruption.
- Operators need to explain why a run is blocked or which path it took.
Choose another approach when
- The process is a short, deterministic sequence that plain code expresses more clearly.
- The proposed graph would make side effects harder to observe.
Build this graph Recipe, invariants, queries, risks
Minimal implementation recipe
- Define start, waiting, failure, cancellation, and terminal states.
- Give each task a typed input, output, owner, timeout, and idempotency rule.
- Model success, failure, retry, compensation, and approval transitions explicitly.
- Persist run state or event history before adding parallelism.
- Add checkpoints and a safe resume rule for long-running work.
- Trace every transition and verify both success and failure paths.
Required invariants
- Every run is terminal, waiting on a named condition, or actively owned.
- Retries are bounded and side effects are idempotent or compensated.
- A transition must be valid from the current state.
- A resumed run cannot silently repeat a completed external action.
Verification queries
- Which nodes are ready to execute?
- Why is this run blocked, and what can unblock it?
- Which downstream work is invalidated by this failure?
Suitable starting substrates
- Plain code + typed state
- Workflow engine
- Durable event history
- DAG scheduler
Common failure modes
- Unbounded retries
- Hidden side effects
- No recovery path
- Framework for a straight line
Reasoning graph
Represent goals, questions, assumptions, evidence, alternatives, tests, decisions, and observed outcomes.
- Primary question
- Why should the system choose this conclusion or action?
- Typical lifetime
- Per decision; retain selectively
- Starter nodes
- Goal · Question · Hypothesis · Evidence · Alternative · Test · Decision · Outcome
- Starter edges
DECOMPOSES_INTO · SUPPORTS · REFUTES · TESTED_BY · SELECTED_OVER · VERIFIED_BY
Use it when
- A consequential decision must remain explainable after the model call ends.
- The system must compare alternatives, gather evidence, or backtrack.
- Reviewers need to trace a conclusion to tests and external observations.
Choose another approach when
- A deterministic rule or direct lookup already answers the question.
- The design would store unrestricted hidden chain-of-thought or sensitive deliberation.
Build this graph Recipe, invariants, queries, risks
Minimal implementation recipe
- Decide whether the graph is transient search, a durable decision record, or both.
- Set a branch, token, time, and tool budget before exploring alternatives.
- Link claims to external evidence and observations. Keep the source material in its governed location.
- Persist concise assumptions, alternatives, rationale, decision, and uncertainty.
- Link each decision to the test or outcome that later verified or contradicted it.
- Prune failed branches and expire stale evidence under an explicit policy.
Required invariants
- Model confidence never becomes authority by itself.
- A durable decision cites evidence and records uncertainty.
- The durable record contains concise rationale and evidence. Hidden chain-of-thought stays outside the record.
- A failed test can invalidate dependent decisions.
Verification queries
- Which decisions rely on unverified assumptions?
- What evidence supports this conclusion, and what refutes it?
- Which rejected alternative should be reconsidered after this result?
Suitable starting substrates
- Typed JSON records
- SQLite or PostgreSQL
- Transient search tree
- Graph store after measured need
Common failure modes
- Branch explosion
- Transcript-as-reasoning
- Stale evidence
- Confidence as permission
State & memory graph
Represent events, checkpoints, episodes, memories, summaries, versions, scope, and continuity across runs.
- Primary question
- What happened, what is true now, and what should persist?
- Typical lifetime
- Session to long-lived
- Starter nodes
- Agent · Session · Run · Event · Checkpoint · Episode · Memory · Summary
- Starter edges
OCCURRED_IN · PRECEDED_BY · UPDATED · SUMMARIZED_BY · RECALLED_FOR · SUPERSEDES
Use it when
- The system must resume, reconstruct state, or remember across sessions.
- Multiple agents need shared coordination history with clear scope.
- Old information must be superseded, expired, or traced to its origin.
Choose another approach when
- A stateless request is complete after one response.
- The system lacks retention, deletion, permissions, or conflict policies.
Build this graph Recipe, invariants, queries, risks
Minimal implementation recipe
- Separate authoritative current state, event history, selected memory, and lossy summaries.
- Record immutable events and derive current state when replay is practical.
- Add checkpoints with schema and software-version compatibility rules.
- Define what becomes memory, when it is retrieved, and when it expires.
- Scope reads and writes by user, agent, tenant, project, or thread.
- Propagate supersession and deletion into every derived index.
Required invariants
- One source is authoritative for current state.
- Every memory has scope, provenance, and a review or expiry policy.
- Newer memory supersedes older memory without erasing history.
- Deleting a source also removes or invalidates derived retrieval records.
Verification queries
- What was the run state at this time?
- Which checkpoint can safely resume execution?
- Which memory supersedes this older memory, and why was it recalled?
Suitable starting substrates
- Append-only event log
- Checkpoint store
- SQLite/PostgreSQL projection
- Memory store + retrieval index
Common failure modes
- Stale memory
- Unbounded checkpoints
- Cross-scope leakage
- Shared writes without governance
Choose the simplest substrate that fits
Start with infrastructure your application already trusts. Adopt a dedicated graph system when query depth, latency, scale, or interoperability requirements justify the change.
JSONL + SQLite
Local tools, prototypes, event history, and shallow cross-run queries.
Start here when append, replay, portability, and low operations cost matter most.PostgreSQL
Existing applications with transactions and bounded relationship traversals.
Use joins, recursive CTEs, indexes, and materialized projections before adding a new datastore.RDF + SPARQL
Semantic interoperability, shared vocabularies, ontologies, and linked data.
Choose it when the meaning and exchange of statements matter across systems.Property graph
Frequent, variable-depth, relationship-centric traversal and exploration.
Adopt it when measured queries are awkward or slow on the current substrate.Workflow engine
Long-running execution with retries, timers, signals, approvals, and recovery.
Choose durable execution when the system needs operational guarantees across time and failure.AI uses graphs around the model
Graph engineering structures the context, control, decisions, and continuity around an AI model. The graph gives the system explicit relationships the model can retrieve, follow, evaluate, or update.
Ground retrieval
Entity and claim graphs connect evidence across relationships. GraphRAG combines those relationships with vector similarity and community summaries for corpus-level questions.
Control agents
Workflow graphs represent tool calls, branches, retries, joins, approvals, checkpoints, and recovery as explicit product behavior. This structure keeps execution rules visible and testable.
Structure decisions
Search graphs can explore candidate paths. Durable reasoning graphs preserve concise evidence, alternatives, tests, and decisions without storing hidden chain-of-thought.
Preserve continuity
Events, episodes, checkpoints, summaries, and supersession links let an agent resume work and recall relevant context across sessions.
How RossLabs tools use graph structures
These examples use architecture already published on this site. The descriptions remain at the product-pattern level and exclude private content, personal information, local paths, source filenames, and private graph relationships.
Atomize AI
KnowledgeExtracts entities and relationships from research sources, filters graph noise, and uses the graph to support cross-source synthesis.
Read the public architecture →Market Research Platform
Knowledge + executionUses deterministic entity extraction and an embedded graph for document-to-entity retrieval, while a small in-house runner handles simple pipeline flow.
Read the public architecture →Build Loop
Execution + reasoning + stateRuns Assess → Plan → Execute → Review → Iterate → Learn as a gated workflow. Plans, evidence, findings, tests, and run history provide the adjacent reasoning and state records.
Read the public architecture →Agent Rally Point
State & memoryUses an append-only coordination ledger and a rebuildable projection for claims, decisions, risks, artifacts, handoffs, and acknowledgements.
Read the public architecture →Personal LLM Wiki
KnowledgeCombines vector and lexical retrieval with graph-aware reranking over authored relationships. This public reference covers the architecture. Private notes, sources, filenames, and relationships remain private.
Read the public architecture →Sources and confidence
Overall confidence is high for the historical milestones, standards, graph data models, and workflow concepts. Confidence is moderate for the unified “graph engineering” field. The four-part taxonomy is a practical synthesis created for this guide.
Graph Engineering for AI-Native Systems
The supplied 39-page report shaped the four-part working taxonomy. Its externally checkable claims were verified against the sources below.
Euler and the Bridges of Königsberg ↗
Historical basis for graph theory's 1736 origin story.
RDF 1.1 Concepts and Abstract Syntax ↗
Defines RDF graphs and subject-predicate-object triples.
ISO/IEC 39075:2024: GQL ↗
Defines data structures and operations for property graphs.
Knowledge Graphs ↗
Covers graph models, creation, enrichment, quality, identity, and publication.
Introducing the Knowledge Graph: things, not strings ↗
Google's 2012 launch and entity-first search framing.
From Local to Global: A Graph RAG Approach ↗
Knowledge-graph indexing and community summaries for corpus-level retrieval.
ReAct: Synergizing Reasoning and Acting ↗
Interleaves actions, observations, and reasoning during task execution.
Tree of Thoughts ↗
Explores and evaluates multiple candidate reasoning paths.
Graph of Thoughts ↗
Models thought units and dependencies as an arbitrary graph.
LangGraph Graph API and persistence ↗
Current workflow-graph and checkpoint concepts.
Generative Agents: Interactive Simulacra of Human Behavior ↗
Memory stream, reflection, retrieval, and planning for agents.
PROV-O: The PROV Ontology ↗
A standard vocabulary for entities, activities, agents, derivation, and attribution.