An AI workflow can produce a convincing demonstration while leaving the hardest purchasing questions unanswered. Who can approve a proposed action? What happens when the source material is incomplete? What evidence will show that the delivered system meets your requirements?
Use this guide when commissioning AI agents and business assistants. It focuses on approval design and acceptance criteria, so you can compare proposals against the same operational brief.
1. Describe one decision and its consequences
Start with a specific job, such as preparing a response to a support request or suggesting a change to an internal record. Name the input, the permitted output, the system receiving that output and the person accountable for mistakes.
Separate reading information, recommending an action and executing it. A first release might read approved documents and prepare a draft, while a named employee retains responsibility for sending it. Decide explicitly whether later releases may act without review, and under which limits.
2. Make approval a visible product feature
Ask the supplier to show exactly what the reviewer sees: the proposed action, affected record, recipient, source evidence and any unresolved uncertainty. Approval should apply to that specific proposal. If the destination or content changes materially, define when fresh approval is required.
OpenAI’s guardrails and human-review documentation describes pausing tool execution for approval and placing validation at the tool boundary. In your brief, request a demonstration that rejection prevents the action, including after a restart or delayed review.
- Gather permitted evidenceRead the approved request and relevant records.
- Prepare a proposalShow the intended change, source and missing information.
- Check the boundaryValidate the destination, fields and user permissions.
- Request human approvalApprove the specific change, or reject and stop.
- Execute and verifyCheck the receiving system and record the actual outcome.
This is a proposed design for discussion, not a client implementation or performance claim.
3. Specify data access before model choice
List the documents, applications and fields the workflow needs. Identify confidential information that must stay out of prompts or logs, and agree who can inspect stored requests, outputs and approval records. Ask which providers receive the data and what retention settings apply to the selected services.
A document or customer message may contain instructions that conflict with your workflow. Include examples that try to redirect the assistant, request unrelated data or change the destination. The acceptance test should verify the approved boundary still holds.
4. Test meaning as well as format
A response can use the correct fields and still contain the wrong facts. OpenAI’s Structured Outputs documentation explicitly notes that structured outputs can contain mistakes. Ask for checks on source accuracy, required information and allowed actions alongside format validation.
Build a small, representative test set with your operational team. Include straightforward requests, ambiguous wording, missing documents, contradictory records and unsupported questions. Write the expected behaviour before reviewing the generated answer. Sometimes the right result is a clear request for more information.
Agree how errors will be graded. A stylistic correction and an unauthorised record change should not carry the same weight. Set thresholds that fit your workflow rather than accepting an unexplained overall accuracy percentage.
5. Include failure and recovery in acceptance
Ask what happens if an integration times out after accepting an update, the reviewer goes offline or a record changes while approval is pending. Define how the operator checks the current state before retrying, and how repeated execution is prevented where possible.
Request visible statuses for waiting, rejected, attempted, confirmed and unresolved work. Keep an exception queue with an owner. Agree how to pause automated execution while leaving approved read-only or manual processes available.
Buyer’s acceptance checklist
- One bounded workflow, named owner and documented exclusions
- Approved data sources, access roles and retention decisions
- Review screens showing the exact proposed action and evidence
- Tests for rejection, changed proposals and expired approvals
- A representative test set with agreed pass and failure criteria
- Recovery checks for timeouts, repeated requests and changed records
- Logs, operating instructions, maintenance ownership and provider costs
Agree what happens after delivery
Models, prompts and connected systems can change. OpenAI’s evaluation guidance recommends evaluating changes and expanding test coverage over time. Decide who reruns your acceptance set, who approves releases and how the previous working configuration can be restored.
Bring sample inputs, your current approval process and the actions you want the system to support. Discuss an AI workflow brief with Offchain to define the first release and its acceptance evidence.