{
  "schemaVersion": 1,
  "id": "atlas-lesson-workflow-graphs-state",
  "title": "Workflow graphs and explicit state",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Compare a fixed DAG/state machine, model-assisted node and model-directed tool choice on one task.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/workflow-graphs-state/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "From request to durable action",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. This denotes an authored transition system. It does not state that a stochastic model policy is deterministic unless its returned decisions are recorded.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/workflow-graphs-state-44fd1755c7c48aed.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#workflow-graphs-state",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "bf5721d094740420853701ae5bc933ba3c58d8bfac55986edd7ea883d51e36b2",
  "contentLength": 6881,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-workflow-graphs-state.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-workflow-graphs-state.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Workflow graphs and explicit state",
      "start": 47,
      "end": 464
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 464,
      "end": 1908
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1908,
      "end": 1936
    },
    {
      "id": "section-4",
      "title": "Workflow graphs and explicit state · explicit relationship",
      "start": 1936,
      "end": 3079
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 3079,
      "end": 3659
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3659,
      "end": 4025
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 4025,
      "end": 4565
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4565,
      "end": 4841
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4841,
      "end": 4870
    },
    {
      "id": "section-10",
      "title": "What establishes that this incident was correctly handled?",
      "start": 4870,
      "end": 5271
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 5271,
      "end": 6142
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 6142,
      "end": 6672
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 6672,
      "end": 6695
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 6695,
      "end": 6881
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#workflow-graphs-state"
    },
    {
      "title": "Building effective agents",
      "url": "https://www.anthropic.com/engineering/building-effective-agents"
    },
    {
      "title": "LangGraph workflows and agents",
      "url": "https://docs.langchain.com/oss/python/langgraph/workflows-agents"
    },
    {
      "title": "n8n AI Agent node",
      "url": "https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/workflow-graphs-state-44fd1755c7c48aed.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Tools, memory & agent loop",
      "url": "https://semiaifoundry.com/learn/atlas/tool-loop/"
    },
    {
      "title": "Evaluation & the AGI frontier",
      "url": "https://semiaifoundry.com/learn/atlas/evaluation/"
    }
  ],
  "recordHash": "d196f9b946f95ba387ec30213c7f752c7c0e6226e2c6fcb00c1ed650c7bd8e18",
  "contentFormat": "text/markdown",
  "content": "From request to durable action · Atlas v1.3.0\n\n# Workflow graphs and explicit state\n\nCompare a fixed DAG/state machine, model-assisted node and model-directed tool choice on one task.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#workflow-graphs-state)Logical state, task evidence and declared units; no physical assembly scale\n\nLearning objectiveIdentify the owner of each transition and distinguish workflow completion from a satisfied external goal.\n\n## The mechanism\n\nA workflow represents progress as state and permitted transitions. A node may compute a value, call a service, wait for input or select the next step. The important distinction is who chooses the transition and what evidence permits it. A fixed workflow follows authored control flow; a model-assisted workflow can use a prediction inside that flow; a model-directed system can propose its next operation from observations. None of these designs can turn a proposed tool call into an authorized effect by itself. The durable incident example compares a fixed workflow with an authored branching policy on the same environment and task. The latter can repair one malformed argument yet still choose the wrong manual fact. Its extra branches are visible source logic, not learned reasoning. Separating business state from the last message also makes the end condition testable: a worker can report completion while inventory or the work order is wrong.\n\n1.  The incident identity, target asset and allowed effects define a task before any node executes.\n2.  A transition consumes the current state and a recorded event; each tool node passes through validation and authority.\n3.  A review state stores an exact proposed action and waits for a decision instead of treating the wait as failure.\n4.  The policy can stop, retry or choose a next tool, but the independent environment checker evaluates the completed business state.\n\n## Science and assumptions\n\n### Workflow graphs and explicit state · explicit relationship\n\n$$\ns_{n+1}=f(s_n,e_n)\n$$\n\nThe next workflow state is obtained by applying the declared transition function to the current state and observed event.\n\nSymbols and units\n\nsₙ\n\nWorkflow state after n recorded transitions\n\nstate object\n\neₙ\n\nInput, tool result or review event for this transition\n\nevent object\n\nf\n\nDeclared transition function\n\nstate transition\n\nFor incident-017, both authored modes read FAN-7, obtain reference facts, reserve two FILTER-A units after review and create one linked work order. The normal run uses four calls. If the reference list begins with FAN-9, the fixed workflow selects the requested asset while the authored first-fact policy uses FAN-9. Both can reach their internal completed state. Only the FAN-7 environment satisfies the original goal. The comparison therefore measures the task after execution rather than rewarding a particular graph shape or the number of tool calls.\n\nAssumptions This denotes an authored transition system. It does not state that a stochastic model policy is deterministic unless its returned decisions are recorded.\n\n## Engineering example\n\nFor incident-017, both authored modes read FAN-7, obtain reference facts, reserve two FILTER-A units after review and create one linked work order. The normal run uses four calls. If the reference list begins with FAN-9, the fixed workflow selects the requested asset while the authored first-fact policy uses FAN-9. Both can reach their internal completed state. Only the FAN-7 environment satisfies the original goal. The comparison therefore measures the task after execution rather than rewarding a particular graph shape or the number of tool calls.\n\n## Distinctions and tradeoffs\n\nA graph containing an AI node is not automatically a model-directed agent.\n\nA fixed path is easy to inspect but needs explicit recovery branches; dynamic choice can adapt and can also choose an incorrect next action.\n\nAI becomes useful through the surrounding execution and verification system, not merely through a model invocation.\n\n## Specifications and interfaces\n\nMechanism boundary\n\nWhat decides the next step?\n\nThis denotes an authored transition system. It does not state that a stochastic model policy is deterministic unless its returned decisions are recorded.\n\nEvidence type\n\nAuthored worked example\n\nThe durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform.\n\n### Interfaces\n\nDeclared input and state Input\n\nThe incident identity, target asset and allowed effects define a task before any node executes.\n\nChecked outcome Output\n\nIdentify the owner of each transition and distinguish workflow completion from a satisfied external goal.\n\n## Check your understanding\n\n### What establishes that this incident was correctly handled?\n\n1.  The final environment matches the task and policy constraints\n2.  The last node is named complete\n3.  The graph contains more than one tool\n\nAnswer and reasoning\n\nThe final environment matches the task and policy constraints\n\nA completion label is a control state; the independently checked environment establishes the task result.\n\n## Evidence and scope\n\nThe durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. This denotes an authored transition system. It does not state that a stochastic model policy is deterministic unless its returned decisions are recorded.\n\nThe durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform.\n\n## Sources\n\n-   [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)\n-   [LangGraph workflows and agents](https://docs.langchain.com/oss/python/langgraph/workflows-agents)\n-   [n8n AI Agent node](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/workflow-graphs-state-44fd1755c7c48aed.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Tools, memory & agent loop](https://semiaifoundry.com/learn/atlas/tool-loop/)\n-   [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)"
}