How to Price a Fixed-Scope Agent Build vs an Hourly One

Both structures have a real incentive story, and the incentive matters more than the headline number.

A fixed-price agreement defines a scope of work with the client and delivers that exact scope for an agreed price, which gives budget predictability and scheduled milestone payments (SOLTECH). The vendor carries the delivery risk and prices that risk in. The vendor's incentive becomes defending the letter of the specification, because every deviation eats margin, and once the specification is fixed, new ideas rarely get incorporated (Atomic Object). That is not malice. It is the contract working as written.

A time-and-materials agreement bills actual hours at agreed rates. There is no risk premium because there is no fixed promise, and the risk of unknowns sits with you. In exchange you get adaptability: changing direction mid-build is a conversation rather than a contract amendment (VeryCreatives). What you need in return is transparent reporting and the discipline to manage scope yourself, because nothing in the contract will do it for you.

The comparison most bids stop at is predictability versus flexibility. The comparison that decides your outcome is the incentive row. Pick the alignment you want, because you will get the behavior you paid for.

Run a short test on the build itself before you compare quotes. The test is about what you know, not what you want.

Use fixed price when the tool list is closed and each API is documented, you already have a labeled evaluation set or can build one before the build starts, the data sits in a system your team controls, the workflow boundary is one team's queue, and you can name the approvers at each release gate. That is a bounded build, and a fixed bid is honest. Expect the vendor to add a risk factor for unknowns, because a provider that commits to a price on an unclear scope will add padding to protect itself (SOLTECH).

Use time and materials when you do not yet know which tools the agent must call, the retrieval corpus is being cleaned or migrated, the evaluation set does not exist, or the business owner cannot yet say what good looks like. These are the cases where the final destination is clear and the path is not, which is where a pay-for-actual-effort model fits (Faberwork).

Neither structure prevents scope creep, so the third option matters. The hybrid fixes a time-boxed discovery phase with a deliverable (a written scope, an evaluation set and a priced build estimate), then converts to fixed price for the build, with a named change-order rate for anything outside the criteria. Some firms run a close variant they call fixed-budget, scope-controlled (Atomic Object). The CTO-side version of the same move is fixed-scope phases with re-scoping gates between them (VeryCreatives).

The rule that keeps hybrids from becoming mush is the two-of-three rule. Fix budget and time for discovery, then fix scope and budget for the build. Trying to fix all three at once is how fixed-price projects turn adversarial.

Most bad fixed bids are not overpriced. They are under-specified, and the missing line items reappear later as change orders. Before you sign, check for these.

• Discovery, separately billed and capped. A scoping workshop or a short paid phase that produces the acceptance criteria. A fixed bid on a vague scope is a risk premium on top of a guess, which is why a scoping workshop should come first (VeryCreatives).
• Numbered acceptance criteria with thresholds and a dataset. Include the evaluation set, its size, and who owns labeling it. Then name the approver per criterion.
• Named tools and endpoints, plus an exclusion list. Unnamed adjacency becomes implied scope by month three.
• Client obligations with dates. Data access, credentials, firewall exceptions, and the named owner on your side for each.
• Revisions, in rounds. A contract should state the expectation for revisions along with a set number of rounds for rework, because unlimited fixes is not a price (Indeed).
• Monitoring and observability. Logging, trace capture, and a written definition of a regression. Without it, every post-launch behavior change becomes an argument.
• Handover. Documentation and a walkthrough, priced in, because a contractor who finishes without documenting leaves the internal team with an expensive knowledge gap (Dataworks).
• A named change-order rate. A figure, not a range, plus the turn-around for pricing a change.

For a checkable version of the acceptance block, write it into the statement of work like this:

AC-1 Tool selection: for 50 golden tickets, the agent calls
     the correct help-desk endpoint first in >= 90% of runs.
     Dataset: evalset_v3 (owner: support-ops). Approver: VP Support.
AC-2 Retrieval: answer grounded in retrieved passages in 100%
     of runs, zero answers from parametric memory.
AC-3 Escalation: tickets above the refund threshold route to a
     human with the reason recorded.
Exclusions: billing disputes, EU queue, voice channel.
Client obligations: read-only CRM token by week 1; labeled set by week 2.
Change-order rate: rate card line B, priced within 3 business days.

If a bid cannot survive that template, it is not a fixed bid. It is a number with a date.

Hourly work shifts the review from whether the price is fair to whether the estimate is honest. Read the rate card first.

Look for blended versus role-based rates. A single blended rate hides whether senior work is billed at a senior price, and it usually means the plan treats junior and senior as interchangeable, which they are not. Contract rates usually sit above the salary-equivalent hourly rate because the contractor prices in flexibility, gaps between assignments, insurance, administration and the absence of employee benefits (Dataworks). A rate card that pretends otherwise is hiding overhead somewhere.

Then read the hours estimate as a distribution, not a number. Ask for three figures per workstream: optimistic, expected and pessimistic. A single number with a confident decimal is a tell.

Worked example. Suppose a build is quoted at 240 hours and your review finds the estimate excludes evaluation-set construction (about 30 hours), observability setup (about 16 hours) and two rework rounds (about 24 hours). The honest expected case is closer to 310 hours, with a pessimistic case around 380 if the corpus needs re-chunking. Under time and materials at a stated rate, that band is your exposure. Under a fixed price, the vendor has read the same gaps and padded for them, which is why the fixed quote often lands above the sum of the estimated hours. Both are rational. You are choosing which one you would rather see.

The review checklist:

1. Are rates role-based, and does the staffing plan match the rates?
2. Does the estimate carry a range per workstream?
3. Are evaluation, monitoring, documentation and rework inside the hours or explicitly outside?
4. What is the weekly burn report cadence, and who signs it?
5. Is there a written cap, and what happens when it is reached?

The structure that limits disputes has four parts, and each one closes a specific failure mode.

1. Capped discovery. A short paid phase, capped in hours and dollars, whose deliverable is the scope document, the acceptance tests and a build estimate with a range. Cap it because discovery without a ceiling is time and materials with a nicer name. Bill it separately so the build quote rests on something you have read.

2. A fixed build against numbered criteria. The build is fixed price, and the price attaches to acceptance tests rather than features. The vendor now has an incentive to hit the tests, because the tests define margin.

3. A named change-order rate and an assumptions list. Any request outside the criteria gets priced at a rate both parties already agreed, within a stated turn-around. The assumptions list is the mirror image: the vendor writes down what it assumed, so an assumption that turns out false becomes a priced conversation rather than a fight.

4. A written cap and a weekly burn report for anything open-ended. If you go hourly for the discovery phase or for a genuinely unknown workstream, cap it. A cap converts an open bill into a maximum, and a weekly burn report against the cap gives you the chance to stop early. Time and materials is not a blank check; it succeeds on active collaboration and reporting (Faberwork).

One caveat worth writing down. The label on the contract does not decide how a worker is classified. In the United States, classification turns on behavioral control, financial control and the nature of the relationship, not the job title or the agreement's heading (IRS). The Department of Labor is explicit that receiving a 1099 form does not make someone a contractor, and that signing an independent contractor agreement does not either (DOL). A long engagement where you set the hours and direct the method can look like employment whatever the invoice says, and the key difference the agencies weigh is control and independence (Gusto). Keep the vendor's methods theirs, and keep the deliverable the thing you judge.

If you would rather keep scope discussions in-house and have a specialist build against the acceptance criteria you approve, that is what Quanta does: describe the site, app, document or plan and a specialist picks it up with you (https://quantaintelligence.ai/). If the agent's model layer is still being chosen when you scope, one API key across text, image and embedding models shortens the build-side list and makes it easier to price (https://quantaintelligence.ai/inference).