How to Write an RFP for AI Agent Implementation Services

An RFP for AI implementation services should describe one specific role for the agent, then require every provider to answer in the same written format on four topics: ownership, operations, security and support. Feature lists and demo scripts say little about who will run the system next year. Ask for commitments you can test and artifacts you can read, and the proposals become comparable.

Key takeaways

• Define one role and one observable success criterion before writing a single question. A vague scope gets vague proposals.
• Fix the response format. Every provider answers the same numbered questions, so you can compare line by line.
• Make ownership, operations, security and support separate mandatory sections, not marketing appendices.
• Ask for artifacts, not claims: a sample permission list, a sample recurring report, an exit summary.
• Prefer a bounded first engagement over a long commitment, and treat any unanswered mandatory question as a gap.

Why do generic AI RFPs produce answers you cannot compare?

Most RFP templates come from software procurement. They ask for feature lists, supported models, certifications and references. Those questions fit a product you configure yourself. They fit poorly when you are buying an agent that holds memory, signs in to your systems and takes actions on your behalf.

The result is predictable. Three providers describe their approach as secure, flexible and fully supported, and you cannot tell which one will leave you with usable documentation if the relationship ends. The fix is not a longer questionnaire. It is a shorter one that forces specifics: who holds which asset, who performs which recurring task, which permissions the agent has, and what happens when something breaks.

One caution before you start. An RFP is a good tool when you know what you need and want to compare providers fairly. If you are still deciding whether the work belongs in a tool, a team or a partner, settle that first. Otherwise the RFP will try to answer a strategy question it was not built for.

What should the RFP document contain, and in what order?

Keep the document short enough that a busy provider reads all of it. A workable outline looks like this:

• Company context: what the business does, which teams are involved, which channels people use (email, chat, WhatsApp, phone) and which systems hold the relevant information.
• The role: one job for the agent, written like a job description, with inputs, outputs and an explicit list of what is out of scope.
• Success criterion: something observable, such as a defined set of tasks completed correctly under review, not a general statement about efficiency.
• Constraints: data sensitivity, languages, regions, regulatory obligations and the points where a human must approve an action.
• Response format: numbered questions, a required order, a deadline and a named contact on your side.
• Ownership questions.
• Operations questions.
• Security questions.
• Support questions.
• Commercial structure and exit terms, described in words, with no need to quote figures at this stage.

The role section deserves the most care, because every other answer depends on it. A provider cannot describe a permission model for a role that does not exist. If you have not yet written one, a job description for your first AI agent role is a good starting point, and most of it can be pasted into the RFP.

Give providers something to react to. Include two or three real tasks the agent would handle, written with the messy details your team sees: an incomplete request, a forwarded thread, a document in the wrong format. Proposals that engage with those details are written by people who read the brief.

Which ownership questions should every provider answer?

Ownership is where proposals diverge most and where problems surface late. Providers rarely hide the answers, but they rarely volunteer them either. Put these questions in the RFP as mandatory items:

• Who owns the prompts, instructions and task definitions, and in what readable format are they delivered to you?
• Who owns the agent's memory and knowledge base, including anything it accumulated during operation?
• Who owns logs, evaluation results and incident records?
• Which accounts, domains and integrations are registered in your company's name, and which in the provider's?
• Which components are proprietary to the provider, and what license do you hold to use them?
• Which model providers and subprocessors will touch your data, and can you be notified when they change?
• On termination, what is exported, in what format, and within what period?

Ask each provider to attach a one-page exit summary: what you would walk away with, what stays behind, and what it would take to move the work elsewhere. That single page reveals more about lock-in than any architecture diagram. Two companion reads cover the detail: who owns your AI prompts, memory and data and the broader guidance on avoiding vendor lock-in with business agents.

Also ask whether the agent runs under its own identity and accounts or borrows an employee's login. An agent that acts through a person's credentials is hard to audit and hard to revoke. Providers should state this plainly.

How do you make providers describe operations and support?

Implementation is the shorter part of the relationship. Most of the value, and most of the risk, sits in what happens after launch. Models change, integrations break, documents go stale and your business changes. The RFP should make providers say who does that work.

For operations, require answers on:

• What is monitored, how often it is reviewed and by whom.
• How the agent is evaluated on real tasks over time, and how you see the results.
• Who maintains integrations when a connected system changes.
• How changes reach the live agent: is there a test environment, an approval step and a way to roll back?
• How permissions are reviewed, and how often.
• What a recurring report contains. Ask for a sample, with company details removed.

For support, require answers on:

• How you report a problem, and who answers.
• How severity is defined, and what response is described in writing for each level.
• What is explicitly excluded from support.
• What happens when an upstream model provider or connected service fails.
• How incidents are communicated afterward: cause, impact, corrective action.
• Which languages and time zones the support team works in.

Be wary of two things. First, support promises that are broad but undefined. Second, service targets that the provider cannot control, such as the availability of a third-party model. Good proposals separate what they commit to from what they depend on. A fuller treatment of what to put in writing is in what to define in an AI agent SLA, and what not to.

An illustrative scenario: a distribution company asks providers what happens if the agent starts sending incorrect order confirmations on a Friday afternoon. One proposal answers that support is comprehensive and available when needed. Another says that the sending permission can be suspended by the company's own administrator at once, that the provider will review logs and report on cause within a stated working window, and that corrections are tested in a separate environment before returning to live use. Only the second answer describes something you could hold anyone to.

What should the security section ask for?

Security answers are easy to inflate. Avoid asking whether the provider is secure. Ask what the agent can do, with which credentials, and what stops it from doing more.

• Request a permission list for your specific role: every system the agent reads from, drafts in or sends through, with the smallest access that works. Least privilege for AI agents explains why starting small matters.
• Ask which actions require human approval, and how that approval is recorded.
• Ask how untrusted content, such as inbound emails, web pages and attachments, is prevented from issuing instructions to the agent. This is the prompt injection question, and a credible answer describes design choices, not reassurance.
• Ask how credentials and secrets are stored, rotated and revoked.
• Ask what is logged, who can read the logs, and how long data is retained.
• Ask where data is processed and stored, and how deletion requests are handled.
• Ask how the provider handles a suspected security incident, including how and when you are told.

You can also ask providers to map their answers to a recognized reference, so you are not grading on their vocabulary. The OWASP Top 10 for LLM Applications covers common failure modes in language model systems. The OWASP Authorization Cheat Sheet is a practical baseline for access decisions. The NIST AI Risk Management Framework gives a structure for governance conversations. You do not need the provider to hold any particular certificate. You need them to show they have thought about each area and can describe their controls in plain language.

If your team has no security reviewer, ask a trusted adviser to read only this section of the responses. It is the section where specialist eyes help the most.

How do you score the responses and choose?

Scoring is simpler when the questions are fixed. Use this sequence:

• First, remove any response that skips a mandatory section or answers with a link to a general brochure.
• Second, score each answer on three things: is it specific, is there an artifact behind it, and can you test it?
• Third, give ownership, operations, security and support equal standing in your discussion. A strong demo should not outweigh a weak exit plan.
• Fourth, invite the finalists to a working session on your own role, using your own sample tasks. Watch how they ask questions, not how they present.
• Fifth, ask for a bounded first engagement with a defined role, defined approval boundaries and a success criterion you can observe, before any wider commitment.

Keep a short written record of why you chose the winner. It helps later if the scope changes, and it helps your team understand the decision. For the wider selection picture, see how to choose an AI implementation partner.

How does a managed approach answer these sections? Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. The agent keeps its identity, memory, channels, tools and permissions under human control, and managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. Service is remote, in English and Portuguese. If you send Be Human an RFP written this way, those are the sections it would be expected to answer in writing.

Frequently asked questions

How long should an RFP for AI implementation services be? Long enough to define the role and the four mandatory sections, and short enough that a provider can answer thoroughly. A focused document with numbered questions usually serves better than a long questionnaire, because it gets specific answers instead of copied boilerplate.

How many providers should receive the RFP? A small handful is enough. Every additional response costs you reading and scoring time, and the quality of comparison drops when you cannot discuss each proposal properly. Choose providers whose work resembles your situation and who are willing to answer the ownership and exit questions directly.

Can we write an RFP if we have not decided on the role yet? You can, but the responses will be generic. It is better to spend a short period choosing one role, its inputs, its outputs and its limits first, then write the RFP around it. If you cannot yet name the role, a discovery conversation with one or two providers may be more useful than a formal process.

Should the RFP ask about commercial terms? Yes, but ask about structure, not figures, at the first stage. Ask what is included in the initial engagement, what recurs, how changes to scope are handled, and what the exit terms are. Once you understand the structure, you can compare proposals on the same basis and discuss the numbers with the finalists.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.