# Request for Proposal: [AI agent project name]

> Working requirements template. Adapt with procurement, legal, privacy, security and domain owners. This document is not legal advice or a security certification.

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:

```text
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.

## Primary references

- https://www.gov.uk/government/publications/guidelines-for-ai-procurement/guidelines-for-ai-procurement
- https://www.gsa.gov/artificial-intelligence/buy-ai
- https://www.gov.br/governodigital/pt-br/infraestrutura-nacional-de-dados/inteligencia-artificial-1/publicacoes/guia-unificado-de-inteligencia-artificial-para-o-setor-publico-1/guia-unificado-de-inteligencia-artificial-para-o-setor-publico
- https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- https://developers.openai.com/api/docs/guides/evaluation-best-practices
- https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

## Related resources

- https://www.juancarlo.com.br/en/blog/evaluate-ai-agent-development-company
- https://www.juancarlo.com.br/en/blog/measure-ai-automation-pilot
- https://www.juancarlo.com.br/en/tools/ai-agent-production-readiness-checklist
- https://www.juancarlo.com.br/en/ai-agent-development-services