Open Data Infrastructure
Data Modeling Exception States for Agent Workflows
Why agent-facing data models need explicit exception states for denied access, missing evidence, stale context, partial writes, and human review.
Agent workflows fail badly when the data model pretends every state is normal.
Exceptions need first-class states
Traditional data models often focus on successful business states. Agent workflows need more. They need denied access, missing evidence, stale context, partial write, quarantined result, needs review, and failed validation states that are explicit enough for machines and humans to handle.
If those states are not modeled, they become prose in logs, prompt instructions, or one-off error messages. That is how governance disappears from the workflow right when it matters.
Core idea: Agent-facing data models should represent exception states as normal infrastructure, not rare application errors.
Trustworthy systems need explainable failure states
NIST AI RMF frames trustworthy AI as a lifecycle risk-management problem. MCP tool calls connect models to external systems. Those two facts collide when a tool cannot return clean data but still has to return something useful.
Exception states give the workflow a controlled vocabulary. Denied is different from missing. Stale is different from partial. Needs review is different from failed. Each state should have a required evidence packet and allowed next action.
Patterns that work
- Model denied, stale, missing evidence, partial write, quarantined, and human review as explicit states.
- Attach required evidence fields to each state.
- Define which states can reach users, tools, memory, and writes.
- Make exception states visible in metrics and incident review.
- Use the same state names across APIs, tables, prompts, and runbooks.
For adjacent ODI context, read event-centric context for agents, semantic identifiers for agents, tool result quarantine.
What breaks first
- A tool returns null when access was denied, so the agent treats it as missing data.
- Stale context is returned with no freshness warning.
- Human review exists outside the workflow state model.
- Partial writes are recorded as success because no partial state exists.
Questions to ask
- Which exception states can an agent workflow produce?
- What evidence is required for each state?
- Which states block downstream action?
- Are state names consistent across data products and tools?
Sources to start with
These primary sources anchor the technical claims in this guide.
The exception state is not edge-case decoration. It is the workflow telling the truth.