How to write an AI agent brief that gets comparable quotes in 2026

Three vendors, one description, and quotes of 18,000, 60,000 and 190,000 euro. That spread is normal. The usual explanation for it is wrong.

The instinct is to assume the cheap one has not understood the work and the expensive one is padding the number. Sometimes that is true. Far more often all three read the same two paragraphs and quoted three different projects, because the brief never said which project you wanted. Price variance in AI agent work is mostly a measure of how much uncertainty you handed the vendor and asked them to absorb.

This article is written for founders, CTOs, and operations leaders who are past the demo stage and intend to put an agent into production this year. If you are still deciding whether AI is interesting, this will be too specific to be useful. If you have a process in mind, a budget in the room, and you are about to ask three companies what it would cost, this is the document that saves you a quarter.

You will get the 9 answers that actually move a quote, what to write for each one, a before and after version of a real brief, what to deliberately leave out, and how to run the process so proposals come back comparable instead of confusing.

‍

Key takeaways

• Quotes vary by 10x because vendors price uncertainty, not because they disagree about day rates.

• The 3 expensive unknowns are the decision you want automated, the real state of your data, and what a wrong answer costs you.

• Most public AI RFP templates ask 30 questions about the vendor and almost nothing about you, which is the wrong side of the variance.

• A useful AI agent brief is 4 to 8 pages and answers 9 things, not 60.

• Naming a measurable accuracy target and an escalation path lowers a quote more reliably than negotiating does.

• Hiding your budget does not get you a better price. It gets you a proposal aimed at the wrong scope.

• Ask every vendor to list the assumptions behind their number, then compare the assumptions before you compare the prices.

‍

Why AI agent quotes vary by 10x

Quotes vary because an AI agent is not a feature with a known shape. It is a decision-making process wrapped around your data, and until a vendor knows which decision and which data, they are pricing a range of possible projects rather than one project. The honest ones quote the top of that range. The optimistic ones quote the bottom and come back in month 3 asking for more.

Consider what happens inside a vendor's head when they read "we want an AI agent to handle supplier invoices." They have to guess whether that means reading PDFs and pushing clean data into your accounting system, or reading PDFs, matching them against purchase orders, flagging mismatches, chasing suppliers by email, and posting approved invoices for payment. The first is roughly 4 weeks of work. The second is a 4 month programme touching 3 systems, a permissions model, an audit trail, and a change of how your finance team spends its afternoons. Both are defensible readings of the same sentence.

Now add the second unknown. Are those invoices arriving as machine-readable PDFs from 12 regular suppliers, or as a mix of scans, photos, and email bodies from 400 suppliers in 4 languages? That single fact can triple the extraction work and is almost never in the brief. The vendor cannot see your inbox, so they price the pessimistic case or they price the optimistic case, and you get a 3x gap that has nothing to do with their competence.

The third unknown is the one nobody writes down at all: what a wrong answer costs. An agent that drafts a reply for a human to send can be 90 percent right and still be excellent. An agent that posts a payment without review has to be far closer to perfect, which means evaluation harnesses, guardrails, review queues, and logging that a drafting agent never needs. Same technology, very different engineering bill.

This is not a theoretical risk. Gartner has predicted that over 40 percent of agentic AI projects will be canceled by the end of 2027, pointing at escalating costs, unclear business value, and inadequate risk controls. Read that list again. All three are scoping failures, and all three are decided before a line of code is written.

‍

The RFP template trap

Search for help with this and you will find a dozen templates promising 30 or 60 procurement questions every AI vendor must answer. Model hosting, training data opt-outs, SOC 2 status, audit trails, kill switches. Those questions are worth asking and you should ask them. They are also not where your money is going.

Here is the uncomfortable part. Serious vendors answer those 30 questions almost identically, because the good answers are now table stakes and everyone has rehearsed them. The questionnaire filters out obvious agent washing, which is useful, and then tells you nothing about why one proposal is 3 times another. The variance does not live on the vendor's side of the table. It lives on yours, in the facts only you can supply.

So invert the document. Spend 2 pages on what you need from them and 6 pages on what they need from you. That one change turns a beauty contest into a real comparison.

‍

What an AI agent brief actually is

An AI agent brief is a short document, usually 4 to 8 pages, that states the decision you want automated, the systems and data it touches, the accuracy and oversight you require, and what a failure costs. It is the smallest set of facts a competent vendor needs to give you a fixed price they will stand behind.

It is not a technical specification. You are not designing the system, you are removing the ambiguity that makes the system unpriceable. A brief that specifies the model, the framework, and the vector database has skipped the useful work and moved straight to guessing at the implementation.

It is also not a wish list. The most common failure we see is a brief describing an assistant that can do 9 things, none of them precisely. Vendors respond to that by either quoting the whole fantasy or quietly scoping the easiest part, and neither response helps you. One agent, one decision, one measurable outcome. The second agent comes after the first one earns its keep, and it will be cheaper because the plumbing already exists.

The test for whether your brief is finished is simple. Hand it to someone in your company who does not work on this process. If they can tell you what the agent decides, what happens when it is unsure, and how you would know next quarter whether it worked, the brief is done. If they cannot, no vendor will be able to either.

‍

If you want a running start, our AI product requirements template gives you the structure for exactly this kind of document, including the sections most teams forget until a vendor asks. It is free and takes about an hour to fill in properly.

‍

The 9 answers your brief must contain

Each of these removes a specific piece of uncertainty from the quote. Skip one and a vendor either prices the worst case or discovers it in week 6 and asks for a change order.

‍

1. The decision, not the tool

Write one sentence in the form "the agent decides X, given Y." Not "an AI assistant for customer support" but "the agent decides which of our 7 refund categories a customer email falls into, and drafts the reply for that category."

This is the single highest-leverage sentence in the document. It converts an open-ended product into a bounded task with a countable set of outcomes, which is what makes estimation, testing, and evaluation possible at all. If you cannot write it, you are not ready to buy yet, and the honest thing a vendor can sell you at that point is a short discovery engagement rather than a build.

‍

2. The current process, in numbers

Describe how the work happens today with real figures: how many items per week, how many people touch it, how long one item takes, how often it goes wrong now, and what the current error rate costs. Two paragraphs is enough.

Vendors use this for two things. It tells them the scale the system must handle, and it gives them the baseline that the business case rests on. It also protects you. A process running 40 items a week rarely justifies a 90,000 euro build, and a good partner will tell you that before you spend it rather than after.

‍

3. The data reality, not the data ideal

State where the input lives, what format it actually arrives in, how messy it is, how far back the history goes, and who can grant access. Be honest about the mess. Nobody has clean data and pretending otherwise only moves the discovery to week 5, where it is far more expensive.

The specific facts that move a price are volume of sources, consistency of format, and whether labelled examples of correct decisions already exist. A thousand past decisions with the right answer recorded is the most valuable asset you can bring to an AI agent project, because it turns evaluation from guesswork into measurement. If you have that, say so in the brief. It can cut weeks from a build.

‍

4. The systems it touches, and the direction of each

List every system the agent reads from and every system it writes to, and mark which is which. Reading is cheap. Writing is where cost, risk, and approval cycles live.

For each one, note whether a supported API exists, who owns the credentials internally, and whether a third party has to approve the integration. An agent that reads your CRM and drafts into a document is a different budget from one that writes back into your ERP, and an integration that needs a vendor's professional services team can add a month of waiting that has nothing to do with engineering.

‍

5. Where a human stays in the loop

Say explicitly what the agent may do on its own, what needs a human approval, and what it must always escalate. Three lines will do.

This is the clause that most changes a quote, because full autonomy is not a feature toggle. It is a different system. Autonomous action requires much stronger evaluation, rollback paths, permission scoping, and audit logging than a system where a person clicks approve. Most agents that reach production and stay there start with a human approving every action, then earn autonomy category by category once the numbers justify it. Ask for that path in the brief and you get a cheaper phase 1 and a safer phase 2.

‍

6. What good enough means, as a number

Name the accuracy or quality bar you will accept, and how it will be measured. "Correctly categorises at least 92 percent of invoices, measured against 300 historical examples reviewed by our finance lead" is a real acceptance criterion. "Works reliably" is not.

Unspecified quality bars are priced as perfection, which is expensive, or as nothing, which is how you end up rejecting a delivery you cannot define. Setting the bar yourself also forces a healthy conversation internally about what the process actually achieves today, which is usually less flawless than people remember.

‍

7. What a wrong answer costs

Write down the consequence of each type of error, in money, time, or risk. A miscategorised support email costs a few minutes. A wrongly approved payment costs the payment plus a hard conversation. A wrong answer to a patient or a regulator costs something else entirely.

This tells a vendor how much engineering to put into guardrails, and it tells you where the real budget belongs. It is also the fastest way to spot a topic that should not be automated yet at all. If an error is unrecoverable and undetectable, you want a human in front of it regardless of how good the model is.

‍

8. Volume, latency, and where it runs

Give the expected number of runs per day, the acceptable response time, and any constraint on where data may be processed. If your customers are European and your contracts promise EU processing, that is a scoping fact, not a detail, and it belongs on page 2.

The EU AI Act adds obligations that depend on what the system is used for, so the intended use case belongs in the brief as well. A vendor who has to reverse engineer your compliance position from a demo will either over-engineer it or miss it, and both are expensive corrections.

‍

9. Ownership after launch, and a budget range

State who will own the agent once it is live, whether your team expects to maintain it, and what range you have approved. Yes, name a range.

The fear is that naming a budget means paying all of it. In practice the opposite happens. A range lets a vendor tell you what is realistic inside it and what falls outside, which is the conversation you want. Without it, proposals arrive scoped to a number someone imagined, and you spend 3 weeks discovering that two of them were never feasible. If you want to sanity-check your range first, our breakdown of what it costs to build an AI agent in 2026 covers the real drivers.

‍

‍

A worked example: the invoice exceptions agent

Here is the same project described twice. The first version is close to what most briefs look like when they arrive.

"We are a mid-sized distributor and we want an AI agent to handle supplier invoices. Currently our finance team processes them manually and it takes too long. We would like the agent to read invoices, check them, and help the team work faster. Please send a proposal."

Three vendors quoted that: 18,000, 60,000 and 190,000 euro. The cheapest scoped PDF extraction into a spreadsheet. The middle one scoped extraction plus matching against purchase orders with a review screen. The most expensive scoped an autonomous approval workflow with supplier email chasing, because the word "handle" can honestly mean that. Nobody was wrong. The brief was.

Now the same project with the 9 answers filled in. The agent decides whether an incoming supplier invoice matches its purchase order, and routes the mismatches to a named reviewer with the discrepancy highlighted. Volume is 1,400 invoices a month from about 260 suppliers, roughly 70 percent machine-readable PDFs and 30 percent scans, arriving in Dutch and English. Two people currently spend about 11 hours a week on matching, and around 6 percent of invoices have a discrepancy worth catching. The agent reads from the shared mailbox and the ERP, and writes only to a review queue, never to the ledger. Everything it flags goes to a human, and clean matches are auto-approved only once the match rate holds above 95 percent for a full month, measured against 400 historical invoices the finance lead has already reviewed. A missed discrepancy costs an average of 340 euro. Processing must stay inside the EU. Budget approved is 45,000 to 75,000 euro for phase 1, and the internal owner after launch is the finance systems lead.

The same three vendors, given that, came back at 52,000, 61,000 and 68,000 euro. The remaining spread is real difference in approach and team, which is exactly the thing you wanted to compare. The procurement decision took 2 weeks instead of 2 months, and the eventual build had no change order for scope, because the scope was decided by the buyer rather than discovered by the builder.

Notice what the good version does not contain. No model names. No mention of frameworks, orchestration libraries, or vector databases. It is entirely a description of the business reality, which is the only part a vendor genuinely cannot guess.

‍

What to deliberately leave out

A brief gets worse when it drifts into implementation. Three things to cut.

• The technology stack. Specifying the model or framework narrows the field to vendors who agree with you and hides better options. Models change every few months, and a partner who has to work around your choice will price that constraint.

• Full autonomy in version 1. Asking for an agent that acts without review at launch raises the price and the risk at the same time, for capability you will not use in month 1 anyway. Describe the path to autonomy instead.

• Everything the agent might also do one day. Future scope invites vendors to quote it. Keep the roadmap in an appendix clearly marked as not in this phase, so vendors can design for it without pricing it.

‍

How to run the process so quotes stay comparable

The brief does most of the work, but the process around it decides whether you can actually compare what comes back. Four rules.

• Send the identical document to everyone, with the same deadline and the same contact for questions. Then share every question and answer with all vendors. It costs you nothing and it removes the excuse that one of them had better information.

• Ask for a fixed price for phase 1 with the assumptions listed. The assumptions are the real deliverable. A proposal that says "assumes 3 integrations, assumes historical labels exist, assumes no SSO requirement" is a vendor who read the brief. A proposal with no assumptions section is a vendor who will find them later at your expense.

• Ask each one to name the 3 things most likely to increase the price. Their answers tell you more about their production experience than any case study. Vendors who have shipped agents will name data quality, integration permissions, and the evaluation set. Vendors who have not will talk about model choice.

• Compare assumptions before numbers. Line the assumption lists side by side first. Most of the apparent price gap will resolve into different scope, and what remains is a genuine commercial difference you can negotiate. Once you get to contract, the clauses worth agreeing before you sign are a separate and equally unglamorous exercise.

‍

‍

How Codelevate reads an AI agent brief

When a brief reaches us, the first thing we do is try to break it. We look for the decision sentence, and if there is not one, we write the 3 versions we think you might mean and ask which is right. That single exchange resolves most of the price ambiguity before anyone estimates anything.

Then we look for the evaluation set, because it determines how the project is run. If you have a few hundred historical decisions with known correct answers, we can measure the agent against reality from week 2 and the build becomes a tightening loop rather than a leap of faith. If you do not, building that set becomes the first work package, and we say so in the proposal instead of hiding it in a day rate.

The last thing we look for is the write path. We want to know exactly which system the agent is allowed to change, under what approval, and what happens when it is wrong. In our experience this is the line between an agent that stays in production and one that gets quietly switched off in month 4 after an incident nobody had planned for. It is also the part of an AI development engagement where the honest scoping conversation pays for itself several times over.

None of this requires you to be technical. It requires you to know your own process precisely, which is a different and much more transferable skill.

‍

The transformation this buys you

The difference between a weak brief and a good one is not paperwork quality. It is whether you stay in control of your own project. With a vague description you outsource the most consequential decisions in the build, scope, accuracy, and oversight, to whichever vendor happens to guess closest, and you discover their guess in month 3. With 9 clear answers you decide those yourself, get proposals you can actually compare, sign a fixed price that survives contact with reality, and put something in production while the alternative is still in evaluation.

A weekend spent writing this document routinely saves a quarter of procurement and tens of thousands of euro in scope drift. It is the highest return on effort available anywhere in an AI project.

‍

‍

Where to go next

If you are writing this for the first time, start with the decision sentence and the data reality. Those two sections carry most of the price variance, and everything else gets easier once they are written down.

For the wider picture of shipping AI inside a software product, including where agents fit next to features your customers already pay for, our SaaS founder's AI blueprint is a practical companion to this piece.

And if you would rather pressure-test your brief with someone who quotes these projects every week, book a free call with our team. Bring the draft, however rough. An hour on the decision boundary and the data usually changes the number more than any negotiation will.