{"id":"workflow-graphs-state","name":"Workflow graphs and explicit state","shortName":"Workflow graphs and explicit state","role":"Compare a fixed DAG/state machine, model-assisted node and model-directed tool choice on one task.","description":"A 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.","mechanism":["The incident identity, target asset and allowed effects define a task before any node executes.","A transition consumes the current state and a recorded event; each tool node passes through validation and authority.","A review state stores an exact proposed action and waits for a decision instead of treating the wait as failure.","The policy can stop, retry or choose a next tool, but the independent environment checker evaluates the completed business state."],"learningObjective":"Identify the owner of each transition and distinguish workflow completion from a satisfied external goal.","engineeringExample":"For 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.","misconception":"A graph containing an AI node is not automatically a model-directed agent.","check":{"question":"What establishes that this incident was correctly handled?","options":["The final environment matches the task and policy constraints","The last node is named complete","The graph contains more than one tool"],"answer":0,"explanation":"A completion label is a control state; the independently checked environment establishes the task result."},"checks":[],"prerequisites":["tool-loop","evaluation"],"related":["tool-loop","evaluation"],"specs":[{"label":"Mechanism boundary","value":"What decides the next step?","context":"This denotes an authored transition system. It does not state that a stochastic model policy is deterministic unless its returned decisions are recorded."},{"label":"Evidence type","value":"Authored worked example","context":"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."}],"interfaces":[{"name":"Declared input and state","direction":"in","signal":"The incident identity, target asset and allowed effects define a task before any node executes."},{"name":"Checked outcome","direction":"out","signal":"Identify the owner of each transition and distinguish workflow completion from a satisfied external goal."}],"tradeoff":"A fixed path is easy to inspect but needs explicit recovery branches; dynamic choice can adapt and can also choose an incorrect next action.","whyAI":"AI becomes useful through the surrounding execution and verification system, not merely through a model invocation.","sourceIds":["automation-agent-patterns","automation-langgraph-workflows","automation-n8n-agent"],"sources":[{"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"}],"science":[{"title":"Workflow graphs and explicit state · explicit relationship","equation":"The next workflow state is obtained by applying the declared transition function to the current state and observed event.","explanation":"For 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.","assumptions":"This denotes an authored transition system. It does not state that a stochastic model policy is deterministic unless its returned decisions are recorded."}],"evidenceNotes":"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.","level":"software","branch":"From request to durable action","subbranch":"Workflow graphs and explicit state","scale":"Logical state, task evidence and declared units; no physical assembly scale","kind":"system","workstream":"W11","visualFamily":"software-flow","labId":"library","labScope":"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.","history":[],"workedTrace":{"normalCalls":4,"taskAsset":"FAN-7","decoyAsset":"FAN-9"}}