Fixed price for agentic AI: how pods make it possible

“Can you give me a fixed price for this?” is the question every CTO asks and every vendor dodges when the “this” is an AI agent. The dodge is understandable. Agents are new, models change, the client’s data is a mystery until you open it. Time-and-materials feels safer for the vendor and honest for the client. I think it is neither, and this essay is about why, and about how we price agentic work at Ailoitte in a way that is fixed for the client and survivable for us.

Why time-and-materials fails for agents

Hourly billing works when effort and progress move together. On a conventional build they mostly do: a week of work produces a week of features. On an agent they do not. A week of prompt tuning can produce nothing measurable. A single afternoon writing the list of things the agent must refuse can be the most valuable work on the project, and it produces no code. When the client pays for hours, they pay for the first and cannot see the second.

The deeper problem is that hourly billing removes the pressure to define “done”. An agent can always be a little more accurate, a little more polite, cover one more edge case. Without a written outcome, nobody has to decide when it is good enough, so the project drifts into a permanent pilot. A permanent pilot is the most expensive way to not ship, and hourly billing makes it the default.

There is a third problem, and it is the one clients feel first. Time-and-materials puts the whole of the risk on the buyer. If the agent turns out to be harder than anyone thought, the buyer pays more. The vendor’s incentive is to discover that it was harder.

Fixed-price agentic engagement

An engagement in which the vendor commits to a price for an agent that passes a named evaluation set at an agreed rate, enforces an agreed refusal list, and runs inside an agreed budget, with changes to any of the three priced as scope changes.

What makes an agent priceable

You can price anything you can define. The reason agents feel unpriceable is that “done” is usually a feeling. It becomes a number when it is written down as three artefacts.

The evaluation set. A fixed collection of real cases, with the expected outcome for each, and an agreed pass rate. “The agent resolves 85 percent of these 400 support conversations without escalation, and never escalates one of these 40 incorrectly” is a scope. “A good support agent” is not.

The refusal list. The actions the agent must never take and the requests it must decline, enforced at the tool layer. This bounds what “wrong” can mean, which bounds how much testing is enough, which bounds the price.

The budget. Cost per run as a range, cost per month as a ceiling, and the behaviour at the ceiling. This bounds the architecture: a two-cent run and a two-dollar run are different systems, and you have to know which one you are building before you can price it.

Notice that these three artefacts are exactly the decisions that most enterprise agent projects postpone until the pilot review, which is where they die. Fixed price is not a pricing trick. It is a forcing function that moves those decisions into the first two weeks, when they are cheap.

How a pod carries the risk

At Ailoitte we deliver this with what we call AI Velocity Pods: a small senior team that takes an outcome from definition to production for a fixed price. The pod model works because it splits the risk along the line where each side can actually control it.

The pod carries the delivery risk. Given a defined outcome, will the agent pass the evaluation set inside the budget? That depends on architecture, tooling and model choice, all of which the pod controls. A small senior team can carry that risk because everyone in it has made these decisions before and everyone has read every prompt and every failing trace. That is not possible in a team of twenty, which is why the pod is small, and it is why the price can be fixed. It is also why every agent in Leverge ships with its runtime workflow published: the definition is the product, and a buyer should be able to read it before they pay for it.

The client carries the definition risk. What must the agent refuse? Which cases go in the evaluation set? What is a run worth? Only the client can answer those, and the definition phase exists to move as much risk as possible from this bucket into the first one before anyone commits a number. If the client changes the evaluation set or the refusal list after the price is agreed, that is a scope change and it is priced as one, in the open, the same way a change to a building’s floor plan is.

What the definition phase looks like

Two weeks, usually. The pod and the client’s domain, risk and engineering people produce the three artefacts and nothing else. No prompts, no orchestration code. The output is a document that a CFO, a CISO and an engineer can all read and agree with, and a price.

The two weeks pay for themselves in a way that is easy to underestimate. More often than not, the definition phase changes the project. The refusal list turns out to exclude the cases that were driving the business case, so the scope moves. The evaluation set reveals that the data needed to judge the agent does not exist yet, so the first deliverable becomes the data. The budget conversation shows that the agent would cost more per case than the people it was meant to help, so the target becomes a narrower, higher-value slice. Every one of those is cheaper to learn in week two than in month six, and every one of them is a discovery that hourly billing would have monetised rather than surfaced.

What fixed price does to the engineering

A fixed price changes how the pod builds. It cannot afford an architecture that needs constant tuning, so it puts refusals in code rather than in prompts. It cannot afford to discover the budget was wrong in month two, so it routes cases to the cheapest model that passes the evaluation set and reserves the expensive one for the hard slice. It cannot afford a handover that takes three months, so the runbook, the trace viewer and the kill switch are built early, because they are deliverables, not extras.

In other words, fixed price produces the same system the production-grade tests describe, for commercial reasons rather than philosophical ones. I find that reassuring. A delivery model that only works when everyone is virtuous is not a model.

How to read a fixed-price quote

Not every fixed price is the kind I am describing. Some are hourly estimates with a margin on top and a change-request clause that reopens the price at the first surprise. Three things tell them apart.

The quote references the artefacts. A real fixed price names the evaluation set, the pass rate, the refusal list and the budget it was priced against. If the quote describes features instead (“an AI assistant that handles customer queries”), it was priced on a feeling and will be re-priced on a fact.

The definition phase is separate and paid. A vendor who gives you a fixed price before the definition phase has either done this exact agent before or is guessing. Ask which.

The handover is in scope. Runbook, kill switch, trace tooling, evaluation set: if these are listed as deliverables, the vendor expects the agent to run without them. If they are listed as a support tier, the vendor expects you to keep paying.

None of this is specific to Ailoitte. It is what a fixed price for an agent has to contain to be fixed, from anyone, and it is worth asking for even if the vendor is your own engineering team.

Where fixed price does not work

Two places, honestly. Research, where the outcome is knowledge rather than a system; that should be scoped as a short time-boxed study with a written question, and billed as one. And any project where the client cannot or will not produce the three artefacts. A buyer who cannot say what the agent must refuse is not ready to buy an agent, at any price, from anyone.

If you are doing this in your company

If you are buying: ask the vendor to give you a price after a paid two-week definition phase, and to show you the three artefacts that the price is based on. If they cannot produce the artefacts, the price is a guess and the risk is yours.

If you are building in-house: run the definition phase anyway. Give your own team a fixed budget and a fixed outcome for the first agent, written down as an evaluation set, a refusal list and a run budget. The discipline is the point, and it is free.

If you want to see the model from the inside, the work with me page describes how an engagement starts, and the vendor evaluation playbook has the questions to ask anyone, including us.