Practical guide

Redesign an AI-assisted workflow around the handoff, not the prompt

Once a team has chosen a bounded AI use case, the harder question is where the work changes hands. A workflow redesign should describe the route from a permitted input to a reviewed output, including the points where a person can reject the draft, recover the original source and stop the process. It is not a list of model features or a promise that fewer steps means better work. The artifact.

By Two Prune

Once a team has chosen a bounded AI use case, the harder question is where the work changes hands. A workflow redesign should describe the route from a permitted input to a reviewed output, including the points where a person can reject the draft, recover the original source and stop the process. It is not a list of model features or a promise that fewer steps means better work. The artifact here is a handoff map: a before-and-after sequence, a named owner for each transition and a check that can be observed during a small trial.

Map the current handoffs before moving them

Follow one recent task from trigger to delivery. For each step, note who supplies the material, what format it arrives in, which version controls, who decides that a step is complete and where the next person can see the evidence. Mark rework loops as well as the forward path. A task may appear to involve a slow drafting step when the real delay is waiting for an approved source or an owner to resolve conflicting instructions. In that case a faster draft does not repair the workflow.

The UK Government's People Factor guide discusses embedding AI tools in real routines through user research, digital design and change management. NIST's AI RMF Map playbook describes documenting context, human roles and oversight practices. Neither source specifies this handoff-map format; it is a practical illustration for a knowledge-work team.

Sources: [1] [2]

Draw the proposed route with two deliberate gates

Imagine a fictional operations team preparing a monthly supplier-issue briefing. Today an analyst gathers approved issue notes, reconciles duplicate entries, drafts a summary, sends it to a procurement owner and then answers corrections by email. A proposed AI-assisted route uses the same approved notes to suggest a grouping and a first-pass outline. The analyst still checks the grouping against issue IDs and writes the recommendation. The procurement owner still decides whether the briefing fairly represents the supplier record before it is distributed.

The first gate is an input gate. A note enters the exercise only if its version and handling permission are known. A stale issue export is replaced before drafting; a confidential attachment with no approved handling route is excluded. The second gate is an evidence gate. Every summary claim needs a link back to an issue ID or an explicit label as an interpretation. If the AI proposes “supplier delays doubled,” the analyst must reproduce the count from the approved register and define the comparison period. If that is not possible, the claim is removed rather than softened into vague language.

The handoff map can fit on one page. For this fictional task its rows read: source owner releases versioned notes; analyst confirms permission and issue IDs; AI proposes groups and outline; analyst reconciles groups and counts; procurement owner accepts or returns the briefing; the delivered copy retains the source version and correction log. Put a “return to source owner” arrow on the first row and a “return to analyst” arrow on the review row. Those reverse arrows are part of the design, not an exception to hide.

Test the changed route against a specific failure

Use a synthetic pack with one duplicate issue, one similarly worded but separate issue and one outdated status note. Ask a worker to produce the briefing using the proposed route. Observe whether they keep the two separate issues distinct, reject the stale note and can show how the final recommendation traces to the approved pack. Compare the route to the old process on evidence retention, review burden and correction path; do not infer productivity from a single exercise. If the worker cannot recover the source behind a statement, redesign the handoff before widening use.

The NIST AI RMF Core treats risk management as iterative across govern, map, measure and manage functions and calls for defined human-AI roles. That framing supports a repeatable check after a workflow change; it does not certify this example. A local operational owner must decide whether the new route is usable, while data and security owners decide whether real materials and tools are allowed.

Sources: [3]

Know when not to redesign

Do not add an AI step simply because the task has a document-shaped output. If inputs are unstable, ownership is disputed or the final decision cannot be checked, the immediate repair may be a source register, a clearer approval rule or a simpler non-AI template. Keep the old route available during a limited trial and record what would trigger rollback. Workflow redesign is distinct from use-case discovery: the use case has already been selected, and the decision now concerns the sequence of responsibility and evidence transfer.

This is an educational example, not evidence of a customer deployment or measured improvement. Two Prune can use a synthetic simulation to observe whether a participant preserves sources, checks AI output and communicates a correction; its assessment report provides bounded evidence for human interpretation, not approval of a live workflow or an automated employment decision.

Sources

  1. 1.UK Government's People Factor guide · UK Government
  2. 2.NIST's AI RMF Map playbook · National Institute of Standards and Technology
  3. 3.NIST AI RMF Core · National Institute of Standards and Technology