Bring one awkward, representative case to an AI agent vendor demo and have the vendor run it from trigger to verified business outcome. Ask how the system selects evidence, uses tools, limits authority and handles failure. Then inspect the human intervention and full cost behind the accepted result.
A polished happy path proves that the sales team rehearsed. Procurement needs evidence that the proposed system can operate inside your workflow without shifting hidden labour, access risk and recovery cost onto your team. These seven questions turn the meeting into a practical evaluation.
1. Which decision in this workflow requires an agent?
Ask the vendor to mark the exact point where model judgement changes the route. Every surrounding step should have a clear execution mode: deterministic rule, retrieval, model decision, human approval or recorded action.
This prevents “agentic” from becoming a label applied to an ordinary integration. OpenAI’s practical guide to building agents recommends agents for complex decisions, difficult-to-maintain rules and work dominated by unstructured data. A stable sequence of validation, calculation and system updates carries less variance when implemented as conventional automation.
Use a real case to test the boundary. If the proposal handles inbound sales enquiries, supply one enquiry with ambiguous requirements and another with complete structured data. The vendor should explain the interpretation required by the first and the cheaper fixed path available to the second.
The recent Model Operator comparison of AI agents and workflow automation provides a six-part test for path variability, input structure, acceptance, consequence, latency and economics.
2. What evidence does the agent use, and what happens when sources disagree?
Request the source packet behind one decision. It should show which documents, records or messages were retrieved, their versions, the user’s access rights and the precedence rule applied when two sources conflict.
An answer with citations still fails operationally when the cited policy expired last month or the CRM record has lower authority than an approved contract. The vendor needs a mechanism for freshness, source ownership and conflict escalation. Otherwise, your operators will reconstruct context during review, adding labour after the apparent automation gain.
Microsoft’s agent architecture checklist asks teams to define processing flows, data retrieval, inputs, outputs, user feedback and accountability before detailed design. Use those categories during the demo: identify where data enters, how it moves and which source can authorise the resulting action.
For knowledge-heavy workflows, this question also reveals whether the product requires an organised source layer or expects a connector to resolve contradictory company context by itself.
3. Whose identity does the agent use, and where does its authority stop?
Have the vendor list every read tool, write tool and external action available in the demonstrated workflow. For each one, ask which identity performs the action, how access is granted, whether permission expires and which actions require fresh approval.
Delegated authority creates a different risk from a chatbot response. A system that drafts a CRM update can remain inside a review queue. One that changes the opportunity stage, emails a buyer or applies a discount alters commercial state.
Microsoft’s June 2026 guidance on governing and securing AI agents recommends a distinct identity, named owner, inventory record, access controls and continuous monitoring for each agent. During procurement, ask the vendor to demonstrate those controls across the whole lifecycle with product evidence and configuration records.
The identity record should also make retirement testable. The Model Operator guide to AI agent identity lifecycle covers sponsorship, access expiry and verified decommissioning in more detail.
4. Show us the failure path, including partial action
Interrupt the demonstration after the agent has taken one external action but before the workflow finishes. Ask what the system records, what it retries and how it prevents duplicate execution.
Partial action is where a persuasive demo becomes an operating liability. A timed-out API response leaves the destination state unknown. Retrying a payment, message or CRM update without an operation ID can create a second live consequence. Calling the run “failed” also leaves the operator with no account of what already changed.
A credible response gives terminal states business meaning and makes repeat attempts idempotent. It also names the stop control, incident owner and reconciliation path. The vendor should identify which actions can be reversed automatically, which need a person and which leave a permanent consequence.
Stage a failure and inspect the evidence. The trace should connect each attempted action to the resulting system state and recovery decision.
5. How do you prove success outside the agent’s own response?
Choose the operating system that defines completion: a reservation database, CRM, ERP, repository, support platform or another authoritative destination. Then ask the vendor to verify the outcome there.
Anthropic’s agent evaluation guidance separates the transcript from the outcome. An agent can report that a booking succeeded while no reservation exists in the database. The same distinction applies to business workflows: a generated proposal, drafted resolution or submitted tool call remains intermediate work until the target state and owner accept it.
Require an acceptance record for the case. Capture whether the output was accepted unchanged, corrected, returned for material rework or rejected. Add active review time and the correction reason. This exposes hidden labour that completion rates omit.
For a paid proof of concept, agree the acceptance rubric and evidence source before the vendor configures the system. The AI agent pilot success criteria guide sets out the wider quality, safety, adoption and commercial gates.
6. Which evaluations run before release and after production changes?
Ask to see the evaluation suite behind the accuracy figure. A useful suite contains representative tasks, expensive edge cases, multiple trials for variable outputs and graders matched to the work.
Code-based checks can verify tool parameters and final system state. Model graders can assess open-ended quality against a rubric, although domain experts still need to calibrate judgement where customer, financial or policy consequences resist mechanical scoring.
Anthropic distinguishes capability evaluations from regression evaluations. The first tests whether the agent can handle harder work; the second protects behaviours that already passed. That distinction matters during procurement because a vendor can improve one headline capability while a model, prompt or tool change degrades an established workflow.
Request the latest regression result, the release threshold and one example where a failed evaluation blocked deployment. Then ask how a production failure becomes a future test case. That record says far more about the vendor’s engineering discipline than a benchmark collected on prompts they selected.
7. What is the full cost per accepted outcome?
Request an itemised estimate for the case shown: platform licence, model usage, tool calls, integration, evaluation, monitoring, active review, exception handling and recovery. Divide that total by accepted outcomes; initiated runs include work the business rejected.
Variable model spend is only one part of the operating cost. A low token bill can sit beside expensive human reconstruction, vendor services and integration maintenance. Conversely, a higher-cost model can be economically stronger when it reduces material corrections enough to protect throughput or margin.
The cost model should state expected case volume, complexity segments, review rate and failure assumptions. Ask how pricing changes when the workflow uses more turns, larger context, premium models or external tools. Preserve those assumptions in the proposal so later economics can be compared with the demo claim.
The Model Operator guide to AI agent unit economics gives the run-level ledger for joining execution spend, human effort, recovery and realised business outcomes.
Leave the demo with an evidence pack
Close the meeting by requesting one compact record:
| Evidence | Procurement question it answers |
|---|---|
| Workflow map and judgement boundary | Does this use case justify an agent? |
| Source packet and conflict rule | Can the decision be reconstructed? |
| Tool and permission matrix | What can the system read and change? |
| Failed-run trace and recovery record | What happens after partial action? |
| Outcome plus reviewer decision | Did the workflow produce accepted value? |
| Evaluation summary and release gate | Will changes be tested before exposure? |
| Cost assumptions per accepted outcome | Does the operating model clear the commercial threshold? |
Microsoft’s checklist also includes acquisition, governance, user experience and ROI in the architecture discussion. Those concerns belong in the buying process because procurement commits the organisation to the full operating model around an endpoint.
Use the evidence pack to decide whether to reject the proposal, narrow the scope or move into a bounded proof of concept. If the vendor cannot demonstrate one representative case with attributable evidence, limited authority and recoverable failure, broader autonomy will amplify uncertainty already visible in the room.
Model Operator helps leadership teams define the workflow, source authority, acceptance evidence and operating boundary before an agent build or vendor commitment. For a hands-on review through AI Initiative Consulting or an Agentic Company Brain build, start a conversation or email alexander@modeloperator.io.