How to Compare Two AI Agent Proposals Side by Side: A Grid

To compare AI vendor proposals, rewrite both into the same grid and judge them on four things: scope, ownership, support and exit terms. Price and demo polish tell you little until you know what is included, who holds the accounts and data, what happens after launch and what you can take with you if you leave. A proposal that cannot fill every cell of the grid is a pitch, not yet a proposal.

Key takeaways

• Proposals are written in each vendor's own vocabulary, so the first job is translation into one shared format before any judging begins.
• Scope should be stated as one role, the tools and memory it needs, the approval boundaries and a success measure you can observe.
• Ownership is about accounts, keys, data, prompts, configuration and documentation. Ask who holds each one, in writing.
• Support and exit terms reveal more about a vendor than the feature list does. Silence on either is an answer.
• Score each cell as clear, vague or missing, then resolve every vague cell with a written question before you decide.

Why do two AI proposals rarely compare cleanly?

One vendor sends a long document built around a platform. Another sends a short one built around a person. One lists capabilities, the other lists deliverables. Put them next to each other and they seem to describe different purchases, because they do.

The usual mistake is to compare the parts that are easy to compare: the demo, the length of the feature list, the confidence of the writing. These are the parts a vendor controls most. The parts that decide whether the engagement works for your company are quieter: what the agent is allowed to do, who can change it, who answers when it fails, and what happens to your setup at the end of the contract.

A useful proposal is one you could hand to a new operations manager who was not in any of the meetings. If that person could not tell what is being delivered, who owns it and how to leave, the document is incomplete regardless of how good the sales conversation was. The same logic sits behind a good statement of work, and it is worth reading before you sign anything.

How do you put both proposals into the same shape?

Before scoring, normalise. This takes an hour or two and removes most of the confusion. Do it yourself, or give it to one person so the translation is consistent.

• Create one page per proposal with four blocks: scope, ownership, support, exit.
• Copy the vendor's own words into each block, quoted exactly, without paraphrasing in your favor.
• Mark every statement as a commitment (the vendor will do this), a capability (the vendor can do this) or a hope (this should happen). Only commitments count.
• Leave a cell empty when the proposal is silent. Do not fill it with what you assume is normal.
• List every question the empty and vague cells raise, and send both vendors the same questions at the same time.
• Compare the answers as carefully as the original documents. A fast, specific answer is evidence. A slow, general one is also evidence.

The distinction between commitment and capability does most of the work. Many proposals are written mostly in the language of capability: the platform supports, the team can, the agent is able to. None of that obliges anyone to deliver it.

Scope: what exactly will the agent do?

Scope is where proposals diverge most, and where vague wording is most expensive. An agent that is described as handling customer operations might mean one narrow workflow or an open-ended assistant. You need to know which. If the answer is not obvious, what an AI agent for business is is a useful shared reference for the conversation.

Check each proposal for these items:

• One named role, described the way you would describe a job: purpose, inputs, outputs and who it reports to.
• The memory it needs: which documents, histories or records it can read, and how they are kept current.
• The tools it can use: which systems it can read from, which it can write to, and which actions are off limits.
• Approval boundaries: which actions need a human to confirm, and who that human is.
• A success criterion you can observe, with a method for measuring it, not a general promise of improvement.
• What is explicitly out of scope, so that later requests are visibly changes and not arguments.

The success criterion deserves extra attention. A proposal that defines success only as adoption or satisfaction leaves room for a lot of disappointment. A proposal that names a task, a sample of real cases and a way to review outputs is describing an evaluation, which is how serious agent work is tested. Anthropic's write-up on [evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) is a good outline of what that looks like, and it helps you judge whether a vendor's testing language has substance behind it. If you want a method for setting the bar, see success criteria for an AI agent pilot.

Watch for scope that is too large as well as too small. A proposal promising many roles at once, with no order and no approval boundaries, usually means the first role will be done thinly.

Ownership: who holds the accounts, data and work?

Ownership questions feel legal, but they are operational. They decide whether you can change vendors, audit activity or recover from an incident. Ask for a plain list, one line per asset, with the holder named.

• Model accounts and API keys: are they in your company's name or the vendor's? See who owns AI API keys for why this matters.
• The agent's own identity and accounts in your email, chat and business systems, and who can disable them.
• Your documents, records and conversation history, and whether any of it is used to train a provider's models.
• Prompts, instructions, workflows, configuration and integration code: who owns them and in what format they can be handed over.
• Documentation: whether it exists, who writes it and whether it is updated as the agent changes.
• Logs and evaluation results, and whether you can read them without asking.

Permissions belong in this block too. The proposal should say what access the agent receives and on what principle. The usual standard is least privilege, meaning each tool gets only the access its job requires. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) states the principle clearly. If a proposal asks for broad administrator access to get started and promises to tighten it later, treat that as a finding.

A simple test: imagine the vendor disappears tomorrow. For each asset in the list, could your team still log in, read it and keep the agent running or at least switch it off? Where the answer is no, you have found a dependency, and the proposal should price it, justify it or remove it.

Support: what happens after go-live?

Most proposals describe the build in detail and the operation in a sentence. Yet an agent is closer to a service than a delivered object. Models change, integrations break, documents go stale and people ask it things nobody planned for. Support terms tell you who deals with that.

Compare these points across both proposals:

• Who monitors the agent, what is monitored, and how you see the results.
• How problems are reported, who acknowledges them and in what time frame, stated as a commitment and not as a goal.
• How changes are requested, reviewed and approved. See how to request and approve changes to a managed agent.
• Whether there are recurring reviews of quality, permissions and integrations, and who attends.
• What happens when an underlying model or connected system changes.
• What the vendor does in an incident: containment, communication and a written account afterward.
• What is included in the recurring arrangement and what is billed separately.

Support language is easy to inflate. Phrases like priority support or dedicated team mean little without a described process. Prefer the proposal that explains how a problem travels from report to resolution, even if it sounds less impressive. For realistic expectations on this topic, read what to expect from uptime and support.

Observability is a useful signal of seriousness. A vendor that can show what the agent did, which tools it called and where it failed is operating something it can improve. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains the underlying idea if you need vocabulary for the question.

Exit terms: how do you leave without losing the work?

Exit terms are the section vendors most often leave out, and the one you will wish you had read most carefully. You do not need to plan on leaving. You need the option to leave to be real, because that option keeps everything else in the relationship honest.

Look for:

• The notice period, and whether leaving is possible before a fixed term ends.
• A handover package: configuration, prompts, workflows, integration details, documentation and evaluation sets, delivered in formats your team or another provider can read.
• Deletion: what happens to your data and logs at the end, how it is confirmed and how long it takes.
• Transition help: whether the vendor will support a handover, and in what form.
• Anything proprietary that the agent depends on, such as a closed runtime or a custom format, and what replaces it.
• Backup and restore: whether you can obtain a restorable copy of the working setup. See backup and restore for AI agents.

The point is not to find a vendor that makes leaving painless. It is to see how each vendor treats the subject. A clear exit section suggests a team that expects to earn the renewal. A missing one suggests the relationship depends on switching being hard. Avoiding AI vendor lock-in and migrating agents between providers describe what a clean departure involves.

How do you score the grid and decide?

Once both proposals and both sets of answers are in the grid, score each cell in three levels: clear, vague or missing. Do not add weights yet. First count where each proposal is clear and where it is not. Then read the blocks in this order of importance for most companies: ownership, exit, scope, support. The order reflects how hard each problem is to repair later. Scope can be revised in a change request. Ownership and exit are very hard to renegotiate once the agent is in daily use.

A short decision guide:

• If one proposal is clear in all four blocks and the other is not, choose the clear one, even if the other looks more capable.
• If both have missing cells, send questions and pause the decision. Do not let a deadline stand in for information.
• If both are clear but differ on ownership, prefer the one that leaves accounts, keys and configuration in your hands.
• If both are clear and similar, the tie is broken by evidence: a small paid trial on one real task, as described in testing a vendor's claims before committing.

An illustrative scenario: a logistics firm receives two proposals for an agent that drafts replies to shipment inquiries. Proposal A is polished, promises broad capability and keeps the model accounts under the vendor's name, with no exit section. Proposal B is plainer, names one role, lists the exact systems it reads, puts the accounts in the company's name and describes a handover package. After the written questions, A answers on support in general terms, while B explains its review rhythm and escalation path. The firm chooses B, not because it promises more, but because every cell in the grid can be checked.

Be Human works to this standard in its own proposals. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with the agent's identity, memory and permissions kept under the client's control. You can hold any proposal to the same grid, including ours. For a broader view of the risk side, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a useful reference for how to think about governance.

Frequently asked questions

How many proposals should we compare? Two or three is enough for most companies. More than that tends to produce comparison fatigue, and the quality of your questions matters more than the number of respondents. If you need to standardise the request itself, an RFP for AI agent implementation services gives every vendor the same structure to answer.

Should price be part of the grid? Add it after the four blocks are scored, as a separate column, so it does not bias the reading of the substance. Compare what is included, not just the headline figure, and ask each vendor to list what would be billed separately. The ways vendors structure charges are explained in AI agent pricing models.

Who in the company should review the proposals? The person who will own the agent day to day should lead, with someone checking contracts and data terms and someone checking systems access. Smaller companies can combine these roles, but each question should still be asked by someone. The procurement review guide shows what each function usually checks.

What if a vendor refuses to answer questions in writing? Treat the refusal as information. Vendors with a clear process can usually state their terms plainly, and those who prefer to answer only in conversation leave you with nothing to rely on later. Note the refusal in the grid and weigh it against the other proposal.

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