Multi-step AI workflow design: make every handoff inspectable

Start with the final decision and work backward

Name the business decision, audience, final artifact, action owner, and consequence of error. Then list the minimum stages required to produce that artifact. Avoid adding an agent or model call merely because it is available. Every stage should have a purpose that can be tested independently.

Separate information retrieval, extraction, calculation, synthesis, recommendation, communication, and external action. The same acceptance test does not fit all stages. A retrieval stage needs source coverage and access checks; a calculation stage needs reproducibility; a drafting stage needs claim traceability; an action stage needs authorization.

NIST's current project on evaluation probes for agentic AI describes multi-step agents, tool use, evidence gathering, adversarial verification, and structured audit trails that map decisions to supporting documents. The project is research in progress, not a certification scheme or proof that any particular probe makes a workflow safe.

Sources: [1]

Write a contract for each stage

Each stage contract should specify:

Do not allow a later stage to repair missing evidence by inventing a plausible value. If the source is absent, the handoff should carry an explicit gap. If a unit or identifier changes, the invariant check should stop the chain.

• Purpose: the one transformation this stage performs.
• Permitted inputs: named sources, schemas, data classes, and freshness limits.
• Required output: structure, fields, evidence links, and uncertainty markers.
• Invariants: facts, units, identifiers, and authority boundaries that must not change.
• Principal failure: the most consequential plausible error at this stage.
• Acceptance test: an observable check that must pass before handoff.
• Failure route: retry, alternate source, human escalation, or stop.
• Action permission: read, draft, recommend, or change external state.
• Evidence record: source identifiers, tool calls, versions, checks, and reviewer disposition.

Build the checkpoint graph

Represent the workflow as nodes and guarded edges rather than a single prompt. Put a checkpoint before any irreversible, external, or high-consequence step. Define which checks can be automated and which require domain judgment.

Useful checkpoint types include source-presence checks, schema validation, duplicate detection, arithmetic reproduction, claim-to-source matching, policy rules, red-team probes, reviewer approval, and action confirmation. Keep the verifier independent enough to catch the producer's likely failure. Repeating the same model and prompt style is weak evidence of an independent check.

Worked artifact: a synthetic supplier-risk briefing

A fictional operations team builds a workflow to produce a weekly supplier-risk briefing. Stage one retrieves delivery and incident records. Stage two normalizes supplier identifiers. Stage three calculates exception rates. Stage four drafts a narrative. Stage five sends the briefing.

The first run merges two suppliers with similar names, treats missing deliveries as zero, and then generates a confident recommendation to pause orders.

| Stage | Contract and checkpoint | | --- | --- | | Retrieval | Require named systems, extraction times, and missing-source flags | | Normalization | Preserve supplier ID; reject name-only joins and unresolved aliases | | Calculation | Distinguish missing from zero; reproduce rates from retained rows | | Drafting | Link each material claim to a calculation and source record | | Review | Operations owner resolves identity conflicts and challenges recommendation | | Action | No automatic order change; authorized procurement roles decide separately |

The repaired workflow stops at normalization when the identifier conflict appears. After correction, it produces an exception table and a draft briefing with visible gaps. It does not pause orders or contact suppliers. The example is synthetic and is not procurement or operational advice.

Test propagation and recovery

Test the complete chain with safe historical, synthetic, or approved non-sensitive cases. Inject a stale source, duplicate record, unit mismatch, unavailable tool, malicious document instruction, unsupported claim, reviewer timeout, and failed external action. Observe where the error is detected and whether the workflow stops safely.

The NIST AI RMF Core calls for documenting intended scope, human oversight, deployment-relevant evaluation, monitoring, risk response, and the ability to disengage systems that do not match intended use. The framework is voluntary and under revision. Apply its questions to the workflow context rather than claiming compliance from a checklist.

Retain rejected outputs and recovery paths. A workflow that succeeds only when every dependency works has not demonstrated failure handling. Measure detection location, unsupported-claim count, reviewer corrections, safe stops, and unresolved errors that reached the final artifact.

Sources: [2]

Control external actions separately

Give each tool the least permission needed for its stage. Separate read credentials from write credentials. Require explicit confirmation and an accountable person before sending, publishing, purchasing, deleting, or updating a production record. Where an action is reversible, record the reversal path and test it.

Reopen the design after model, prompt, tool, source, permission, schema, policy, or reviewer changes. Version the stage contracts and tests together so a passing result can be tied to the workflow actually deployed.

Assess workflow-design judgment

A controlled assessment can provide a business objective, source pack, available tools, a flawed workflow diagram, and a deadline. Observable evidence may include whether the participant separates stages, preserves invariants, chooses distinct checks, designs failure routes, limits permissions, and keeps action authority with the right person.

Report only the behavior and evidence observed in that scenario. A single exercise does not establish universal safety, engineering competence, mature benchmarks, or future performance. Two Prune provides assessment evidence and does not make employment decisions.