AI Agent RFP Template: Copyable Requirements for a Custom Build

AI Agent RFP Template: Copyable Requirements for a Custom Build

An AI agent RFP should define the business job, evidence required, authority limits, data boundaries, pilot decision and response format without prescribing the vendor's entire technical solution. The goal is to receive proposals that can be compared against the same outcome and constraints.

This template is for a company sourcing custom AI agent development or a managed agent implementation. It is not legal advice, a security certification or a universal procurement policy. Procurement, legal, privacy and security owners should adapt it to the organization and applicable obligations.

Open the standalone Markdown template to copy it into your own workspace.

When should you use this RFP?

Use the full template when the agent will:

• connect to company systems or confidential data;
• read, write, send or change records;
• require a custom workflow or integration;
• affect customers, employees, money or production;
• need a measured pilot before broader authority;
• involve multiple vendors or a formal procurement process.

Use a lighter project brief when you are still testing whether the problem deserves a procurement process. If the job, owner and outcome are not defined, discovery should happen before the RFP.

What to prepare before sending it

Do not invent precision. Mark an answer as unknown, discovery required when the organization has not yet verified it. A visible uncertainty is more useful than a requirement based on a guess.

Copyable AI agent RFP template

Replace the bracketed fields and remove sections that do not apply.

# Request for Proposal: [AI agent project name]

RFP owner: [name and role]
Business owner: [name and role]
Technical owner: [name and role]
Security or privacy owner: [name and role]
Issue date: [date]
Questions due: [date]
Response due: [date]
Planned pilot decision: [date]
Response contact: [contact method]

## 1. Purpose and instructions

[Organization] is requesting proposals for a bounded AI agent system
that supports [named business workflow].

The response must:
1. answer every requirement in the supplied response matrix;
2. distinguish available capability, configuration, custom work and roadmap;
3. identify assumptions, exclusions, dependencies and buyer responsibilities;
4. provide evidence links or attachments where requested;
5. state where discovery is required before a responsible estimate;
6. disclose model, hosting and material third-party dependencies;
7. avoid presenting a prepared demo as production evidence.

Alternative non-agent solutions may be proposed when they meet the outcome
with less complexity or risk.

## 2. Business context and problem

Organization context:
[Relevant business, market, team and operating context]

Current workflow:
[Trigger, steps, people, systems, output and current completion state]

Problem to solve:
[Observed delay, cost, quality, risk, backlog or missed outcome]

Why an agent may fit:
[Where context or exceptions change the next action]

Current baseline:
- unit of work: [example: one reviewed support request]
- monthly volume: [value or unknown]
- median cycle time: [value or unknown]
- accepted quality measure: [value or unknown]
- exception or rework rate: [value or unknown]
- human effort per unit: [value or unknown]
- current direct cost: [value or unknown]

Target outcome:
[Measurable result without prescribing the implementation]

Out of scope:
[Processes, users, actions, systems and outcomes excluded]

## 3. Users, owners and workflow boundary

Primary users:
[Roles and relevant access]

Affected people:
[Customers, employees, partners or other groups]

Workflow start:
[Verified trigger and required input]

Successful terminal state:
[Observable completed outcome]

Exception state:
[What stops automation and who owns the case]

Required human decisions:
[Decisions that remain with named roles]

Operating owner after launch:
[Team or role]

## 4. Functional requirements

For every proposed capability, label the response:
- available now;
- available through configuration;
- requires custom work;
- not supported;
- discovery required.

Inputs:
[Messages, records, documents, events or approved sources]

Required outputs:
[Decision, draft, update, response, record or other artifact]

Knowledge sources:
[Approved repositories, policies, records and freshness rules]

Required tools and integrations:
[System, operation, read or write direction, environment and owner]

State and memory:
[What must persist, for how long and who may access it]

User experience:
[Channel, status, review, correction, escalation and completion receipt]

Accessibility and language:
[Applicable requirements]

Volume and performance:
[Expected volume, concurrency, latency needs and peak conditions]

## 5. Agent authority and prohibited actions

The response must list each proposed tool action with:
- action and target;
- execution identity;
- minimum permission;
- read, draft, write, send, delete or permission effect;
- value, volume, recipient or resource limit;
- approval requirement;
- reversibility and recovery path;
- audit evidence.

Allowed read actions:
[List]

Allowed draft actions:
[List]

Allowed bounded write actions:
[List with limits]

Actions requiring approval:
[List with approver role and exact payload shown]

Prohibited actions:
[List]

Default behavior when no policy matches:
[Recommended default: deny and record]

The agent must not expand its own permissions or treat silence as approval.

## 6. Data, privacy and security

Buyer data classes:
[Public, internal, confidential, personal, regulated or other]

The response must provide:
1. a data-flow diagram;
2. purpose and permitted use for each data class;
3. model, hosting, storage and material subprocessors;
4. processing and storage locations;
5. retention and deletion behavior;
6. whether buyer data is used for provider training;
7. encryption and secrets management;
8. identity, access and tenant separation;
9. logging content and access controls;
10. vulnerability and dependency management;
11. incident detection, notification and response responsibilities;
12. secure development and environment separation;
13. buyer and supplier shared-responsibility matrix.

Known buyer restrictions:
[Policies, regions, prohibited data, required reviews or standards]

Security evidence requested:
[Policies, architecture, testing summaries, attestations or other evidence]

## 7. Evaluation and acceptance

The pilot must be evaluated on a buyer-approved case set that includes:
- normal cases;
- edge cases;
- known historical failures;
- ambiguous inputs;
- untrusted or adversarial inputs where relevant;
- tool and dependency failures;
- cases that should abstain or escalate.

Evaluation unit:
[One completed business unit]

Representative case-set source:
[Sanitized historical cases, synthetic cases or controlled live sample]

Outcome metrics:
[Business result and acceptance definition]

Process metrics:
[Quality, completion, cycle time, human effort and cost]

Failure metrics:
[Detection, severity, impact, recovery and silent-failure rate]

Safety and authority metrics:
[Denied actions, approvals, overrides, incidents and policy violations]

Acceptance thresholds:
[Threshold by critical metric, not only one average]

Human reviewers:
[Roles, rubric and calibration process]

Reproducibility:
[Required version, configuration, logs and test artifacts]

Production evaluation:
[Continuous evaluation and review cadence after pilot]

## 8. Reliability, recovery and human handoff

The response must describe and demonstrate:
1. timeout before an external action;
2. timeout after an external system may have accepted an action;
3. duplicate request and idempotency behavior;
4. partial tool or integration failure;
5. invalid, missing or stale data;
6. unavailable model or provider;
7. missing approval or unavailable reviewer;
8. human handoff with context and acceptance;
9. rollback or compensation;
10. incident escalation and degraded user experience.

Recovery objectives:
[Applicable recovery expectations or discovery required]

Business continuity owner:
[Role]

## 9. Observability and operating model

Required trace:
input reference -> source evidence -> model decision -> tool proposal ->
policy decision -> human decision -> execution receipt -> verified outcome

Required operational signals:
- outcome and acceptance by workflow;
- model and tool version;
- latency and error by step;
- retries, timeouts and duplicate prevention;
- approval, rejection and expiry;
- human correction and exception effort;
- model, search, storage, integration and monitoring cost;
- cost per completed and accepted unit;
- incidents, rollback and unresolved states.

Operating responsibilities:
[Buyer, supplier and shared responsibilities]

Support and incident expectations:
[Coverage, channels, priority and response model]

Change management:
[How models, prompts, policies, tools and dependencies are tested and released]

## 10. Delivery approach and pilot

Proposed phases:
1. discovery and workflow confirmation;
2. data and integration assessment;
3. architecture and control design;
4. representative evaluation setup;
5. bounded implementation;
6. pilot with narrow authority;
7. decision and operating handover.

Required deliverables:
[Architecture, data map, source, configuration, eval set, reports,
runbooks, training, support plan and other artifacts]

Pilot scope:
[One workflow, user group, systems, volume and authority]

Pilot exclusions:
[Explicit exclusions]

Decision gates:
- expand when: [conditions]
- adjust when: [conditions]
- stop when: [conditions]

Supplier must identify assumptions that affect schedule or price.
Unverified dates must be presented as estimates with dependencies.

## 11. Ownership, portability and exit

The response must state ownership and license terms for:
- source code;
- infrastructure and configuration;
- prompts and policy artifacts;
- evaluation cases and results;
- buyer data and generated records;
- logs and operating history;
- custom integrations;
- third-party components.

The response must describe:
1. buyer control of production accounts and credentials;
2. export formats and tested export process;
3. model and provider replacement path;
4. dependency inventory and recurring fees;
5. documentation and knowledge transfer;
6. transition assistance;
7. deletion and access removal after exit.

Any requested contract terms must be reviewed by the buyer's procurement
and legal representatives.

## 12. Supplier team and evidence

Name the people accountable for:
- discovery and product decisions;
- architecture and engineering;
- evaluation;
- security and data;
- delivery;
- production operation and incidents.

For each relevant example, provide:
- comparable workflow and scope;
- supplier's actual role;
- evidence the reference can verify;
- permission to use the reference;
- limitations and differences from this project.

Do not include confidential client data or claims that cannot be verified.

## 13. Commercial response

Break out:
- discovery;
- implementation;
- integrations;
- data preparation;
- evaluation;
- security work;
- hosting and infrastructure;
- model and third-party usage;
- monitoring and support;
- training and handover;
- change requests;
- exit or transition support.

Provide:
- pricing basis and currency;
- assumptions and exclusions;
- one-time and recurring fees;
- usage drivers and example calculation at the supplied volume;
- buyer resources required;
- payment and acceptance milestones;
- proposal validity period.

Projected savings or return must be labeled as hypotheses until measured
against the buyer baseline.

## 14. Response matrix

Return one row per requirement:

Requirement ID:
Requirement:
Response status:
Proposed approach:
Available now or custom:
Evidence:
Assumptions:
Buyer dependency:
Delivery dependency:
One-time cost:
Recurring cost:
Risk or limitation:

## 15. Procurement process

Planned stages:
[Written response, clarification, evidence review, pilot, decision]

Evaluation criteria:
[Published dimensions and weights]

Clarification rules:
[How questions and shared answers will be handled]

Buyer reserves the right to:
- request evidence for any response;
- narrow or stop the process when a critical blocker remains;
- select a non-agent approach;
- run a bounded pilot before production authority;
- reject unverifiable claims.

How to evaluate the responses

Separate compliance from quality.

Use the buyer scorecard for AI agent development companies after receiving the proposals. Critical blockers should override a polished total score.

A fair procurement sequence

1. Run discovery until the business job and baseline are explicit.
2. Share the same RFP, clarification answers and sanitized evidence with every candidate.
3. Score written responses before presentations.
4. Verify documents, references and claimed capabilities.
5. Give finalists the same representative case set.
6. Run a bounded pilot with narrow credentials.
7. Measure outcomes using the AI automation pilot scorecard.
8. Review production controls with the AI agent readiness checklist.
9. Record expand, adjust, pause or stop conditions.

The UK government's AI procurement guidance recommends output-based requirements, data assessment, multidisciplinary evaluation, iterative delivery and lifecycle planning. These principles keep the RFP focused on the challenge while still demanding evidence.

Common RFP mistakes

• Asking for “an AI agent” without naming the business job.
• Prescribing a framework before suppliers understand the outcome.
• Giving different data or cases to different vendors.
• Scoring features without testing representative behavior.
• Defining one average accuracy target and ignoring severe failures.
• Saying “human in the loop” without approval and handoff rules.
• Omitting provider, retention and subprocessor questions.
• Treating a demo as acceptance.
• Comparing build price while hiding usage and operating effort.
• Leaving ownership and exit until contract negotiation.
• Requiring certainty where discovery is still needed.
• Publishing compliance claims without specialist review.

Frequently asked questions

What belongs in an AI agent RFP?

Include the business job, baseline, users, systems, data, authority, required evidence, evaluation cases, acceptance thresholds, reliability, operating model, ownership, commercial response and pilot decision. Keep the requirement outcome-based enough for suppliers to propose a simpler solution.

Should an AI agent RFP specify the model or framework?

Only when a verified constraint requires it. Otherwise specify the outcome, data, systems, controls and evidence. Ask the supplier to disclose its model and framework choices, dependencies, limitations and replacement path.

How long should an AI agent RFP be?

Long enough to make proposals comparable, but proportional to the project. A low-risk internal prototype may use a short brief. A system that reaches sensitive data or performs external actions needs more detailed security, evaluation and operating requirements.

Should the RFP include a budget?

Include a verified range or commercial constraint when the organization is prepared to disclose it. Also ask suppliers to separate discovery, build, integrations, usage, monitoring, support and transition so different cost models remain comparable.

Should suppliers build a proof of concept before selection?

Use a bounded, paid pilot when written evidence cannot prove performance on your workflow. Give finalists the same case set, systems boundary and outcome metrics. Do not grant broad production authority only to accelerate a procurement demo.

Is this template a contract?

No. It is a requirements and response template. Procurement, legal, privacy, security and relevant domain owners should convert accepted requirements into the appropriate agreement and controls.

Primary references

• UK Government guidelines for AI procurement
• GSA Buy AI
• Brazilian Government Unified AI Guide for the public sector
• NIST AI Risk Management Framework Core
• OpenAI evaluation best practices
• OWASP AI Agent Security Cheat Sheet

---

A useful RFP creates a shared definition of the job before anyone estimates the build. Scope the workflow, evidence and bounded pilot for custom AI agent development.