A user kicks off an agentic workflow. The agent lays out what it’s going to do: gather the inputs, classify the request, draft the response, route it for approval. The user steps back and lets it run.
Halfway through, an input goes missing, and the screen still says “working.” Did the route change? Which partial results are still usable? What should the user do next, if anything? Older software rarely had to answer questions like these.
Deterministic states were simpler
Traditional software usually knows what state it’s in. An action is available, processing, complete, failed, or waiting for input. Design systems standardized those conditions and made the product predictable.
AI creates states that sit between the old categories.
The system can understand the request but lack evidence. It can finish most of a task and become blocked by one permission. It can produce a usable answer with one weak claim. It can change its plan because a source failed. It can be certain about the data and unsure about the recommendation.
Call all of that “working” and the interface hides the exact information the user needs to trust the result.
A state needs a name before it needs a style
Useful agentic states include:
- Interpreting: determining intent and scope.
- Gathering: retrieving context or evidence.
- Planning: choosing steps before acting.
- Acting: changing internal or external state.
- Waiting: blocked on the user, a person, a source, or permission.
- Rerouting: changing approach while preserving completed work.
- Partially complete: useful work exists, but the job isn’t finished.
- Low confidence: the result needs focused review or more context.
- Ready for approval: the system has prepared work but hasn’t committed it.
- Completed with caveats: the job landed, with limitations the user should see.
- Reverted: the previous state has been restored.
- Escalated: responsibility has passed to a person with context intact.
The labels don’t all need to appear literally. The underlying distinctions need to affect behavior.
A state must change the next move
A confidence badge with no consequence is decoration.
Low intent confidence should cause the system to ask. Weak evidence should expose sources and prevent risky automation. A blocked state should explain the reason, preserve progress, and offer a valid route forward. A partial result should separate what’s usable from what remains unresolved. A meaningful reroute should say what changed, what the new plan is, and what happens to the work already done.
Reroute without saying so and the user feels hijacked. Pause without explanation and they feel babysat.
The state tells the user what happened and tells the product what actions are allowed.
A state inventory records that contract for each state.
Fill-in table
State inventory
Start with a real workflow. Add a row whenever a changed condition changes what the system or person can do.
| State and entry condition | What the system knows | What the person sees | Available next moves | Work retained |
|---|---|---|---|---|
| Which state is this, and what put the workflow there? | Which input, evidence, or decision is available, missing, or uncertain? | What happened, what is uncertain, and what happens next? | What can the person inspect, provide, approve, stop, reroute, undo, or wait for? | Which inputs, decisions, or output stay usable if the workflow changes? |
Example
State inventory: a draft that lost its policy record
A policy record goes missing while the opening workflow prepares a draft. This entry shows what changes for the user and which work remains usable.
- State and entry condition: Rerouting. The policy record the draft depends on is missing, so the agent skips the blocked step and prepares a different part first. The stakes haven’t escalated, so it announces the reroute instead of pausing for a decision.
- What the system knows: It has the ticket summary. It does not have the policy the draft depends on.
- What the person sees: It says what changed and gives a new plan. “I’m going to prepare the customer history first, then come back to the draft once the policy is attached.”
- Available next moves: Not known yet: What can the user inspect, provide, approve, stop, reroute, or undo while the policy record is missing?
- Work retained: “The ticket summary still holds; the draft reply is stale, so I’m holding it until the policy check is done.”
Progress should describe the job
“75% complete” can be less honest than silence if the system can’t know. A percentage implies a stable denominator. Many agentic tasks don’t have one.
Show meaningful work instead: four of six sources reviewed, draft assembled, waiting for approval, public-source search available, twelve findings preserved. Let the user inspect completed portions where possible.
A good progress state reduces uncertainty. A fake progress indicator merely delays frustration.
The design system should own state semantics across AI features
When each feature team invents its own language, one surface says “thinking,” another says “generating,” and a third says “agent running.” Approval, completion, and recovery mean different things in different places.
The design system should own state semantics across AI features: what each state means, what it shows, what actions it permits, how it transitions, and what must be preserved.
Run a state inventory
For each AI workflow, document the states, then test the unhappy paths:
0 of 7 done
