# Graph engineering _Thread · sourced_ Two uses of graphs that are often confused: graphs that connect information, and graphs that connect work. ## Guided worked example · Engineering & technical work Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Compare different meanings of a graph within one task: relationships in information, transitions in a workflow, and coordination between agents. Follow what each representation helps explain. **Assumptions:** Nodes and edges need an explicit meaning. A knowledge relationship is not an instruction to execute a step or delegate an action. **Design choices:** Choose the graph type for the question and combine representations only with clear interfaces. A simple list can be better when relationships add no useful structure. **Request:** Explain a recall using information, workflow, and agent graphs. **Starting evidence:** Information: lot L7 → board B2 → P8. Workflow: verify → draft notice → approve. Agents: investigator → reviewer. **Action and control:** Keep edge meanings explicit: fact relationship, allowed transition, or handoff. **Stage records (authored, not executed):** ### Input record Information: lot L7 → board B2 → P8. Workflow: verify → draft notice → approve. Agents: investigator → reviewer. What changed: Establish the facts supplied for this version of the task. ### Design note Choose the graph type for the question and combine representations only with clear interfaces. A simple list can be better when relationships add no useful structure. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Keep edge meanings explicit: fact relationship, allowed transition, or handoff. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative P8 is an affected candidate; investigator prepares evidence; notice workflow waits for approval. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Three small linked graphs with explicit node/edge meanings and the same case followed across them. If the result falls short: If a conclusion or transition is confusing, inspect edge semantics and missing data before adding more nodes. Distinguish a broken data join from a broken workflow. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Apply this to dependencies, processes, or agent coordination. Name what every edge means and what it does not imply. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** P8 is an affected candidate; investigator prepares evidence; notice workflow waits for approval. **Change something — Treat the dependency edge as an instruction to notify:** Verification and approval are skipped. Restore the information/action distinction. **Decision:** Does an information edge authorize an operation? **Answer:** No; it describes a relationship. **Why:** An edge meaning depends on the graph; knowing a dependency does not authorize a workflow action. **Review criteria:** Three small linked graphs with explicit node/edge meanings and the same case followed across them. **Recovery:** If a conclusion or transition is confusing, inspect edge semantics and missing data before adding more nodes. Distinguish a broken data join from a broken workflow. **Adapt it:** Apply this to dependencies, processes, or agent coordination. Name what every edge means and what it does not imply. > Knowledge graphs connect information; agent graphs connect work. Graphs describe connections. First ask what the connections mean: relationships between facts, or transitions between pieces of work. A knowledge graph is a data model. Workflow and agent graphs describe execution. An application can combine them: an agent can query a knowledge graph during a workflow step. ## Three meanings of an arrow | | Knowledge graph | Workflow graph | Agent graph | |---|---|---|---| | A node represents | An entity, concept, or claim | An operation or subworkflow | An agent or another operation in a composed system | | An edge represents | A named relationship | An allowed transition or dependency | A handoff or another allowed transition | | A useful question | Which parts fit this model? | What runs after validation fails? | Which specialist handles the next subtask? | | What you design | Identity, relationships, provenance, updates | Steps, state contracts, branch policy, recovery | Roles, tools, context, handoffs, authority, limits | ## The boundary is about control A conditional edge is not automatically agentic. A workflow can use a model to classify an input and route to a predefined handler. An agent can choose a next action based on what it discovers. A mixed system can do both. This guide places common knowledge-graph applications at level 2, workflows at level 3, and teams at level 6. These are teaching groupings, not framework requirements. Several nodes do not necessarily make a team. ## What the picture leaves out **Dynamic routing still needs design.** Define destinations, handoff data, permissions, and termination behavior before allowing a model to choose between them. **Checkpointing is an implementation choice.** A graph does not inherently save after every node. Configure persistence deliberately and check the framework’s recovery semantics. **Relationships need evidence.** Knowledge graphs can be authored manually, imported from structured systems, or extracted from text. Entity identity, incorrect edges, stale facts, and missing relationships still need attention. ## Choose a representation for the task Use a knowledge graph when explicit relationships help answer your questions. Use a workflow graph when branches, dependencies, or recovery paths are worth making explicit. Use an agent graph when delegating decisions across agents has a concrete advantage over one agent or a fixed process. Start with [retrieval](/gradient_ascent/techniques/rag/) or [a sequential workflow](/gradient_ascent/techniques/prompt-chaining/) when it already meets the task. Draw exits, errors, retries, and handoffs as well as the happy path. ## Sources 1. [Graph API overview](https://docs.langchain.com/oss/python/langgraph/graph-api) — LangChain (accessed 2026-09-20) ## Pages that carry it - [Knowledge graphs and GraphRAG](/gradient_ascent/techniques/knowledge-graphs/) (sourced): Storing facts as entities and relations, for questions that span several documents. - [Workflow graphs](/gradient_ascent/techniques/workflow-graphs/) (sourced): Describing a workflow as steps and the connections between them. - [Agent graphs](/gradient_ascent/techniques/agent-graphs/) (sourced): Describing a team of agents and how work passes between them. Last reviewed 2026-09-20.