Who this is for: Operations teams introducing AI into a repeatable business process.
AI automation uses a model for a step that needs interpretation, such as extracting information from a document or categorizing a request. The surrounding workflow still needs explicit rules, permissions, and an owner.
An extraction step is not automatically an autonomous agent. Keep the system's freedom proportional to the job, and decide how you'll detect a plausible wrong answer before it can change a customer record.
Choose how much judgment the system needs
Use deterministic rules when the input and decision can be specified reliably. A required field being empty doesn't need a language model. Use a bounded AI step for interpretation, with a fixed output structure and explicit checks.
An agent can select tools or steps. That can be useful for a variable task, but it adds paths you must evaluate. Start with a fixed workflow if it can do the job. More freedom creates more cases to test.
| Approach | Example | Control |
|---|---|---|
| Rule | Route a known territory code | Approved lookup and fallback |
| Bounded AI step | Extract a contract start date | Source evidence, validation, review |
| Agent | Investigate a request across allowed tools | Tool permissions, budget, stop condition, approval |
Separate valid structure from correct meaning
Suppose a synthetic contract says, “Service begins October 1, 2026. Invoices are due 30 days after issue.” A useful extraction returns start_date 2026-10-01 and payment_terms_days 30, with the supporting text. It must not turn the invoice terms into the service start date.
Check three things separately: did execution finish, does the output match the schema, and does it represent the document correctly? A valid date is not necessarily the right date. Deterministic workflows can make silent business errors too; AI changes the error patterns, not the need for reconciliation.
- Step 1
Read
Use the approved document input.
- Step 2
Extract
Return defined fields and source evidence.
- Step 3
Validate
Check types, allowed values, and missing fields.
- Step 4
Review
Hold ambiguity and consequential changes for a person.
- Step 5
Write
Save approved values with a source reference.
Create examples that can falsify the design
Build an evaluation set with normal inputs, missing information, contradictions, unusual formatting, and instructions embedded inside the source document. Treat those embedded instructions as data. They must not change the workflow's rules or tool permissions.
Write expected outcomes before running the model. Include “send for review” and “no write” as correct outcomes. A model that guesses a value for every field can appear productive while producing expensive cleanup.
Make review a real operating step
Give the reviewer the source excerpt, proposed values, validation failures, and the action they are approving. Assign an owner and a due time. If the review queue has no capacity, the workflow has no reliable fallback.
Don't treat a model's self-reported confidence as a calibrated probability. Check its relationship to errors on your own examples. For consequential actions, require explicit approval even when the model sounds certain.
Record model and prompt versions, tool configuration, evaluation results, and changes to the output schema. Rerun the evaluation after a change. Estimate operating cost from measured calls, retries, and review minutes; token cost alone can miss the largest expense.
- The source input cannot expand tool permissions.
- Missing or ambiguous information has a safe outcome.
- A person can inspect evidence before approving a write.
- Known failures appear in the evaluation set.
- Model, prompt, and schema changes trigger retesting.
Free download · No email required
AI workflow design checklist
Describe one bounded use case. Keep the allowed actions narrower than the model's general capabilities. Use the evaluation pack before launch.
Open the CSV in Excel, Google Sheets, or another spreadsheet tool. The Markdown brief is editable in a text editor.
Common questions
- Can we remove human review after a good test run?
- Only after deciding which error types the process can tolerate and verifying performance on representative inputs. A small clean test set is weak evidence for rare, consequential failures.
- Does valid JSON mean the answer is safe to use?
- No. JSON can be structurally valid and contain the wrong customer, date, or amount. Validate business meaning and supporting evidence before acting.
