Fixed-Price vs Time-and-Materials for Agent Builds

Most buyers ask which pricing model is "safer" for an agent build, then pick fixed-price because it produces a single number a finance committee can approve. That instinct is understandable and often wrong. The pricing model is not a safety device. It is a way of assigning who eats the cost when the parts of the build nobody could estimate turn out to be expensive — and on an agent project, those parts are rarely the model or the prompt. They are the integrations, the evaluation harness, the approval routing, and the operational grind of getting a non-deterministic system to behave the same way twice.

You have already decided to outsource the build. This piece is about the contract shape. The short version: fixed-price rewards you when the unknowns are small and named, and punishes you when they are not; time-and-materials does the opposite. The rest is picking which one your specific pilot actually is, and writing the clauses that keep either model honest.

What Each Model Actually Buys You

A fixed-price contract is a bet the vendor makes on their own estimate. Fixed-price contracts lock in a set fee for defined deliverables, shifting scope risk to the provider, which sounds like a gift until you notice what the provider does to protect that bet. They pad. Industry commentary puts the typical risk premium on fixed-price software work at 15 to 30 percent, and every ambiguous requirement in the SOW gets priced at the worst plausible interpretation. If the project runs clean, you paid for risk that did not materialize.

Time-and-materials inverts the burden. T&M bills for actual hours and expenses, shifting cost risk to the client, so the vendor has no reason to pad and every reason to discover the real shape of the problem before committing to a solution. The tradeoff is obvious: your finance team gets a range instead of a number, and your governance discipline has to be real, because nobody is protecting the budget for you.

Neither model is inherently more expensive. A 2017 study in the International Journal of Project Management found fixed-price contracts connected with a higher risk of project failure compared to T&M, largely because the incentive to defend the fixed number can override the incentive to build the right thing. That should not be read as "always pick T&M." It should be read as: the model that looks safer to procurement is often the one that quietly kills the project.

The Unknowns That Decide the Model

Agent builds fail estimation for reasons traditional software builds do not. Enterprises typically underestimate total cost of ownership for AI agent projects by 40 to 60 percent, and integration with existing systems by 30 to 50 percent. Those overruns cluster around a handful of specific unknowns. Before you pick a contract shape, price each of these on your own project, honestly:

• Tool surface. How many systems does the agent read from and write to, and do you already have stable, documented APIs for each? Every undocumented endpoint is a T&M line item pretending to be a fixed-price deliverable.
• Evaluation set. Do you have a labeled corpus of realistic tasks the agent will be graded on, or will the vendor have to build one? If the latter, nobody knows what "done" means yet.
• Approval topology. Which actions require a human in the loop, at what dollar threshold, and who signs? If this is undecided, the workflow itself is undecided.
• Data access. Are the required datasets already accessible from the environment where the agent will run, with the right entitlements? Access negotiations routinely take longer than the build.
• Baseline metrics. Do you know the current human cost per task, error rate, and cycle time? Without a baseline, no acceptance criterion is defensible, and the pilot cannot pay for itself on paper.

If four or five of those are answered concretely, fixed-price is legitimate. If two or fewer are, a fixed-price SOW is a fiction that both sides will spend the engagement renegotiating. Mayer Brown's contract lawyers put it plainly: if the desired end results aren't defined clearly and accurately, the parties may spend the project negotiating change orders. Change orders on fixed-price work are not free. Standish Group data indicates they average 15 to 25 percent of the original contract value, and they arrive on the vendor's timetable, not yours.

Why Duration Matters More Than Complexity

The single strongest predictor of overrun is not complexity but calendar length. McKinsey's large-project study found that every additional year on the project increases cost overruns by roughly 15 percent. Software results at large are not encouraging either. The Standish Group's CHAOS 2020 report classified 31 percent of projects as successful, 50 percent as challenged, and 19 percent as failed outright.

The implication for agent work is direct. A four-to-six-week pilot with a narrow scope can survive a fixed-price contract because the estimate window is short enough that the vendor's padding is bounded and the unknowns cannot compound. A six-month "agent platform" build under fixed price is a different animal. The model of the world you signed against in month one will not survive month three, and the change-order machinery becomes the project.

A useful heuristic: if your engagement is longer than about eight weeks, either break it into fixed-price phases with independent acceptance gates, or run it as T&M with a not-to-exceed cap. A single fixed price stretched across a quarter is the shape that reliably produces the outcomes IDC keeps measuring.

Clauses to Insist On, Whichever Model You Pick

The contract shape matters less than the clauses inside it. The following are the ones that separate a pilot that pays back from a pilot that becomes a permanent line item. None are exotic; most are missing from the SOWs that come across a CIO's desk.

• Evaluation-gated milestones. Payments trigger when the agent passes a pre-agreed evaluation set on realistic tasks, not when a calendar date arrives. The set is written into the SOW before build starts, with pass thresholds and a defined rerun procedure on failure. This is the single most effective clause you can add.
• A not-to-exceed cap on T&M. The cap is the discipline. Pair it with a written protocol for what happens as spend approaches the cap: mandatory review, scope trim, or explicit extension. Without that protocol, the cap is theater.
• Change control with a response SLA. Every change request is priced and answered within a defined window, and no work starts without a signed addendum. This is the clause that keeps fixed-price projects from becoming ad-hoc T&M projects at fixed-price margins.
• Explicit IP assignment on everything. Prompts, evaluation sets, connectors, orchestration code, and the agent's configuration all transfer to you on payment. Some vendors retain reusable components by default, which creates dependency if the buyer ever wants to modify or extend the agent without rehiring the original vendor.
• Model-change handling. The provider you build against will deprecate or update the model you shipped on. The SOW should state who reruns acceptance on the replacement model and how those hours are priced during the support period.
• Approval-gate design as a deliverable. The mapping of which actions require human sign-off is a first-class artifact, not an afterthought. Our note on which agent actions need human approval is a useful starting frame; the design itself belongs in the SOW.
• Exit ramps at each milestone. You can terminate at any gate, take delivery of what has been built and paid for, and receive documented handover. Without exit ramps, the vendor's leverage grows every week.

Two of those — evaluation gates and exit ramps — matter regardless of pricing model. The rest are the ones that keep a fixed-price contract from turning into an argument or a T&M contract from turning into a subscription. If you want a deeper look at how the underlying build should be shaped before you sign anything, our AI agent architecture practice covers the pre-contract work that makes either model estimable.

Picking, Concretely

Fixed-price is the right call when the workflow is narrow, the integrations are one or two systems you already own, the evaluation set exists, and the engagement is under about eight weeks. In that window, the vendor's padding is small, the change-order surface is small, and you get budget certainty without paying much for it. A discovery sprint that produces the evaluation set and the integration inventory is a reasonable fixed-price prelude even when the build itself will be T&M.

Time-and-materials is the right call when the workflow crosses more than two systems, when the tool surface includes anything undocumented, when the approval topology is still being negotiated, or when the pilot is genuinely exploratory. A capped T&M engagement with weekly burn reporting, evaluation gates every two weeks, and a documented exit ramp is not a looser contract than fixed-price; it is a tighter one, because the governance is continuous instead of front-loaded into an estimate that was wrong on day one. IDC's finding that 67 percent of enterprises exceeded their AI agent spend budgets by more than 10 percent is not a T&M problem or a fixed-price problem. It is a governance problem, and the contract shape is only the first place it shows up.

Before you sign either, run the unknowns list. If the answers are honest and most of them are green, take the fixed price and the padding that comes with it. If they are not, take the T&M and the discipline that comes with it. What you should not do is sign a fixed price against a scope you cannot yet describe, or sign an uncapped T&M against a workflow you have not tried to bound. Both are the same mistake in different packaging: pretending the unknowns are somebody else's problem. On an agent build, they are yours until the workflow runs, and the contract is only useful to the extent it says so.