Do Not Buy an AI Agent Until It Passes This Evidence Contract

Most AI-agent comparisons begin with products. Teams list vendors, watch demonstrations, count connectors, compare model names, and ask which agent is “best.” That sequence is backwards.

An agent is useful only inside a specific business episode. It receives evidence, interprets it, proposes or performs an action, writes to a system, and hands unresolved cases to a person. The same product can be valuable in one episode and dangerous in another. A polished demonstration cannot establish that it will work with your customers, vocabulary, permissions, missing data, and failure recovery.

The source guide, Choosing an AI agent for your SME’s line of business, makes the right starting point explicit: choose from the process, data, action, and human takeover—not from a category label. This article turns that principle into a procurement artifact: an evidence contract.

An evidence contract specifies what a vendor must demonstrate before a pilot, what the pilot must prove before production, what the system must record while operating, and what conditions trigger a pause or exit. It is not a promise that the agent will never fail. It is a testable agreement about scope, proof, authority, recovery, and accountability.

The decision in one page

Do not approve an AI agent because it can produce the happy-path output. Approve only a bounded use case when all eight conditions are true:

1. The unit of work has a defined trigger, result, owner, and deadline.
2. Inputs and systems of record are named and accessible under least privilege.
3. The agent can abstain when evidence is missing, contradictory, or outside scope.
4. High-impact actions require independent policy checks and meaningful approval.
5. Every write returns a durable receipt and supports reconciliation.
6. Evaluation uses representative local cases, not vendor-selected examples.
7. Ongoing review, maintenance, incident response, and exit work have owners.
8. The business case remains positive after review, correction, and operating cost.

If any condition is missing, use the system in read-only or draft mode while collecting evidence. “Start small” is useful only when small also means low-impact, observable, and reversible. The U.S. Small Business Administration’s AI guidance for small businesses similarly recommends testing whether tools add value and having people review AI outputs; its advice is general and U.S.-focused, so a European or Swiss company must separately map its own legal obligations.

Define the business episode before the product

“Sales agent,” “finance agent,” and “support agent” are marketing categories. A business episode is precise:

When an inbound distributor request arrives, match it to an existing account, extract product and delivery constraints, identify missing fields, prepare a CRM draft, and route pricing questions to the account owner within 30 minutes.

That sentence establishes a trigger, evidence, operations, output, human owner, and service level. It also exposes several distinct risks: incorrect identity matching, invented constraints, duplicate records, unauthorized pricing, and delayed escalation.

Write the episode as a table before contacting vendors:

Element	Required description	Evidence
Trigger	Event that starts the work	Logged message or system event
Eligible cases	What the agent may handle	Taxonomy and examples
Excluded cases	What always goes to a person	Policy and risk review
Inputs	Data the agent may read	Source inventory and permissions
Output	Exact artifact or action	Schema and acceptance criteria
Authority	Maximum effect it may create	Tool and approval matrix
Owner	Person accountable for outcome	Named role, not “AI team”
Deadline	Required service level	Current baseline
Recovery	Route for uncertainty and failure	Runbook and tested queue

Avoid compound episodes. “Find leads, enrich them, score them, email them, book meetings, and update the CRM” contains multiple decisions with different evidence and consequences. Test each transition separately.

Map evidence before features

For every output field, ask where the supporting fact comes from and how fresh it must be. A model’s fluent answer is not evidence.

Create four labels:

• observed: directly present in an authorized source;
• derived: calculated deterministically from observed values;
• inferred: model interpretation with uncertainty;
• approved: confirmed by an accountable person or policy service.

An agent may infer that a message concerns a renewal. It should not silently store that inference as an approved commercial stage. An agent may derive a due date from an approved contract rule. It should not invent a rule when the contract is missing.

Require citations at field level for material claims. “Source: knowledge base” is insufficient. The reviewer needs document, version, section, and retrieval time. When sources conflict, the system should show the conflict and stop rather than selecting the most convenient passage.

Knowledge quality is a business responsibility. The vendor operates retrieval technology; it does not know that yesterday’s policy superseded a PDF still present in a shared drive. Name a content owner, define update and retirement procedures, and test whether removed content disappears from answers.

Set the authority ceiling

Agent risk grows with three variables: functionality, permission, and autonomy. The ceiling must be enforced outside the prompt.

Use an authority ladder:

Level	Agent behavior	Production example
0 — Observe	Read bounded data	Summarize a ticket
1 — Propose	Draft an artifact	Prepare a reply or CRM update
2 — Prepare	Create a reversible pending action	Hold a slot or stage a record
3 — Execute bounded	Commit low-impact cases	Send an approved template
4 — Execute material	Affect money, rights, access, or obligations	Payment, contract, deletion

Most SME pilots should begin at levels 0 or 1. Level 2 requires receipts, expiry, and reversal. Level 3 requires stable eligibility rules and monitoring. Level 4 should remain under meaningful human approval unless a rigorous domain-specific control case supports otherwise.

Do not grant a generic integration identity broad access because configuration is easier. Give each tool the minimum operations, records, and amounts required. Separate draft_invoice, approve_invoice, and send_invoice. Server-side services validate the user, case state, amount, and policy every time.

Turn demonstrations into adversarial trials

A vendor demonstration answers one question: can the vendor show the system working on a prepared path? Procurement needs a different answer: how does the system behave when the path breaks?

Provide your own sanitized cases. Include:

• a normal complete request;
• a request missing one decisive field;
• two records with similar identities;
• conflicting values in two authorized sources;
• an unsupported language or intent;
• an attachment containing irrelevant instructions;
• an API timeout after a possible write;
• a policy that changed recently;
• a request outside the customer’s permissions;
• a high-impact case that must be escalated.

Score behavior, not eloquence. A correct abstention can be more valuable than an attractive answer. An agent that admits uncertainty and routes the case is safer than one that always completes the workflow.

Require the vendor to show logs and receipts during the test. If the team cannot explain which source, model, prompt, tool, identity, and policy version produced the result, it cannot investigate production failures.

The evidence contract

The contract should be short enough to use and detailed enough to reject unsupported claims.

Scope evidence

• one named business episode;
• eligible and excluded case definitions;
• supported languages, channels, and regions;
• explicit non-goals;
• authority level for each transition.

Data evidence

• data-flow map from collection through deletion;
• authoritative sources and update owners;
• subprocessors and processing locations;
• training and retention settings;
• export, correction, and deletion procedures.

Performance evidence

• evaluation set provenance and sample composition;
• results by intent, language, impact, and exception class;
• false acceptance and false escalation rates;
• human edit and override rates;
• latency and availability under realistic load.

Control evidence

• permission matrix and service identities;
• deterministic policy checks;
• approval interface for high-impact actions;
• immutable action receipts;
• idempotency and reconciliation behavior;
• rate limits, kill switches, and rollback.

Operating evidence

• exception queue owner and capacity;
• incident classification and notification;
• change log for models, prompts, tools, and sources;
• regression test process;
• support response and recovery objectives;
• exit plan and usable data export.

The contract should identify who produces each proof and who accepts it. “Available on request” is not proof. Ask to see the artifact before production approval.

Architecture for a controlled pilot

flowchart TD
    A[Business event] --> B[Identity and schema validation]
    B -->|Invalid| X[Exception queue]
    B -->|Valid| C[Retrieve authorized evidence]
    C --> D[Agent proposes interpretation]
    D --> E{Evidence complete and consistent?}
    E -->|No| X
    E -->|Yes| F[Deterministic policy service]
    F --> G{Authority level}
    G -->|Observe or propose| H[Human review]
    G -->|Bounded action| I[Prepare action]
    G -->|Material action| H
    H -->|Approve| I
    H -->|Reject or edit| J[Record correction]
    I --> K[Scoped tool execution]
    K --> L{Receipt confirmed?}
    L -->|No| M[Reconciliation queue]
    L -->|Yes| N[Commit outcome]
    X --> O[Resolve and label]
    M --> O
    J --> P[Evaluation log]
    N --> P
    O --> P
    P --> Q[Review metrics and changes]

The agent interprets; the policy service authorizes. The tool executes; the receipt proves. The queue handles uncertainty; the evaluation log improves the system.

Build a representative evaluation set

Do not evaluate only common, clean cases. Sample across time periods, customers, employees, languages, channels, document formats, and impact levels. Keep a separate challenge set for rare but consequential failures.

The Census Bureau’s 2026 analysis of its Business Trends and Outlook Survey found that U.S. business AI use varied materially by firm size and sector (Census analysis). Those figures do not predict the outcome of a specific SME pilot, and U.S. businesses are not a proxy for every market. They illustrate the denominator problem: adoption and capability differ across populations, so vendor averages cannot replace local evidence.

Split the set into development and holdout portions. Vendors may iterate on development cases. Preserve holdout cases for the acceptance decision. After launch, add production failures to regression tests without deleting older challenges.

Report confidence intervals or at least raw counts when samples are small. “100% accurate” on ten cases is not production evidence. Record the number of eligible, excluded, ambiguous, and high-impact cases separately.

Metrics that determine the decision

One accuracy score hides the failures that matter.

Quality

• eligible cases correctly accepted;
• excluded cases correctly rejected;
• required fields extracted with source evidence;
• unsupported claims per case;
• human approval without edits;
• downstream corrections after approval.

Safety and control

• high-impact actions attempted without approval;
• permission denials;
• unknown tool outcomes;
• duplicate writes;
• conflicts detected and surfaced;
• time to disable one intent or tool.

Operations

• handling time from trigger to business outcome;
• review minutes per case;
• exception queue age;
• repeat work and handoffs;
• service-level breaches;
• maintenance hours by owner.

Economics

• avoided manual cost;
• software and inference cost;
• review and correction cost;
• incident and rework loss;
• ongoing content and integration maintenance;
• net value per completed outcome.

Do not treat time saved as revenue automatically. The organization must be able to redeploy capacity. The benefit may instead be faster response, lower backlog, better evidence, or less interruption. Name the actual outcome.

Executable acceptance gate

Save this example as agent-gate.mjs. Replace thresholds with risk-based values approved for the episode.

export function acceptAgent(metrics, thresholds) {
  const checks = {
    eligibleAccuracy:
      metrics.eligibleCorrect / metrics.eligibleTotal >= thresholds.eligibleAccuracy,
    unsafeAcceptance:
      metrics.unsafeAccepted / metrics.highImpactTotal <= thresholds.unsafeAcceptance,
    evidenceCoverage:
      metrics.sourcedFields / metrics.materialFields >= thresholds.evidenceCoverage,
    reviewCost:
      metrics.reviewMinutesPerCase <= thresholds.maxReviewMinutes,
    unknownWrites:
      metrics.unknownWrites <= thresholds.maxUnknownWrites,
    netValue:
      metrics.netValuePerCase >= thresholds.minNetValue,
  };

  const failed = Object.entries(checks)
    .filter(([, passed]) => !passed)
    .map(([name]) => name);

  return { approved: failed.length === 0, checks, failed };
}

const result = acceptAgent({
  eligibleCorrect: 188,
  eligibleTotal: 200,
  unsafeAccepted: 0,
  highImpactTotal: 24,
  sourcedFields: 940,
  materialFields: 1000,
  reviewMinutesPerCase: 2.4,
  unknownWrites: 0,
  netValuePerCase: 3.8,
}, {
  eligibleAccuracy: 0.92,
  unsafeAcceptance: 0,
  evidenceCoverage: 0.90,
  maxReviewMinutes: 3,
  maxUnknownWrites: 0,
  minNetValue: 2,
});

console.log(JSON.stringify(result, null, 2));

The numbers are illustrative, not benchmarks. High-impact workflows may require zero unsafe acceptance while tolerating more escalation. A low-impact drafting task may accept more errors if review is fast and mandatory.

Price the full operating model

The purchase price is only one cost. Include implementation, source cleanup, permissions, evaluation, user training, exception handling, monitoring, vendor support, incident response, model changes, connector changes, and exit.

Use this formula:

net value per case
= avoided handling and delay cost
- execution cost
- expected review cost
- expected correction and rework
- risk-weighted incident loss
- allocated maintenance and change cost

Run pessimistic scenarios. Double the exception rate. Remove one reviewer. Assume a connector outage during peak volume. Increase the percentage of cases that require manual verification. If value disappears under plausible conditions, restrict the scope or stay in assist mode.

EY’s discussion of an agentic workforce architecture argues that scaling requires governance and operating-model change, not technology alone. It describes EY’s enterprise context, not evidence that a small company should copy its architecture. The transferable point is organizational: agents create new ownership, supervision, and coordination work that must be designed and funded.

Contract for change, not only launch

Agent behavior can change when the provider updates a model, prompt, retrieval pipeline, safety layer, or connector. Require notification and regression testing for material changes.

Record:

• model and version;
• system instructions and policy version;
• retrieval index version;
• tool schema and permissions;
• evaluation suite version;
• release date and approver;
• rollback target.

A vendor should not be able to change the execution path without leaving evidence. Define which changes require re-acceptance and which can follow a lighter review.

Monitor source freshness. A correct answer from an obsolete policy is still wrong. Set review dates and automatic warnings for expired material. Make source removal testable.

Design human review that works

“Human in the loop” is not a control when the reviewer sees only a polished answer and clicks approve under time pressure.

Show:

• original request;
• material source excerpts;
• fields inferred rather than observed;
• missing or conflicting evidence;
• proposed changes compared with current state;
• financial, legal, or customer impact;
• available alternatives;
• clear approve, edit, reject, and escalate actions.

Measure reviewer disagreement and automation bias. Insert known challenge cases periodically. If reviewers approve incorrect outputs because the interface hides uncertainty, improve the review design rather than blaming individual users.

Give operators a fast way to label the reason for correction. Free-text feedback alone is difficult to analyze. Use a taxonomy such as wrong identity, missing evidence, stale source, unsupported intent, policy conflict, tool error, poor wording, or routing mistake.

Run a recovery and exit exercise before acceptance

Procurement teams often review what happens when the agent works and postpone what happens when it stops. That is risky because a production agent can become a hidden routing layer between customers, employees, and systems of record. When it fails, the business may discover that nobody knows which cases are pending, which actions completed, or how to continue manually.

Design a two-hour exercise with the vendor and process owner. Begin with ten open cases in different states: new, waiting for evidence, awaiting approval, prepared for execution, written successfully, and written with an unknown receipt. Then disable the model endpoint or connector without warning the operators.

The team must be able to answer:

• Which cases are safe to continue manually?
• Which cases may already have changed a downstream system?
• Where is the original customer evidence?
• Which proposed actions were never approved?
• Can pending jobs be exported with stable IDs and current state?
• Can the tool identity be revoked without blocking ordinary staff access?
• Can customer communication continue from an approved fallback channel?
• Who decides when the automated path may resume?

Do not accept a screenshot or vendor narrative as the result. Save the exported file, tool receipts, revocation log, queue snapshot, decisions, and elapsed times. Record where an operator needed vendor assistance. A recovery objective that depends on one external engineer being immediately available is a dependency, not an internal capability.

Next, simulate an ambiguous write. The tool request times out after attempting to create a CRM record. The correct result is not “retry.” The system should place the case in reconciliation, search the downstream system using the idempotency or request identifier, determine whether the record exists, and only then choose a follow-up action. Repeat the test for a message, calendar booking, and financial draft if those operations are in scope.

Test partial degradation as well. If retrieval is unavailable but the CRM works, the agent should not invent knowledge from memory. If the model works but the policy service is unavailable, material actions should stop. If the logging service fails, decide whether processing pauses or continues in a restricted mode. Document those choices; otherwise the software will make them implicitly.

The exit half of the exercise assumes the contract ends next week. Export business records, configurations, prompt and policy versions, evaluation cases, corrections, action logs, and unresolved incidents. Verify the files can be opened without the vendor’s application and that identifiers preserve relationships. A large archive is not portable when essential fields are proprietary or undocumented.

Build a revocation sequence:

1. stop new intake into the agent;
2. freeze or reconcile pending writes;
3. export state and audit evidence;
4. redirect customers and employees to the fallback route;
5. revoke API tokens, OAuth grants, service accounts, and webhooks;
6. confirm deletion or contractual retention at the vendor and subprocessors;
7. validate that systems of record remain complete;
8. close the change with named approval.

Time each step. A reversible pilot should be removable without reconstructing the business process from chat transcripts. If the vendor cannot demonstrate export, revocation, and deletion before receiving production data, the exit risk is already known.

Finally, convert every exercise failure into an acceptance item. Missing request IDs require a schema change. Unclear queue ownership requires an operating decision. A token that cannot be revoked independently requires an integration redesign. Recovery testing is not an appendix to procurement; it is evidence that the proposed autonomy remains under the company’s control.

Failure modes to test

The category label hides a different workflow

Two “sales agents” perform incompatible jobs. Compare the exact episode, inputs, outputs, and authority—not the label.

The vendor demo uses perfect data

Production records contain duplicates and missing fields. Test sanitized real cases before approving integrations.

The agent always answers

It cannot recognize unsupported cases. Require abstention and measure false acceptance.

A timeout creates a duplicate action

The system retries without reconciling. Require idempotency keys, receipts, and lookup by request ID.

A document changes the agent’s instructions

Retrieved content contains malicious or irrelevant commands. Treat content as data and enforce policy outside the model.

Permissions exceed the business need

A read-and-draft agent can delete or export records. Remove unused tools and scopes at the identity layer.

Human approval becomes ceremonial

Reviewers lack evidence or face excessive volume. Improve the interface, narrow eligibility, and set capacity limits.

The business case ignores supervision

Saved minutes are offset by review and maintenance. Recalculate using observed operating costs.

Vendor lock-in appears after launch

Prompts, logs, records, and evaluation data cannot be exported. Test exit before production.

A model update invalidates evidence

Performance changes silently. Pin versions where possible and rerun acceptance tests for material releases.

Procurement checklist

• [ ] One business episode is named and bounded.
• [ ] Eligible and excluded cases are documented.
• [ ] Every material field has an evidence source.
• [ ] Observed, inferred, derived, and approved values are distinct.
• [ ] Authority is capped per tool and transition.
• [ ] High-impact actions require meaningful approval.
• [ ] Vendor tests use representative customer-provided cases.
• [ ] Holdout cases remain unseen until acceptance.
• [ ] Results are segmented by intent, language, and impact.
• [ ] False acceptance and false escalation are reported separately.
• [ ] Every write has an idempotency key and receipt.
• [ ] Unknown outcomes enter reconciliation rather than retry.
• [ ] Logs identify source, model, policy, tool, and actor.
• [ ] Data flows, subprocessors, locations, and retention are documented.
• [ ] Training on company or customer data is controlled contractually.
• [ ] Exception queues have owners and capacity limits.
• [ ] Maintenance and incident response are funded.
• [ ] Material changes trigger regression testing.
• [ ] One intent or tool can be disabled independently.
• [ ] Export and exit have been tested.

Monthly evidence review

Review both successes and failures. If the team looks only at escalations, it cannot detect unsupported cases that the agent wrongly accepted. Sample accepted cases, corrected cases, high-impact decisions, and actions with unusual latency.

For every recurring exception, decide whether to repair data, clarify policy, improve deterministic validation, change the interface, narrow scope, retrain users, or stop the feature. Adding prompt text is not a universal remedy.

Recalculate economics from observed review time and correction cost. Compare outcomes against the manual baseline, including manual errors. Do not demand perfection from automation while pretending people never fail; do not excuse scalable new failures because people also make mistakes.

Pause the affected transition when a material action lacks a receipt, a high-impact case bypasses approval, the exception queue exceeds capacity, source freshness cannot be established, permissions drift, or the evaluation suite no longer represents production.

The final rule

The best AI agent is not the one with the longest feature list. It is the one that can prove useful performance inside your bounded episode, with evidence your team can inspect, authority your systems can enforce, and failure paths your operators can recover.

Buy the proof before buying autonomy. Begin with observation and proposals. Expand only after representative tests, stable controls, and positive unit economics. Keep every expansion reversible.

An evidence contract turns vendor enthusiasm into a decision process. It gives procurement a standard, operators a recovery path, leadership an honest business case, and customers protection from experiments disguised as production.

Start with one week of baseline observation before the vendor test. Count volume, handling time, corrections, exceptions, and service failures in the current process. Without that baseline, a faster demonstration can look successful while merely shifting work to another person. Compare completed business outcomes, not generated drafts, and preserve the baseline definition throughout the pilot so the final decision remains auditable.