How to Write an AI Agent RFP (2027 Buyer's Guide)

Most companies buy an AI agent the way they bought software in 2015. They write a request for proposal full of feature checkboxes, send it to five vendors, and score the replies on who ticked the most boxes. Then they are surprised when the "agent" they bought turns out to be a chatbot with a confident tone, or a Zapier flow wearing a new coat of paint.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, mostly on unclear value, runaway cost, and weak controls. A lot of those cancellations are decided at the buying stage, long before anyone writes a line of code. The RFP either forced the vendor to prove the agent can do real work, or it let them talk around it.

A good AI agent RFP is not longer than a normal one. It asks different questions. A traditional software RFP buys fixed functionality: does the product do X, Y and Z. An agent RFP buys governed decision-making: can this system take a goal, work through several steps on its own, and do so safely enough that you would let it near a real customer or a real invoice. This guide is the structure we use with clients, and the questions that separate a real agent from a rebranded one.

The RFP is a filter, not paperwork

Think of the document as a sieve. Every question is there to let the serious vendors through and catch the ones who are guessing. The single most useful property of a good RFP is that it is annoying to answer dishonestly. A vendor who is "agent-washing," selling templated automation with agentic language, can wave past vague questions about capabilities and vision. They cannot wave past a request for a recorded run of their agent completing a multi-step task on messy data, with the failures left in.

So write the RFP to be hard to fake. Ask for evidence, not adjectives. Every time you are tempted to ask "does your platform support autonomous workflows," rewrite it as "show us a run where your agent completed a task of at least five steps without a human in the loop, and tell us what it did when a step failed."

Start with the outcome, not the feature list

Before any vendor section, the RFP should state what you are actually trying to achieve, in plain numbers. Not "improve customer service" but "resolve 40% of tier-one support tickets end to end, measured by tickets closed without a human touching them, within six months." The outcome is the thing you score against later, so it has to be concrete enough to measure.

This does two things. It stops vendors pitching you a generic platform and forces them to respond to your problem. And it gives you the yardstick for the pilot, so "success" is defined by you up front rather than negotiated afterwards by whoever is keenest to renew. If you cannot write the outcome as a number, you are not ready to buy yet, and that is worth knowing before you spend.

The sections an agent RFP actually needs

Beyond the usual company background and pricing, an AI agent RFP needs six sections that a normal software RFP skips.

• Autonomy and scope. What decisions does the agent make on its own, and where does it stop and ask a human? Make them draw the line explicitly. "It depends" is not an answer you can govern.
• Data access and boundaries. What systems does the agent need to read and write, with what permissions, and how are those permissions scoped so it cannot wander. An agent is only as safe as the smallest blast radius you can give it.
• Evaluation and accuracy. How do they measure whether the agent is doing the job correctly, and will they run their evals against your data before go-live. A vendor with no eval story is telling you they do not know when their own product is wrong.
• Failure and escalation. What happens when the agent is unsure, hits an error, or gets a request outside its scope. A good answer describes graceful handoff to a person; a bad one pretends it never happens. This is the human handoff question, and it separates production systems from demos.
• Observability and audit. Can you see what the agent did, step by step, after the fact, and can you explain a given decision to a customer or a regulator. If you cannot trace it, you cannot defend it.
• Cost model and ceilings. How is usage priced, how does cost scale with volume, and can you cap it. Token and per-action pricing can turn a cheap pilot into an expensive surprise at scale, so make them model it.

Questions that expose agent-washing

Drop these straight into the RFP. They are deliberately specific, because specificity is what agent-washing cannot survive.

1. "Walk us through one task your agent completed autonomously across at least five steps, including a run where something went wrong." A real agent has these recordings. A chatbot has a highlight reel of single answers.
2. "Where does your product make decisions versus follow pre-written rules?" If the honest answer is "it follows rules," you are looking at automation with a language model bolted on, which is fine, but it should be priced and governed like automation.
3. "How do you evaluate the agent's output, and can we see the eval results on data like ours?" Watch whether they talk about measurement or pivot to a roadmap.
4. "What is the worst thing your agent could do if it misunderstood a request, and what stops it?" Vendors who have run this in production answer fast. Vendors who have not go quiet.
5. "Who owns the prompts, the logic and the data when we leave?" Ties directly to lock-in, and the answer tells you how the relationship ends before it starts.

How to score the responses

Score against your outcome, not against who wrote the prettiest proposal. A simple weighting that works: evidence of autonomous task completion (30%), evaluation and accuracy story (20%), safety, escalation and auditability (20%), integration with your systems (15%), and total cost including the cost to run and govern it (15%). Notice that raw feature count carries no weight at all. A product can tick every box and still be a chatbot.

Weight evidence over promises everywhere. A vendor who shows you a modest agent doing one real job reliably beats a vendor who describes a brilliant one that does not exist yet. The second vendor is selling you their roadmap, and you will be paying to build it.

A skeleton you can copy

If you want somewhere to start, this is the bare structure. Fill the outcome in first, then let it drive the rest.

1. The outcome we are buying
   - Target metric and baseline (e.g. 40% of tier-1 tickets resolved, from 0 today)
   - How and when we will measure it
2. Scope and autonomy
   - What the agent decides alone; where it must escalate
3. Data and integrations
   - Systems to read/write, permissions, data residency
4. Evaluation and accuracy
   - Vendor's eval method; results on our data before go-live
5. Safety, failure and escalation
   - Error handling, human handoff, guardrails
6. Observability and audit
   - Step-level logs, decision traceability, retention
7. Commercials
   - Pricing model, cost at 10x volume, caps, exit terms
8. Evidence
   - Recorded multi-step runs, including failures; references

An RFP like this is harder to answer, and that is the point. It costs a serious vendor an afternoon and costs a pretender a deal they could not have delivered on anyway. Either way you win, and you find out now rather than nine months into a project that was heading for the 40% pile.

The buying stage is where most agent projects are quietly won or lost. Spend it well, and the pilot has a real chance. Skip it, and no amount of good engineering later will save a project that was mis-bought from the first week.