How to Price an AI Agent Project

A vendor quotes you $400,000 to build an AI agent. Is that expensive? You have no idea. Neither do they. The price of an agent and the value of an agent are set by two different things, and the proposal in front of you only addresses the first.

Here's the gap. Build cost is driven by scope and engineering hours. Value is driven by how the agent behaves against real data, real customers, and real edge cases — which nobody can fully see in a demo. A six-figure build can produce zero. A modest build can pay for itself in a quarter. So the question a CFO should ask is not "what does this cost" — it's "who is on the hook if it doesn't move the number." That single question reorganizes the entire negotiation.

Why the three default pricing models all fail here

There are three pricing models on the table for any technology project, and AI agents quietly break all of them.

• Time and materials. You pay for hours. The vendor is rewarded for the project taking longer, and the agent's actual performance never enters the math. You are buying effort, not outcome.
• Fixed-bid build. You pay a set price for a defined scope. Feels safe. But "the agent passes UAT" and "the agent holds up in production traffic" are different milestones — and fixed-bid pays out at the first one, before a single real customer has tested its edges.
• Per-seat or per-conversation SaaS. Clean and predictable, but it prices access to a tool, not a result. You can light up 500 seats of an agent platform and move nothing — the meter runs whether or not the agent ever resolves a case correctly.

All three share one flaw. They price the building of a thing whose value is unknown until it runs. With ordinary software you can mostly predict value before you build — a payroll system processes payroll, deterministically, the same way every run. An agent is probabilistic: its value lives in how it handles the inputs no one specified, and that only shows up under load.

“

You are not buying code. You are buying a probability distribution over outcomes. Price the distribution, not the code.

Separate the three things you are actually paying for

An honest agent quote has three distinct cost layers, and conflating them is how budgets get torched. Make your vendor price them on separate lines.

• Data readiness. Getting the agent the clean, governed, retrievable data it needs to act — resolving duplicate customer records, unifying the fields the agent will read, wiring access to the systems it must query at runtime. On Salesforce, this is the Data Cloud work that has to land before Agentforce is worth turning on. It is usually the largest and most underpriced line, because an agent can only act on what it can actually see.
• The build. Designing the agent's instructions, the tools it can call, its guardrails, and its escalation paths to a human. Real engineering, but typically smaller than people expect once the data underneath it is sound.
• Run and care. Keeping the agent accurate, monitored, and improving after launch — when models get deprecated, new edge cases surface in the logs, and the business changes underneath it.

If a quote bundles these into one number, you cannot tell whether you are paying for durable value or for a slide deck. The data layer especially deserves its own line. We put data before agents for a reason: point a capable agent at fragmented records and you have paid to automate confusion faster. The cheapest way to make an agent fail is to skip the data work and call the build done.

The run cost is the cost. The build is the down payment.

CFOs are trained to scrutinize the big upfront number. With agents, the upfront number is often the least important one. An agent is not a deliverable you receive and own outright; it is a system that has to be operated. The model version it was built on gets deprecated. A pricing or policy change breaks an assumption baked into its instructions. A new product line appears that it has never seen and confidently mishandles.

So the number that should dominate the negotiation is the annual run-rate, not the build fee. A low build price with no plan to operate the thing is not a discount — it's a deferred bill, payable the first week the agent says something wrong to a customer with nobody watching. Ask every vendor: after launch, who reviews this agent's transcripts, how often, and what does that cost? If they don't have a crisp answer, you've found the trapdoor.

Tie the fee to the number — but define the number first

The cleanest way to align a vendor with you is to tie part of their fee to the outcome the agent is supposed to move. This is the model we run on, and it's worth understanding even if you never use it, because constructing the contract forces the right discipline before any money is spent.

Outcome-tied pricing only works if you nail down the metric before anyone writes code. Pick one number the agent is accountable for — speed-to-lead, resolution rate, qualified pipeline, cost per case — and write down its baseline as it stands today. Three things make a baseline defensible: a single agreed definition of the metric, a measurement window long enough to smooth out noise, and a source of record both sides trust. In our Green Subsidy solar engagement the metric was speed-to-lead — contacting inbound homeowners faster than a human team could clear the queue. It was defined and baselined up front, which is precisely why it could anchor the fee instead of becoming an argument later.

The discipline is the real prize. If a vendor won't tie any part of their fee to an outcome, ask why — the honest answer is often that they aren't confident it will move. And if you can't establish the baseline, you've learned something more valuable than any quote: you're not ready to buy an agent yet. You're ready to fix your measurement. That's cheaper to discover now than after the build.

A five-question pricing checklist for the buyer

Bring these to the next vendor call. The quality of the answers tells you more than the quoted price does.

• What single number is this agent accountable for, and what is its baseline today?
• Show me the data line on its own. What does it cost to make my data agent-ready, and what specifically is broken about it now?
• After launch, who operates this, how often do they review it, and what is the annual run cost?
• What share of your fee are you willing to tie to that outcome?
• What is your plan for the week the agent gets something wrong in front of a customer?

A vendor who answers all five plainly is pricing a result. A vendor who can only answer the first two is pricing a build and quietly handing you the risk on the rest. The gap between those two is the entire game.

What "too cheap" and "too expensive" actually mean

Too cheap usually means the data work and the run cost have been quietly removed from scope, and you'll meet them again as change orders once you're committed. Too expensive usually means you're funding a risk premium on an undefined outcome — the vendor is padding to cover a result no one will commit to. Define the outcome and the legitimate price range narrows fast, because there's less unknown to insure against. Ambiguity is the most expensive line item in any agent quote, and it never appears on the quote.

So price the agent the way you'd price any bet you actually understand: name the payoff, write down the baseline, separate the build from the run, and find out who's standing next to you if it misses.