How do you move an AI prototype into a real business workflow?

1. Define the finished job

Sit with the person who handles these requests today. Follow one ordinary request from arrival to completion, then one that needed help. Record the systems they open, the checks they make, and the decisions they cannot make alone.

Write a short workflow contract: what starts the work, which inputs are required, what counts as complete, and where unresolved items go. For our example, completion means a reviewer has accepted or corrected a draft and the case record reflects that decision. Generating text alone does not complete the job.

Separate fixed rules from interpretation. Matching a known customer identifier can use explicit rules. Interpreting an ambiguous request may need a model. Anthropic's workflow guidance recommends beginning with the simplest approach that meets the task and adding complexity only when it helps.

Deliverable: a one-page workflow map with its start, end, owner, excluded actions, and exception route.

2. Record the baseline before changing the work

Choose a representative sample of recent requests. Include routine cases, incomplete messages, and requests that crossed team boundaries. Record active handling time separately from time spent waiting in a queue.

Track how often someone corrects a response or reopens a case. Note what makes the cases different, such as language or request type, so the pilot is not compared with an easier workload.

Agree what improvement would justify continuing. A team might prioritise shorter turnaround with no increase in material corrections. Another might need less staff effort per completed case. Choose the actual thresholds with the process owner before results arrive; there is no universal percentage that makes every workflow worthwhile.

Deliverable: a baseline sheet, a definition for each measure, and written continue, revise, and stop criteria.

3. Connect one narrow path end to end

Build a small working path through the actual systems: receive a request, retrieve the permitted context, prepare a draft, and place it in the review queue. Keep external actions behind the agreed approval boundary.

Define the data exchanged at every step. A case identifier, source message, draft version, review decision, and processing status make it possible to reconstruct what happened. Retain only the information needed for the job and limit who can access it.

Missing customer context should produce an exception, not an invented answer. A reviewer should see the original request and the evidence supporting the draft alongside the proposed response.

Make retries explicit when recording a case. Use a stable operation identifier and the destination's duplicate-prevention support. If a write times out, check whether it succeeded before repeating it. The AWS guide to idempotent APIs explains why repeated requests need to preserve the same intended operation.

Deliverable: one traceable path through the connected systems, including a failed lookup and an uncertain write.

4. Test with an answer key

For each evaluation case, write down the expected behaviour. Some cases should produce a draft. Others should request more information or stop for specialist review. Correctly declining to proceed can be a successful result.

Include missing attachments, conflicting customer details, duplicate messages, unavailable integrations, and instructions embedded in incoming text that try to change the workflow. Check both the response and the resulting system state.

Use exact checks for required fields, record counts, and prohibited actions. Have the process owner assess matters such as whether a draft answers the request accurately. Keep a separate set of cases for evaluation so success does not merely reflect repeated tuning on the same examples.

Anthropic's evaluation guide describes repeatable tasks and different grading methods. For this workflow, the practical aim is to catch regressions whenever the prompt, model, or integration changes.

Deliverable: a repeatable evaluation set, recorded failures, and evidence that the agreed release criteria are met.

5. Run a controlled pilot

Begin in shadow mode: process copies of permitted requests without sending messages or changing live customer records. Compare the proposed outcomes with the team's actual decisions. This reveals gaps, but it does not yet prove that people will save time using the tool.

Next, let a small group use the review queue for a limited category of live work. Set a volume limit, an end date, and a person who can pause it. Keep the manual route available and make sure every request has one clear processing owner.

Measure all the work that remains: reading drafts, checking evidence, correcting mistakes, handling exceptions, and administering the system. Include model usage, software, and maintenance costs when assessing value.

Deliverable: a pilot review that recommends expansion, another iteration, or stopping, with the measured reasons.

Frequently asked questions