Design the human–AI workflow

By the end of this lesson

• Assign the steps of a service task to people, rules, retrieval, the model and tools.
• Describe the interface and next action for a prepared draft, a confirmed failure and an unknown outcome.
• Check whether reviewers have information, skills, time, authority and a workable takeover route.

Before you begin

• Bring your problem statement, success criteria and stop conditions from Lesson 4. If you have no notes, start with checking service information and preparing a parts-request draft.
• Read the Beichen case: 48 field engineers and six remote experts. The initial assistant provides advice and drafts, without submitting requests or stopping equipment. The organization, events and data are synthetic learning material.

Read the Beichen case and introductory data

Start with how the user completes the task

Lesson 4 established the problem. This lesson turns it into a way of working that someone can actually use. The engineer needs to complete a service task, not receive another fluent answer. Write down the trigger, required inputs, permitted actions and official completion record before deciding where AI belongs.

For a parts draft, the engineer opens the job, checks the equipment and site information, consults the applicable manual, reviews the suggestion, edits or rejects it, and passes a checked draft into the existing approval process. A draft does not mean that parts have been ordered. At each transition, tell the user what remains and who handles it.

Draw four rows: what the field engineer sees and does; what the system reads and produces; how business and operations owners handle exceptions; and how the equipment customer can correct information or ask for a human explanation. The last row matters because affected people may never log into the assistant.

Choose the simplest approach that fits each step

Rules fit explicit checks, such as required fields or permitted quantities. Retrieval helps find material. A model can turn varied input into advice or a draft. An agent that calls tools can affect external systems, so action authorization, execution limits and final-state verification need separate design.

These approaches can work together. Filtering current material for a user and then asking a model to summarize it does not establish that the material is true, complete or applicable to the equipment. Retrieval-augmented generation, or RAG, supplies retrieved material to the model. Access, version validity and content quality still need their own controls.

Anthropic distinguishes predefined workflows from agents that select their own steps. Use that distinction to compare approaches, without treating greater autonomy as the goal. More calls add waiting time, expense and failure paths. Add flexibility only when the task needs it and testing supports the choice.

Walk a parts draft through the whole workflow

Use a paper example without involving real equipment. Suppose an engineer thinks two P-20 parts might be needed. These parameters illustrate the workflow; they are not a diagnosis. Keep a suggested need separate from a confirmed requirement before anything enters a purchasing record.

Use two sheets: one for the assistant interface and one for the business system’s record. Write the state on both after each step. This makes a mismatch visible—for example, the interface claiming completion while the record contains only a draft—without connecting a real service.

Follow the steps below. Whenever an input, permission or person is missing, describe how work continues safely. Replace “contact an administrator” with an owner, a way to verify the state, and a next action if nobody responds.

• Confirm identity and scope: the engineer may read authorized regional data, and this task only prepares a draft.
• Check equipment and sources: the manual must apply to the equipment model and use a valid version. Withdrawn material or missing information needs human investigation.
• Show the draft: display the part, quantity, evidence and unresolved fields, with options to edit or reject.
• Prepare the record: when the tool returns prepared_not_submitted, show “Draft prepared; not submitted” and retain the request identifier.
• Handle the next step: the engineer uses the existing process to reach an authorized approver. The assistant must not claim to have completed that process.

After a timeout, verify the state before retrying

A timeout means that the response did not arrive in time. It does not prove that nothing happened. In the lab fault, the draft record is saved before its response is lost, producing unknown_requires_reconcile. The accurate message is “Outcome unknown; verification needed,” not “Failed—apply again” or “Submitted.”

Idempotency means that repeating a request for the same operation does not add another equivalent business effect. The reference implementation stores an idempotency key: the same key and parameters return the existing result; a changed quantity with the same key is rejected. Verify the real service’s contract and behavior. Creating an identifier in the interface alone is insufficient.

Retain the original request identifier and key, pause duplicate actions, query the authoritative business record, compare parameters and state, and then decide what happens next. A future proposal to submit real requests requires fresh authorization and reconciliation tests. A draft exercise cannot establish reliable purchasing submission.

A confirmed failure also needs evidence. A different lab fault occurs before saving and returns not_submitted: the system can establish that no draft was created. Display “Draft not created.” Only consider retrying under the service contract after confirming that no record was created and that inputs and authorization remain valid. An unexplained timeout cannot establish this state. Display the reason, whether a record exists and the next action together, rather than just a red “Failed.” Tell users whether to supply missing inputs, request access, wait for recovery or ask an owner to verify the state. Repeated clicking should not be their way of investigating.

Make human review capable of changing the outcome

A confirmation click does not establish effective control. Reviewers need sources and missing information, relevant task knowledge, enough time for independent judgment, and the power to make rejection stick. Rejection also needs a workable next step, such as the original process or human takeover. Otherwise people may approve simply to avoid blocking work.

Calculate capacity before promising coverage. For illustration, 30 drafts per shift at four minutes each require 120 minutes of review. If only 60 minutes are available, the plan cannot claim adequate review of every draft. These numbers are assumptions. A real pilot needs observed timings, variation and other duties, with an operations owner confirming the arrangement.

Microsoft’s guidance draws attention to understanding and overreliance. For Beichen, test showing source and equipment details beside the advice, asking for an initial human judgment on consequential tasks, and using incorrect examples in a separate training environment. Each design needs evaluation. Opening a source does not prove comprehension or replace specialist judgment.

Design failure, unavailability and human takeover

Unavailable material and an unavailable model are different problems. Material may be inaccessible, outdated or outside coverage. A user-facing message can say “No current, usable information is available to you” without revealing hidden documents. Authorized support staff still need to distinguish the causes to decide whether to change access, update knowledge or add content.

If retrieval succeeded but the model failed before generating advice or calling any tool, show the valid, authorized source. Display “No advice was generated and no tool action was taken” only after checking the execution record. If a tool might already have been called, retain the unknown outcome and verify it. If the material itself is unavailable, do not fill the gap with an earlier answer. Recovery also does not mean earlier tasks are complete. Operations must reconcile queued drafts, unconfirmed requests and work still being handled manually.

Specify the actual overnight arrangement: who is on duty, how to reach them, how work proceeds while waiting and which capabilities pause if nobody responds. Users need ways to correct information, reject advice and return to the original process. Equipment customers need a channel for correction and human explanation. Context engineering offers technical reference; for this exercise, condensed records must retain sources, versions, authorization and unfinished states.

Check whether the design changes more than the wording

A footer saying “for reference only” changes little if the default button accepts advice automatically. “A human is responsible” is incomplete without time and authority. Improving answers does not fix withdrawn material entering the input. Change defaults, scope or controls; wording can help explain those choices but cannot implement them.

Do not send every task to the six experts. They also have regular duties, so headcount is not review capacity. Distinguish work the field engineer can handle from work requiring a qualified specialist. Tasks without a workable takeover arrangement stay in the original process or outside the pilot.

Finish by explaining the workflow in an engineer’s terms: when to use it, when not to use it, what remains after “Draft prepared,” and what to avoid and where to check after “Outcome unknown.” Ask a partner to follow the instructions. Working alone, read them once as the user and once as the operations owner, looking for anything that requires guessing.

Practice the method

Check your understanding

Write your answer before opening the explanation, then check what you might have missed.

Your record and next step

A human–AI workflow with handling for success, failure and unknown outcomes, plus a staffed takeover plan.

Turn the remaining guesses into assumptions: whether material is usable, users will verify it and overnight support is available. Lesson 6 uses this list to choose the first small test.