AI Agent RFP Template

A useful AI agent request for proposal makes suppliers answer the same business question under the same assumptions. It specifies the work, the authority being granted, the evidence required and the responsibilities that continue after delivery. A long list of model names or fashionable features does little to make prices comparable.

The adaptable RFP below uses an illustrative work-order coordination assistant. It helps a service coordinator interpret incoming requests, identify missing information and prepare a correctly routed work order. It does not authorise hazardous work, dispatch a team without the required approval or certify completion. Replace this example with your own task and have the relevant procurement, legal, security and business owners review the resulting document.

Start with the outcome and disclose the uncertainty

Use a short opening statement such as: “We seek a system that reduces the effort needed to prepare eligible service requests for review while preserving correct site identification, service entitlement, required approvals and an auditable handoff.” This is an example clause to adapt, not a promise that a particular reduction is achievable.

Separate facts from assumptions. State which volumes are measured, which interfaces have been inspected and which data samples are available. Where access or process ownership is unresolved, ask suppliers to price a defined investigation and explain how its result changes the proposal. Do not invite a fixed implementation promise while concealing a dependency that determines feasibility.

The UK government's AI procurement guidance provides a useful methodological reference for problem definition and supplier evaluation. It is not a Saudi procurement rule. Your organisation's applicable purchasing procedures remain the authority for issuing and awarding the RFP.

Schedule A: business context and measurable boundaries

Complete these fields before issuing the request. A supplier should be able to identify the intended user, eligible workload and excluded actions without reconstructing your organisation from a sales meeting.

Business schedule to complete for your procurement

Field	Information to provide	Illustrative work-order entry
Business owner and users	Name the accountable role and working teams	Service operations owner; Arabic- and English-speaking coordinators
Trigger and eligible tasks	Define how work starts and which requests qualify	Incoming maintenance enquiry for an identified customer site
Baseline and volume	Provide measured handling time, case mix, peaks and measurement period	Buyer supplies observed figures; supplier must not assume every enquiry is eligible
Accepted outcome	Describe the business record and required evidence	Draft order with verified site, request category, missing-information status and routing
Excluded authority	List actions requiring another process or person	No work authorisation, unapproved dispatch, entitlement override or completion certification
Language and operating context	State actual inputs, outputs, service hours and accessibility needs	Arabic and English requests, mixed-language equipment identifiers and shift handoffs

Supply redacted examples with expected outcomes, including at least one ambiguity and one legitimate refusal or escalation. The project brief helps gather this context; the RFP adds the structured supplier response and award conditions.

Schedule B: data, integrations and authority

List each source and destination with its owner, access method, environment, relevant record types and current availability. Distinguish a documented API from a hoped-for integration. State whether the agent may read, prepare a proposed change or request a controlled write. Give suppliers a way to identify access they cannot verify before award.

Require a data-flow response covering model processing, retrieval indexes, application storage, operational logs, backups, support access and subprocessors. Ask for the proposed deployment locations and the evidence behind them. Use the PDPL workstream and residency assessment to define applicable requirements; “Saudi compliant” without identified controls and responsibilities is not a usable answer.

Include an adaptable authority clause: “The proposed design must enforce user and tool permissions outside model-generated instructions. An approved action must remain bound to the relevant record, proposed values and approval conditions. The supplier must describe rejection, expiry and recovery behaviour.” Ask the supplier to identify how this will be implemented and demonstrated, rather than accepting the clause as evidence that it already works.

Require one consistent response format

Assign a stable identifier to each requirement. Require an answer for every identifier, including unsupported requests. A capability marked “available” should identify the current product or implementation and evidence. “Configure” and “develop” should identify work, dependencies and price. This prevents a roadmap statement from silently becoming an included commitment.

Supplier response row and worked example

Response field	Example content
Requirement identifier	AUTH-04: prevent dispatch without a valid approval
Delivery status	Available, configure, develop or unsupported; select one and explain
Implementation and evidence	Name the permission check, approval binding and proposed rejection test
Dependency and owner	Buyer provides dispatch API contract; supplier implements the controlled gateway
Commercial treatment	Included line item, separately priced work or explicit exclusion
Qualification	Identify assumptions, limitations and the decision needed to resolve them

Allow alternatives in a separate section so useful ideas remain visible without making the baseline proposals incomparable. Ask an alternative to explain the changed outcome, risk, cost and dependency. A simpler deterministic step may be a better answer to a requirement than an additional agent.

Schedule C: delivery stages and acceptance evidence

Request a plan organised around evidence-bearing stages: feasibility and access confirmation, a bounded working flow, evaluation, controlled operational trial and handover. The supplier should propose durations with prerequisites and buyer effort. Do not let a headline timeline begin before essential access, source approval or reviewer availability exists.

For each stage, specify the deliverable, test environment, acceptance owner, evidence record and treatment of failed criteria. A failed gate may lead to a repair, narrower scope, further investigation or termination under agreed terms. Distinguish defect correction from a new requirement and require written approval for changes in cost or authority.

Set out a buyer-owned evaluation process before suppliers design their demonstrations. Require normal cases, uncertainty, unavailable dependencies and attempted unauthorised actions in the evidence. The detailed pre-purchase evaluation guide supplies a case-pack method; reference the method you adopt rather than copying a generic “high accuracy” target.

If payment is linked to acceptance, define the evidence, review period, rejection reasons and dispute process in the contract. An RFP example is not a substitute for drafting enforceable commercial terms. Acceptance of a prototype should not silently count as acceptance of production operations.

Schedule D: operations, ownership and exit

Ask who handles incidents, source changes, connector failures, model changes and evaluation regressions. Require service hours, severity definitions, response commitments and exclusions to be explicit. A response commitment describes when support engages; it is not automatically a restoration guarantee.

Make the handover list inspectable: agreed source or configuration access, tool contracts, deployment instructions, evaluation cases and results, source-refresh procedures, operational runbook, access inventory and training. Distinguish buyer-owned material, supplier background intellectual property and third-party components. Ask which rights are granted and which licence obligations or account dependencies continue.

Require an exit plan stating which records, configurations and evidence can be exported, in what format, by whom and at what cost. Include credential revocation, access removal, transition support and data retention or deletion responsibilities. Do not assume that an exported chat history is sufficient to operate or replace the system.

Schedule E: the commercial breakdown

Ask for separate figures for discovery, implementation, integration, evaluation, migration, training and initial handover. Then request recurring charges for infrastructure, model usage, software licences, support, maintenance and agreed change capacity. State the currency and whether amounts include applicable VAT, and require the quotation's validity and payment assumptions.

For usage charges, define the billable unit and treatment of retries, failed attempts, human handoffs and third-party calls. For buyer-operated accounts, identify who contracts with and pays each provider. Ask for at least a baseline workload and a clearly stated sensitivity scenario; neither should be presented as a guaranteed forecast.

Require a common evaluation horizon and assumptions so a low initial price does not hide operating work. The total cost of ownership framework helps compare the proposals. Keep optional enhancements separate from the price of satisfying mandatory requirements.

Score eligible proposals, then examine the evidence

Use mandatory gates for non-negotiable conditions such as supported authority boundaries, acceptable data processing, necessary access and required ownership terms. Decide how each gate is demonstrated and whether a gap is remediable. A strong weighted score must not cancel an unresolved mandatory failure.

For proposals that pass the gates, an illustrative weighting is task fit 30%, integration feasibility 20%, security and data-handling evidence 20%, operating model 15% and commercial assessment 15%, totalling 100%. Choose weights for your procurement. Publish scoring anchors that distinguish an unsupported assertion, a documented approach and an observed result.

Record evaluator reasoning and unresolved assumptions, not just a total. Issue material clarifications consistently to participating suppliers under your purchasing process. Before award, reconcile the selected response, exclusions, evidence plan and negotiated terms so the contract represents the decision you actually made.

To discuss a scoped Open for AI development proposal, bring the completed business schedule and your most consequential authority boundary. Share a redacted RFP or procurement brief so the next conversation can address feasibility, responsibilities and the evidence your buyers need.