Workflow orchestration: coordinate dependencies, state and recovery

By Ai Flowi · Published 10 October 2026

Workflow orchestration coordinates which stages may run, the state of each stage and what happens when execution fails or becomes uncertain. It uses dependencies and outcome evidence to decide the next permitted action. A drawn sequence describes intended order; orchestration also needs rules for incomplete work, retries and recovery.

The example here coordinates a non-agent record update. It separates the logic of ordering from any claim that a particular runtime persists state, resumes automatically or provides transactional rollback.

Dependencies define readiness

A stage is ready only when its prerequisites are satisfied. Validation can begin once the input contract and authorised request are available. Writing requires accepted validation and destination identity. Verification needs an attempted-write reference or other outcome evidence. A follow-up intention should not be marked ready merely because execution reached the last box on a diagram.

A dependency is more precise than a visual position. If a write and a verification read run independently, the read may occur before the update is visible. If a dependent stage accepts any preceding output, an error object can be mistaken for a success record. Define the evidence each dependency requires, not only the name of the preceding node.

Original dependency and recovery table for a synthetic record update: on narrow screens, focus the table region and scroll sideways.

The notify-intent stage is an application record describing proposed follow-up work. It is not the Flowi Notify component, and a stored intention is not evidence that a person received a message. Keeping that distinction prevents an internal transition from being reported as completed external communication.

Use states that preserve uncertainty

Ready means the stage is permitted to begin. Running means an attempt is in progress. Succeeded means its defined acceptance condition has been confirmed. Failed means the known outcome did not satisfy that condition. Unknown means available evidence cannot determine whether the action completed. These are proposed application states, not extra native component fields.

In this contract, rejected validation leaves write blocked. An unknown write leaves verification eligible to gather evidence but keeps follow-up blocked. Those dependencies differ even though neither branch has a completed business result. A single overall failed flag would lose which stage may proceed.

Stage success is also narrower than overall completion. Validation succeeding does not imply writing succeeded, and a write acknowledgement does not necessarily establish the verification condition. Define completion as a set of required evidence-bearing outcomes rather than an optimistic final status string.

An unknown write changes the dependency path

The runbook example owns the lost-response investigation and replay decision; this dependency design consumes its reviewed outcome as evidence for later stages.

For synthetic record A17, an unknown write sets verification to ready for investigation, with attempt W4 attached. Follow-up remains blocked. The verification stage is allowed to collect evidence without asserting that writing succeeded. If the runbook supplies confirmation for W4 and the intended revision, verification can evaluate the business condition. An unresolved incident record leaves that condition unsatisfied.

Distinguish verification work from verification success. A read can execute correctly and show the wrong value; the stage has acquired evidence but has not met its acceptance rule. In that case record the mismatch and keep follow-up blocked. This distinction makes the next permitted action inspectable instead of relying on whether a node returned any output.

Is recovery the same as automatic rollback?

A failed later stage does not erase an earlier external write. Transactional rollback requires an actual transaction boundary. A compensating action is a new operation intended to offset an earlier effect; it can fail and may not recreate the original situation. Neither should be promised because a workflow has several connected steps.

For this update, recovery might leave the accepted destination change in place while correcting the missing verification record. Restoring an earlier status would need separate authority and evidence that no legitimate later update would be lost. The recovery plan must consider what happened outside the workflow, not just reset its internal boxes.

The AI agent state page explains storage, simultaneous updates and restart persistence; the following record addresses which prerequisite evidence permits a particular stage to resume.

Read a stage-specific restart record

Illustrative restart record, not executed runtime output
Work reference: synthetic-A17-status-change
Input revision: I3
Validation rule: C2
Validate: succeeded; evidence V9 covers I3 under C2
Write: unknown; attempt W4 concerns A17 and I3
Verify: ready for investigation; no accepted verification evidence
Follow-up: blocked; recipient reference R2 awaits verified result

If I3 and C2 remain the authorised inputs, validation does not need to repeat merely because verification was interrupted. Resume investigation using W4’s association with A17. If the input changes to I4, V9 cannot authorise a new write because it only covers I3. Preserve W4 as earlier work while validating the new request separately; changing the input revision must not relabel the earlier attempt.

If an accepted verification record already exists for W4, check its destination identity, compared revision and result before making follow-up ready. A record that only says “read succeeded” cannot satisfy the comparison rule. A recipient change from R2 to R3 can require renewed follow-up permission without invalidating the completed record update. Restart decisions therefore attach to each prerequisite rather than resetting every stage together.

AI Flowi Workflow: composition versus runtime guarantees

The Run Flow and Sub Flow references cover composition interfaces; their status for this coordination sketch is documented in the catalogue; not production-tested by Ai Flowi.

For an example configuration, not a recorded test, choose an existing validation-only flow using Run Flow’s flow_name_selected and inspect its actual returned evidence before designing a write stage. Keep recovery manual until the called-flow errors and state-storage contract have been verified. This sketch specifies intended evidence rather than invented execution output.

When a simpler sequence is enough

A short, reversible task with no external side effect may only need a straight sequence and a clear error result. Add durable coordination when restart behaviour, independent stages or consequential writes make it necessary. If an existing platform already provides the required verified execution contract, use that mechanism rather than recreating it through loosely connected status fields.

Before choosing a design, walk through invalid input, a known write rejection, a lost reply after writing and an interrupted verification. Each case should have a next action tied to evidence. An instruction to “retry everything” fails that review whenever an external action could already be complete.

Common mistakes and related reading

Avoid equating node order with durable orchestration, accepting an error payload as success, or treating unknown outcomes as safe retries. The AI agent state glossary owns agent-specific task records. A runbook example addresses operator recovery instructions. Event driven architecture explains delivery across producers and consumers, while this page owns dependency and recovery decisions.