Open Data Infrastructure
Data Modeling State Machines for Agentic Workflows
How explicit state machines keep approvals, denials, retries, compensating actions, and evidence packets out of vague status strings.
A status column is not a workflow model just because it contains words that sound official.
Agentic workflows need explicit states
Agentic workflows move through states such as proposed, validated, denied, approved, executing, retried, partially complete, compensated, and closed. If the data model hides those states in a free-form status string, the agent has to guess what is safe to do next.
State machines make the allowed transitions explicit. They help the system distinguish a retry from a new request, a denial from a policy block, a partial failure from a complete failure, and a compensating action from ordinary cleanup.
Core idea: Agentic data models should represent workflow states and transitions explicitly so action boundaries stay reviewable.
Transitions are governance evidence
The W3C State Chart XML specification is one formal model for state machines. Teams do not need SCXML to model every workflow, but they do need the core discipline: named states, allowed transitions, events, actions, and final states.
For ODI, the state model should connect to policy decisions, owner approvals, write attempts, idempotency keys, evidence packets, and incident review. That is how the platform tells an agent, and later a human, what happened and what can happen next.
Patterns that work
- Model workflow states as controlled values with documented transitions.
- Store the event, actor, policy decision, and evidence packet for each transition.
- Separate denied, failed, timed out, partial, compensated, and completed states.
- Require explicit owner approval before transitions that create durable writes.
- Test illegal transitions so agents cannot skip review states.
For adjacent ODI context, read exception states for agent workflows, agentic data human review queues, and agentic data reconciliation workflows.
What breaks first
- A single status value hides whether a workflow failed, timed out, or was denied.
- An agent retries a workflow that is waiting for human approval.
- Compensating actions are stored as notes instead of state transitions.
- Incident reviewers cannot tell which policy decision allowed a transition.
Questions to ask
- Which states are allowed for this workflow?
- Which transitions require policy checks, owner approval, or human review?
- Which evidence is captured at each transition?
- Can the agent explain why the next action is allowed or blocked?
Sources to start with
These primary sources anchor the technical claims in this guide.
- W3C State Chart XML specification
- Model Context Protocol specification
- Open Policy Agent documentation
If the agent can change the workflow, the workflow state cannot live in vibes.