AI agent agencies: compare proposals and deliverables

You receive three proposals from AI agent agencies for the same need, with an identical stated scope, and the prices range from single to double. The difference does not lie in the written scope, but in the evidence each document requires, the reversibility clauses, and the recurring costs each one leaves vague. This guide gives you a line-by-line comparison method, with examples of concrete clauses and the weak signals that should alert you. Everything below relies on three fictitious proposals, built for the exercise, never on observed cases.

The principle: an identical scope guarantees nothing

Two proposals can describe exactly the same agent — an assistant that drafts email replies and creates calendar events — and produce very different results. The first will require demonstrations on fictitious data before signature; the second will settle for a screen mock-up. The functional scope is the same; the agency's real ability to deliver it does not show up in the description.

That is why your comparison must focus on what each proposal commits to proving, not on what it promises. A good habit is to start from a testable project brief written before the competitive process: if all three agencies answer the same document, the gaps that appear in their answers become genuine comparison signals.

The three fictitious reference proposals

To make the method concrete, here are three hypothetical proposals, labelled A, B and C, all for the same agent: drafting email reply drafts, creating calendar events from those exchanges, and a tracking dashboard. Fictitious prices: A offers a €28,000 fixed fee plus €900 per month, B offers €41,000 plus €350 per month, C offers €33,000 plus €1,400 per month.

At first glance, A looks cheapest and C the most expensive on recurring costs. But proposal A mentions no test accounts, no data handover and no support commitment beyond a vague sentence. B includes an evidence phase on fictitious data and a detailed reversibility plan. C itemises usage costs but says nothing about code ownership. The real ranking therefore depends on the clauses, not the sticker price.

Requiring evidence on fictitious data

The first comparison criterion is the nature of the evidence requested before commitment, or in the initial phase. A demonstration on the vendor's own demo data proves the agency can give a demo. Evidence on your fictitious data — anonymised emails, test calendars, edge cases you have chosen — proves it can handle your reality.

Compare explicitly what each proposal provides for:

• Data set: who supplies the test cases, how many edge cases are included, and who validates that they are representative.
• Environment: is the evidence produced in an isolated environment, with test accounts separate from your production accounts?
• Success criteria: does the proposal set measurable criteria, or only a delivery date?

A proposal that refuses evidence on fictitious data, or bills it as an expensive option, signals that it would rather be judged on its presentation than on its results. That is a weak signal, not an automatic disqualification — but it should be discussed in a meeting, not left in the document.

The account list and real permissions

Second criterion: each proposal must list the required accounts and accesses, with the exact permission level. This is where vague descriptions cost the most. A concrete example from the Gmail ecosystem: the gmail.compose and gmail.modify scopes can both allow sending messages. If your need is "prepare drafts, never send", a scope label is not sufficient as a guarantee: limiting behaviour to drafts must be an application-level control, tested and documented. A label is not a Gmail permission boundary.

Compare the proposals on precisely this point. If agency A writes "read-write Gmail connection" and nothing more, while agency B writes "draft creation only, sending blocked at application level, a no-send test included in acceptance testing", you are looking at two very different levels of maturity for an identical scope. The same logic applies to identifiers: a Gmail draft's identifier is stable, but the identifier of the message it contains changes each time it is modified — an agency that has genuinely worked on this case knows it and mentions it in its version handling; one that has never implemented this flow will discover it at your expense.

Code ownership, confidentiality and data

Third comparison block: who owns what at the end. The proposal must answer three questions unambiguously. Do you own the code specifically developed for you, or is it licensed? Are configurations, prompts and business rules exportable in a readable format? Does your data pass through third-party services, and which ones?

On confidentiality, beware of proposals limited to "we comply with the GDPR". Ask for the list of subcontractors and transfers outside the European Union, and what happens to the data at the end of the contract. The core data protection principles — minimisation, retention periods, security — give you a simple frame for evaluating the answers: a proposal that cannot say where your data sleeps at night has not done the work. In our three fictitious proposals, A mentions no subcontractor, B lists them with hosting countries, C refers to "our partners' privacy policy" without naming them. Only B lets you verify anything.

Responsibilities, acceptance and testing criteria

The acceptance clause decides who carries the risk at the end of the project. A good clause defines objective criteria, a testing procedure, a correction period and a consequence in case of repeated failure. A bad clause says "the client validates the delivery" — which shifts the whole burden of proof onto you.

Compare the proposals on four points:

1. Acceptance criteria: are they quantified and testable, or descriptive? "The agent prepares correct drafts" is not testable; "on the 30 cases in the test set, at least 27 drafts judged usable without major rewriting by two evaluators" is.
2. Acceptance procedure: is there a separate acceptance document, with a schedule and handling of reservations? A guide on chatbot acceptance testing and handover can serve as a grid for judging the quality of what each agency proposes.
3. Responsibilities: what happens if the agent sends a wrong email or creates a duplicate event? The proposal must distinguish software failure, user error and force majeure.
4. Caps: is there a liability cap, and is it consistent with the price?

A technical point is often revealing: calendar synchronisation. The Calendar API allows creating events with explicit identifiers, but there is no guaranteed global transaction between your system and the calendar. An agency claiming "100% guaranteed synchronisation" without explaining its failure-recovery strategy, has either not understood the problem or is not telling you. Ask how it handles an event created on the calendar side whose confirmation on your system's side failed.

Reversibility: the clause that protects your future

Reversibility is the most neglected and most decisive criterion over three years. It answers a simple question: if you change agencies or bring the project in-house, what do you get back, in what form, and at what cost?

A serious reversibility clause specifies: handover of the code and its documentation, export of configurations and business rules, return of data in a documented format, transition support for a defined period, and no exit penalty. It also specifies what stays with the agency: the generic components it reuses for other clients may legitimately remain its property, provided your project works without them or with a continuation licence.

In our fictitious proposals, B includes a ten-page reversibility plan with a restoration test; A mentions "source code handover on request"; C provides for an "exit fee equal to three months of fees". None of these formulations is illegal, but they create very different negotiating positions. An agency confident in the quality of its delivery has nothing to fear from a precise reversibility clause.

Support, maintenance and recurring costs

The real cost of an agent is not read in the initial fixed fee but in the sum of recurring costs over two or three years. Compare the proposals on a common grid: hosting, API and model licences, volume-driven consumption, corrective and evolutive maintenance, on-call cover, and price revisions.

Two traps come up systematically. First trap: API consumption billed by volume, whose high scenario nobody has costed. Ask each agency for an estimate across three scenarios — low, nominal, peak — with the calculation formula. A guide on the realistic usage budget of an agent helps you build these scenarios and spot proposals that have not done the maths. Second trap: channel-based billing. If your agent sends WhatsApp notifications, the platform's pricing is per delivered message, with different categories and markets, and not all messages are chargeable — a proposal applying a single flat rate per message either ignores this mechanism or hides a margin in it.

Support is also comparable on verifiable items: coverage hours, contractual response time, the distinction between incident and change request, and what triggers an additional quote. "Support included" without a definition means everything that is not a bug will be billed.

Analysing concrete clauses and weak signals

Beyond the major blocks, the comparison plays out in the detail of the wording. Here are typical fictitious clauses and what they reveal.

Clause	Wording observed (fictitious)	What it suggests	What to do
Evidence	"Demonstration on our demo environment"	The agency avoids your edge cases	Require a test set on your fictitious data
Permissions	"Full access to the mailbox"	No application-level control planned	Ask for least privilege, tested
Ownership	"The deliverable remains the agency's property"	Unpriced long-term dependency	Negotiate a perpetual licence or transfer
Acceptance	"Validation at delivery by the client"	Risk entirely on you	Propose quantified criteria from the brief
Reversibility	"3-month exit fee"	Deterrent departure cost	Cap or remove it, require a restoration test
Support	"Responsive support included"	No measurable commitment	Define hours, response times, contractual scope
Recurring	"Platform fees based on usage"	High scenario not costed	Require three scenarios with a calculation formula

Three weak signals deserve particular attention. First, the absence of an account list: an agency that cannot say which accesses it needs has not yet designed the system. Next, the confusion between protocol and business rules: the MCP protocol, for instance, enables exchanging tools and context with a model, but it does not choose your business rules or permissions for you — a proposal presenting "MCP" as the answer to a governance question confuses the pipe with the decision. Finally, identity proof by shortcut: a QR code to scan to "connect your WhatsApp agent" does not prove an official connection to the Business Platform; ask for the exact channel, the 24-hour service window and the handling of approved templates, plus the terms of use of the WhatsApp Business channel.

A five-step comparison procedure

Here is a procedure you can apply as soon as the proposals arrive.

1. Normalise the scope. Take your brief and check that the three proposals cover the same use cases, the same channels and the same exclusions. Reclassify any divergence in a gap table before comparing prices.
2. Score the evidence. For each proposal, note what is proven on your fictitious data, what is promised, and what is missing. An unprovable promise carries no weight in the comparison.
3. Cost the three-year total. Add the fixed fee, the contractual recurring costs, the consumption estimate across the three scenarios, and a provision for changes. Compare these totals, not the sticker prices. A guide on the full cost of an AI agent details the often-forgotten line items.
4. Test reversibility. Ask all three agencies the same written question: "If we end our collaboration in eighteen months, what do you hand over, in what format, and at what cost?" Written answers beat meeting speeches.
5. Check acceptance. Reread each proposal's acceptance clause and restate it as quantified criteria. If an agency rejects your criteria, ask for its own in writing.

The main example: one request, three answers

Back to the initial request: email drafts, calendar event creation, dashboard. Here is how the three fictitious proposals handle the same point — email sending — and why the gap matters.

Proposal A writes: "The agent sends replies directly, with optional human validation." It uses a broad write scope and rests security on a checkbox. The day validation is skipped by a user in a hurry, the agent sends on its own. Proposal B writes: "The agent creates drafts only; sending is blocked at application level; a no-send test on 20 cases is part of acceptance." The behaviour is limited by construction, not by discipline. Proposal C says nothing about sending; it describes drafting and leaves the question open.

For a scope identical on paper, these three formulations produce different risks, tests and acceptance costs. This is exactly the kind of gap your comparison must surface, line by line, before price becomes the only decision criterion. The same reading applies to the calendar: proposal B specifies that it uses explicit event identifiers to enable updates and deduplication, whereas A and C do not mention it — a detail that will become a production incident if your system and the calendar each create their own version of the truth.

If you would like to put this reading grid to the test on a concrete project, you can define your needs with Edeverse.

Frequently asked questions

Is a more expensive proposal necessarily better drafted?

No. Price and clause quality are largely independent. In our fictitious examples, the most expensive proposal on recurring costs is the one that leaves code ownership vague. Judge each clause on its content, then set the price against the residual risk you are willing to carry.

Can you request evidence on fictitious data before signing?

Yes, and it is a reasonable practice if the scope of the evidence is limited and fairly compensated. You can propose a paid scoping phase, with a fictitious data set you supply and written success criteria. A serious agency accepts being tested on a bounded scope.

What if an agency refuses to list its subcontractors?

Ask at minimum for the categories of subcontractors, the hosting countries and the contractual commitments binding you. If the refusal persists, that is a major weak signal: you will be unable to assess data transfers or exercise your rights in case of incident.

Is the MCP protocol a decisive selection argument?

It is an architecture element, not an answer to your governance questions. MCP organises the exchange of tools and context, but business rules, permissions and controls still have to be defined and tested. A proposal that makes MCP its sole value proposition deserves a follow-up question: what exactly do you do about permissions and acceptance testing?

How do you compare recurring costs when the pricing models differ?

Rebuild the three-year total yourself from each proposal's assumptions, using your own volume scenarios. If an agency refuses to provide its calculation formula or consumption assumptions, cost the high scenario yourself and include it in the comparison, flagging it as a risk.