Selling AI agents is selling a bounded promise

The short version

• An agent is not the product. The bounded piece of work it closes without a human is the product.
• A buyer who has already seen a demo does not need another demo. They need the failure path written down.
• A large vendor's published per-conversation rate is the number buyers compare your quote against, whether or not you compete with them.
• Most of the cost in an agent build is front-loaded integration, policy and evaluation, none of which scales with conversation count.
• Saying which parts you will not automate is what makes the rest of the proposal credible.

What are you actually selling when you sell an AI agent?

A bounded piece of work that currently needs a person, done without one, inside limits you are willing to write down. That is the product. The agent is an implementation detail, and buyers who have sat through three of these pitches can tell the difference.

The word agent has stopped carrying information. It gets used for a chat window, a scripted flow with a language model in the middle, a tool-calling loop, and a system that files tickets in someone else's software. A buyer hearing 'we build AI agents' learns nothing they can act on. A buyer hearing that you will take inbound refund requests, check the order, apply the policy, issue the refund under a threshold and escalate everything else knows what they are being offered.

So the artefact you are selling is a scope, not a capability list. Three things belong in it: the workflow, named the way the buyer's own team names it; the boundary, meaning what the agent refuses and hands back; and the failure path, meaning what concretely happens when it gets one wrong.

The last one does most of the work. Every serious buyer has already pictured the agent telling a customer something untrue. Raise it first and show the containment, and you have answered the question that was going to stop the deal anyway.

Who is buying AI agents, and what do they already believe?

Mostly people who are already running something. Adoption is not evenly spread. The Census Bureau's Business Trends and Outlook Survey puts large firms, those with at least 20 employees, at the top as AI users among US businesses. Smaller firms are not absent: in a survey of 400 US small business owners fielded for Talkdesk, half said they already use AI in customer service.

Two things follow for the pitch. First, you are usually not introducing the idea. Somebody in the account has already tried a chatbot, a copilot licence, or a flow built in a no-code tool, and they have an opinion about it. Second, the motive is not always cost. A national survey of 947 small businesses run by Reimagine Main Street found them looking to AI for competitive edge rather than efficiency alone.

That changes the question you should lead with. Not how many hours this could save, which invites a spreadsheet argument you will lose on assumptions. Better: what does your team currently refuse to do because there is no time? A backlog of unanswered quote requests, a knowledge base nobody updates, a weekend queue that waits until Monday. Those are agent-shaped, they have no incumbent to displace, and the buyer can tell whether it worked without needing to trust your numbers.

Why do agent demos fail to close?

Because a demo proves the happy path, and the buyer's risk is not on the happy path. You type the question you know works, the agent answers, everyone nods, and nothing has been learned about the request that arrives at 2am with a half-typed order number and an angry customer attached.

Replace the demo with a replay. Ask for 100 real items from the queue you are proposing to take, redacted if they need to be, and run them. Then show three lists: what it handled cleanly, what it escalated, and what it got wrong. The third list is the one that sells. Nobody believes a system with no third list, and the buyer is waiting to find out whether you volunteer it or they discover it in production.

This also fixes the accuracy conversation, which otherwise runs in circles. A single percentage is close to meaningless to a buyer, because it hides which errors happened. Two systems at the same number are not equivalent if one hands back anything it is unsure about and the other invents a confident answer. Sort the errors by consequence and talk about the worst category only.

A replay gives you one more thing: an honest answer on timelines. If their real traffic breaks the first version, you learn that during the sale, when changing scope is still free.

How should you price an AI agent?

Start from the number the buyer has already seen. When Salesforce launched Agentforce it announced pricing at $2 per conversation, and the same rate is still shown on its pricing page. Whether or not you compete with Salesforce, a per-conversation figure from a large vendor is the anchor in the room, and a quote well above it needs a reason the buyer can repeat to their finance lead without you present.

The reason is usually that you are not selling a conversation. A platform rate covers inference and a generic flow. A build covers the integration, the policy encoded in the escalation rules, the evaluation set, and the person who reads the logs in week three. Those costs are front-loaded and mostly fixed, so charging for them per conversation fits neither side. It punishes the buyer for volume, and it starves you on a pilot that runs 40 conversations a week.

A shape that holds up: a fixed fee for the build, scoped to one workflow, then a monthly fee covering operation, evaluation and change. Pass inference costs through at cost and show them. Buyers who can see a token line they are able to verify stop suspecting the rest of the invoice.

Avoid pricing on outcomes you do not control. Deflection rate depends on how their knowledge base is maintained and how their customers behave. Sign up to a number that moves for reasons on their side of the line and you will spend the contract arguing about attribution.

Which pricing shape fits which deal?

What should the first engagement look like?

Paid, narrow, time-boxed and written down. One workflow, an agreed measure of success chosen before the build starts, a fixed end date, and a statement of what happens if it misses. Free pilots sound generous and behave badly: nobody staffs them, nobody tests them, and they end by quietly expiring.

The measure matters more than its target value. Pick something the buyer's existing reporting already produces, so there is no argument about the instrument. Tickets closed without a human touch. Median first response time on a named queue. Quote requests answered within an hour. If you have to build the measurement, you have picked the wrong measure.

Scope should be small enough to feel underwhelming. One queue, one language, one category of request, read access where write access is not needed yet. The agent that issues refunds up to £20 and escalates everything else ships, gets watched, and earns the next conversation. The one that handles all customer enquiries never passes review, because nobody can approve a boundary that has not been drawn.

Write the exit into the proposal: what the buyer keeps if they stop. The prompts, the evaluation set, the integration code, the logs. A seller comfortable describing the exit reads as somebody who expects to be kept, and it removes the quiet objection about lock-in that otherwise never gets voiced.

What belongs in the first proposal?

• •The workflow, named the way the buyer's own team names it.
• •The escalation rule, written as a sentence a support lead could enforce by hand.
• •One success measure that their existing reporting already produces.
• •The failure path: who is notified, how it is contained, how a bad answer gets corrected.
• •What varies with volume, priced separately and shown at cost.
• •The end date, and what the buyer keeps if they stop.

How do you answer 'will this replace my team'?

Say what is true: the first-line queue shrinks and the team moves to the work that was waiting. That is also what buyers themselves expect. In the Talkdesk survey of small business owners, 9 out of 10 said they would keep or grow their human service teams.

Promising headcount reduction is a bad trade even when the buyer asks for it. You cannot verify it inside a pilot, it makes everybody you need help from into an opponent, and it sets a target that will later be measured by somebody in finance who was not in the room for the scope discussion. The team whose cooperation you need, for access to the knowledge base, the ticket history and the policy document, will read the proposal.

A better framing is capacity they do not currently have. Nights, weekends, the second language, the backlog that gets triaged and never answered. Nobody defends territory they were never able to cover.

If a buyer genuinely wants to cut a team, that is their decision and not yours to argue with. Just keep it out of the contract, because the moment it is in writing, every escalation becomes evidence.

What do technical buyers ask that sales decks do not answer?

Permissions, logs, evaluation, and what happens when the model changes. The person who will have to run the thing is usually in the room, and their questions are not the budget holder's questions. Stack Overflow's 2025 developer survey drew 31,877 responses to its AI agents question, which is a fair signal that this audience has formed views rather than waiting to be told what to think.

Expect four in particular. Which identity does the agent act as, and can it read anything the requesting user cannot? Where do inputs and outputs get stored, for how long, and who can query them? How do you know a change made it better, which really means: is there an evaluation set, and did it exist before the change? What happens when the underlying model is deprecated or its behaviour shifts under you?

Answer these in writing before the meeting. A technical reviewer rarely wins a deal, but they can stop one, and the thing that stops it is usually an answer that sounds improvised.

It is also the right moment to be plain about what you do not have. No certification, no completed external audit, no compliance badge: say so, then show the controls you actually run. A clear statement that you do not hold something, followed by what you do instead, survives review. A vague claim does not.

When should you tell a buyer not to buy an agent?

When the process is not written down anywhere, when the volume is too low to pay for the build, or when every output needs a named human's sign-off before it leaves the building. In those situations an agent adds a layer without removing any work, and saying so is worth more than the revenue.

Three specific stop signs. The policy exists only in one person's head, so there is nothing to encode and the first disagreement has no referee. The data sits in a system nobody can get an API key for, so the agent will be guessing. The queue is 15 items a week that somebody handles while doing something else, and no measure will ever show a difference.

There is a smaller version of the same honesty. Sometimes the right answer is a form, a routing rule, or a better template. Saying that costs you one project and makes every later conversation easier, because the buyer now believes you when you say something will work.

The alternative is worse than losing the deal. An agent sold into a process that cannot support it fails publicly, inside the buyer's own organisation, and the person who championed it does not champion the next one.