How to Build an AI Workflow That Knows What Happens Next

What is a workflow state machine for AI work?

An AI agent workflow state machine is a saved list of stages and allowed moves. It tells the system where work is, what may happen next, why it stopped, and how it can resume.

The ordinary idea is simple. A product release can move from planning to building, then review, approval, and release. It cannot jump from building straight to release because someone says it looks ready.

AWS Step Functions uses the same core model. A workflow contains states, and transition rules decide which state comes next. Some states end the workflow.

Your team does not need AWS to use the idea. A table, a saved record, and one check at every move can be enough.

The state machine controls order. It does not prove that the work inside each stage was good. Review quality, release proof, and outside actions still need their own checks.

Why is a stage name not enough?

A label can describe the work without controlling it.

Imagine a record that says BUILD. An AI asks to change it to RELEASE. If the system checks only that both names are valid, it will accept the jump. The stage changed, but review never happened.

A real control checks BUILD -> RELEASE. It then compares that request with the allowed next move, BUILD -> REVIEW.

The request should fail. The result should say why it failed and what can happen next.

A checklist has a similar limit. It can remind someone to review. It does not stop a release when the review box is empty. A diagram can show the right order and still let the real process ignore it.

The rule is blunt: if a skipped stage does not change the system's decision, the workflow is still advice.

Which stages should the first workflow use?

Start with one real product flow. Do not model the whole company.

The table below uses a small release path. Each row names the current stage, the next allowed stage, the guard, the owner, and the safe response when the guard fails.

How should the workflow block a skipped review?

Every move should pass through the same check. That includes moves requested by a person, an AI, an automation, and a resumed session.

The check needs three inputs: the saved current stage, the requested next stage, and the guard evidence required for that move.

For the release example, the saved stage is BUILD and the requested stage is RELEASE. The requested move is BUILD -> RELEASE. The table allows only BUILD -> REVIEW, which means only REVIEW after BUILD.

Do not let the AI talk its way around this result. A confident release summary is not a transition rule. Neither is a prompt that says, "Never skip review."

The check has to sit where the status changes. That might be a workflow tool, a task system, an automation, or a person who refuses the move. If the status can change through another path, that path needs the same rule.

What should a stopped run save?

Sometimes the next move is valid, but the run still cannot continue. The reviewer is away. A required answer is missing. A tool failed. The session is ending.

Do not replace the current stage with a vague PAUSED label. Save the stage and the run status separately. A stopped run in BUILD is different from a stopped run in RELEASE.

The saved values were direct: Run status: STOPPED. Stopped at stage: BUILD. Required next stage: REVIEW.

The stop reason explains why progress ended. The next action tells a fresh person what to do. The acceptance criteria say what a useful result looks like. The evidence reference points to the saved work without stuffing it into the record.

On resume, read this record before reading old chat. Check that every required field is present. Then send BUILD to REVIEW through the same transition rule used during the live run.

What happened when I tested the three rules?

I ran a small local experiment with made-up release data. It used a temporary file, started one fresh process for the resume check, and made no network or outside-system call.

The test asked the workflow to make three decisions. The results matched the transition table.

The skipped-review result said, "RELEASE cannot follow BUILD. Complete REVIEW first."

The fresh process recovered this next action: "Review the saved build against the release criteria." It did not need hidden context from the first process.

This experiment proves only those three decisions in the small fixture. It does not prove production reliability, security, or review quality. It does not prove that an evidence reference exists or that a live release worked.

That limit matters. A state machine can force the work to visit REVIEW. It cannot make the review thoughtful.

What did WarpOS reveal about stage control?

I found the same gap while building WarpOS, my agentic operating-system project for long-running AI work.

At the frozen public version I reviewed, the outer sprint runner had a fixed order: plan, design, execute, release preparation, then retrospective. It could halt at key boundaries. It also saved a reason, a restart command, and checkpoints for a later run.

That is real control at the outer level.

The inner execution helper saved its loop number, stage, checks, stop reason, next action, and recovery summary. But it checked only whether the requested stage name was on an approved list. It did not compare the previous stage with the requested next stage.

In plain language, it could save REVIEW as a real stage. It did not yet prove that TEST had to come before REVIEW.

The audit found another useful warning. Some values written by the full-run checkpoint did not match the allowed values in its own saved-record rules. The checkpoint existed, but the contract around it had drifted.

So the honest conclusion is narrow: WarpOS enforced an ordered outer workflow and saved useful inner state. Its inner stage recorder was not yet a complete guarded transition system at that commit.

The lesson is uncomfortable but useful. Saved state is not the same as guarded state. A record becomes a control only when the next move is checked and a bad move fails.

How can your team build the first version this week?

Choose one workflow that already causes arguments. A release, research review, customer email, or content publication is enough.

Write no more than six working stages, plus one final state. For each stage, name the owner, allowed next move, required evidence, stop behavior, and resume action.

Then plant three tests. Ask for one valid move. Ask to skip one important review or approval. Stop the run, open a fresh session, and resume from the saved record.

The second test must fail. The third test must not need the old chat.

If the table works only when everyone remembers to follow it, you have a useful draft. You do not have a control yet. Connect it to the real status change and run the three tests again.