How to write an RFP for agentic AI without buying a promise

An RFP for agentic AI can easily become a contest in adjectives. Suppliers promise “autonomous,” “enterprise-grade,” “secure” and “model-agnostic” systems, each using different demonstrations and metrics. The buyer receives compelling documents that cannot be compared.

The remedy is to procure a bounded operating capability. Describe the workflow, users, data, actions and consequences. State what evidence will decide acceptance. Invite suppliers to explain how they will meet that contract, including where their design requires a change to the buyer’s assumptions.

Open with the decision and workflow boundary

Name the decision the procurement will support: for example, select a provider to implement a recommendation-only maintenance-planning agent for two facilities, with any work order still approved by an authorised employee. Identify what is inside and outside the first phase.

Give suppliers enough context to propose responsibly:

• current workflow, volume range and pain points;
• user roles and affected groups;
• systems and data classes involved;
• actions the agent may recommend, initiate or never take;
• material failure consequences;
• deployment, residency and integration constraints;
• expected human decisions and service ownership.

UK AI procurement guidance recommends beginning with the problem rather than forcing a problem into an AI solution. Explicitly allow a supplier to propose a simpler automation or narrower agent if it better meets the need.

Replace capability claims with response templates

For each requirement, ask for the same response fields. This makes gaps and assumptions visible.

Field	Supplier response
Approach	How the proposed system meets the requirement
Evidence	Test, reference architecture, document or observed demonstration
Dependency	Buyer data, integration, role or third party required
Boundary	Known condition where the approach does not apply
Verification	How the buyer can test it before acceptance
Operation	Who monitors, changes and restores it

Avoid “describe your AI capabilities.” Ask “show how an unauthorised request to create a work order is prevented, recorded and surfaced to an operator.” The second question invites comparable evidence.

GAO’s AI accountability framework groups practices under governance, data, performance and monitoring. Those make a useful completeness check for the RFP, but translate them into the actual workflow instead of asking suppliers to declare general alignment.

Include a buyer-controlled evaluation section

Tell bidders that shortlisted systems will be tested on representative scenarios. Describe scenario classes, measures and evidence access without disclosing every holdout case.

The evaluation section should specify:

1. Outcome: the business state that must be correct.
2. Authority: actions and data use that must remain within role and policy.
3. Reliability: repeated and varied execution, including tail behaviour.
4. Recovery: response to timeouts, partial completion and dependency failure.
5. Human work: review, correction, escalation and handoff quality.
6. Observability: evidence needed to reproduce and investigate a run.
7. Economics: complete cost for an accepted outcome, not a single model call.

The NIST AI RMF stresses documented test sets, metrics, uncertainty, deployment-relevant conditions and production monitoring. Require configuration and dependency versions with results. A score without its conditions should not earn evaluation credit.

Define critical failures separately from aggregate quality. A supplier should not offset one prohibited financial action with ninety-nine well-written summaries.

Procure the operating model

Agents change because models, prompts, tools, data and policies change. Ask who owns each kind of change and what happens before it reaches production.

Require proposed arrangements for:

• release and rollback;
• material-change notification;
• reevaluation triggers;
• identity, secrets and permission management;
• logging, retention and access to evidence;
• incident triage and customer communication;
• service continuity and dependency failure;
• model or tool substitution;
• user support and operator training;
• performance and cost review.

Do not accept “human in the loop” as an operating model. Ask where the decision appears, what evidence the person receives, how much time they have, what happens if nobody responds, and how overrides are recorded.

Expose commercial comparability

Request a pricing workbook built around scenarios rather than a headline token rate. Provide volume bands and ask bidders to identify every billed unit, minimum, included allowance and likely variable.

Include implementation, environments, storage, integrations, model inference, tools, support, observability, evaluation, training, security review, premium features and exit assistance. Ask for a worked monthly example using the same assumptions. Require treatment of failed runs, retries and duplicated work.

The UK Digital, Data and Technology Playbook emphasises interoperability, standards and avoiding lock-in in technology procurement. Translate that aim into priced obligations: export formats, API limits, documentation, transition support and the right to retrieve buyer-owned configurations and evidence.

Make exit and change first-class requirements

Specify what must be returned in usable form: buyer data, workflow configuration, policies, prompts where contractually available, evaluation cases, results, logs, documentation and integration schemas. Ask for deletion evidence where applicable and a transition plan that preserves service and audit needs.

Require bidders to identify proprietary dependencies and the effort to replace them. Proprietary technology can be the best choice; undisclosed dependence cannot be evaluated. Include a small portability exercise in selection or early delivery, such as exporting a case pack and reproducing a result outside the user interface.

Also ask how supplier-initiated changes are governed. A model replacement, feature retirement or telemetry change may alter an accepted workflow. Define notice, testing access, rollback and commercial remedies proportionate to that consequence.

Score evidence and delivery conditions separately

Publish the scoring logic. A practical structure might be:

Area	What earns credit	What does not
Workflow outcome	Observed performance on buyer cases	Generic benchmark alone
Control	Enforced, testable boundaries	Policy statement without mechanism
Evidence	Exportable traces and reproducible results	Dashboard screenshot
Delivery	Named method, dependencies and transfer	Unqualified rapid-deployment promise
Economics	Complete scenario cost and sensitivities	Discounted unit price alone
Exit	Exercisable export and transition path	“Data belongs to customer” alone

Keep mandatory gates distinct from weighted preferences. Data-handling, critical authority and required interface conditions may be pass/fail. Among bidders that clear those gates, use weighted evidence for quality, operations, value and delivery fit.

Do not award points twice for the same polished demonstration. Separate written evidence review, scenario evaluation, architecture discussion, commercial analysis and reference checks.

Contract for staged acceptance

AI development is iterative, so the RFP should not pretend every implementation detail is knowable. It should make learning governable. GAO’s Agile Assessment Guide describes incremental development with continuous evaluation of functionality, quality and customer satisfaction. Use milestones that produce working evidence: discovery acceptance, controlled-environment acceptance, limited operational acceptance and broader authority.

For each stage, define deliverables, cases, thresholds, buyer dependencies, evidence, remediation and stop rights. Payment milestones can follow accepted outcomes or artefacts rather than activity alone, subject to appropriate commercial and legal design.

An RFP cannot eliminate uncertainty from an agentic system. It can prevent uncertainty from being hidden inside broad claims. The winning proposal should not be the one that promises the most autonomy. It should be the one that shows, under comparable conditions, how a bounded workflow will work, be controlled, be evidenced and remain changeable after the contract is signed.