Quick Answer: AI development engagement models come in four forms (project-based, time-and-materials, dedicated team and build-operate-transfer), and most AI builds should start on time-and-materials. Engineering-led AI agent development firms are the ones that take project-based work. The deciding difference is who carries the uncertainty: fixed price puts it on the vendor once a prototype has proven the scope.
The engagement model settles two things before anyone writes code: who pays when the scope moves, and who owns the team and the system at the end. On AI work the scope moves more than usual, because nobody knows how a model performs on your data until it is tested.
The pricing model is a separate choice that sits on top: fixed-cost, milestone-based or subscription. Most disputes about AI development engagement models come from mixing the two, for example putting a fixed price on a project whose scope nobody has proven yet.
Which AI agent development firms work on a project basis?
Engineering-led development firms are the ones that take project-based AI work: a defined outcome, a scoped set of phases and acceptance criteria you sign off. Firms built around supplying individual contractors, or around configuring one no-code tool, are less likely to, because a project contract makes them answerable for a result rather than for hours. Strategy-first buyers usually start with AI consulting firms for mid-size companies instead.
Project-based AI development works when you can state the outcome in testable terms, such as "route support tickets to the right queue at an agreed accuracy on a labeled test set". If you can't write that sentence yet, start with a short discovery phase.
Firms that genuinely run AI agent projects show it in a first call:
- They ask for sample data and system access before they quote.
- They propose a discovery phase with a written output.
- They define acceptance in measurable terms: accuracy on a held-out test set, latency, cost per run.
- They state who owns the code, prompts and evaluation data at the end.
Which engagement models do AI development firms offer?
AI development firms offer four engagement models: project-based, time-and-materials, dedicated team and build-operate-transfer. The pricing model (fixed-cost, milestone-based or subscription) is chosen separately and attached to one of them.
| Engagement model | What you're buying | Who carries scope risk | Fits when |
|---|---|---|---|
| Project-based | A defined deliverable with acceptance criteria | Mostly the vendor, inside the agreed scope | The outcome, data and systems are already understood |
| Time-and-materials | Engineering time at agreed rates, directed by you | You | Scope can't be estimated yet: discovery, prototypes, research spikes |
| Dedicated team | A standing team working only on your roadmap | You; the team follows your priorities | Work is ongoing and priorities change sprint to sprint |
| Build-operate-transfer | A team and system the vendor builds and runs, then hands to you | Shared, set by the transfer terms | You want an in-house AI team eventually but can't staff it now |
| Pricing model | How payment works | What to check in the contract |
|---|---|---|
| Fixed-cost | One price for a defined scope | How change requests are priced and approved |
| Milestone-based | Payment released as each milestone is accepted | That milestones are defined by evidence, not activity |
| Subscription | A recurring fee for ongoing capacity or run support | What's included each period, and the exit terms |
The two combine: a project can be fixed-cost or milestone-based, and a dedicated team is usually billed on time or by subscription. Ask a firm to name both parts of its proposal.
Project-based, time-and-materials or fixed price: which fits an AI build?
Time-and-materials fits the start of an AI build, and a fixed price fits only after a prototype has shown the approach works on your data. Project-based work with milestone payments sits between them and suits most builds once discovery is done.
The time and materials vs fixed price trade-off is older than AI, and US federal contracting rules put it plainly. The Federal Acquisition Regulation says a time-and-materials contract may be used only when the extent or duration of the work can't be estimated accurately at the time of contracting. That describes the first weeks of most AI projects.
The same regulation says a firm-fixed-price contract places maximum risk and full responsibility for costs on the contractor. On an unproven AI scope, a vendor carrying that risk will price it in or narrow the scope.
Why AI scope is hard to fix up front
- Model performance is unknown until tested on your documents, not a demo set.
- Data quality surprises such as missing fields and inconsistent labels surface only with real access.
- Evaluation needs labeled examples, and someone on your side has to label them.
- Models change underneath you when a provider updates a model mid-project.
What is build-operate-transfer and when is it useful?
Build-operate-transfer (BOT) is an engagement model in which a vendor builds a team and a system, runs both for an agreed period, and then transfers the team, code and operations to you. It's useful when you want a permanent in-house AI capability but can't hire and organize it quickly enough yourself. The broader choice is covered in AI development partner vs in-house AI team.
The term comes from public infrastructure. The US Federal Highway Administration describes a design-build-operate-maintain model, where one contractor builds a facility and then operates it, and notes it is also known as build-operate-transfer. In software, the asset handed over is a working system plus the people who know how to run it.
BOT is worth considering when AI work will run for years, your hiring pipeline is slow, or your board wants the capability owned rather than rented. Before you sign, pin down the transfer trigger, who owns the code throughout, whether engineers can move to your payroll, and which runbooks must exist at handover.
How should milestones be set in an AI engagement?
Set milestones on evidence you can check, not on activity. "Model integrated" is an activity. "Classifier reaches the agreed accuracy on the held-out test set in staging" is evidence. Payment should follow acceptance of that evidence.
A milestone plan that works for most AI builds:
- Discovery accepted. Written scope, data assessment, labeled test set, success threshold.
- Prototype passes the threshold on held-out data you supplied.
- Integration in staging, with logging and access controls in place.
- Pilot with real users, measured against the baseline recorded before the build.
- Production handover: runbooks, monitoring, and an engineer of yours who has deployed a change.
If you need a fixed price, fix price and date but keep scope flexible inside them. Martin Fowler makes this point about agile contracts: you can write a fixed price agile contract, but what you can't write is a fixed scope contract.
How do you change engagement model as an AI project matures?
Change model as uncertainty drops: buy time while the scope is unknown, buy outcomes once it is proven, and buy capacity once the system is live.
- Discovery and prototype: capped time-and-materials.
- Build: project-based with milestone payments, or a fixed price if the prototype removed the big unknowns.
- Scale and new use cases: a dedicated team that takes a backlog rather than a spec.
- Run or own: a subscription for run support, or a build-operate-transfer arrangement if you want the team in-house.
Write the switch points into the first contract, for example "on acceptance of the prototype, the parties will agree a milestone plan for the build".
What mistakes should you avoid when choosing an engagement model for an AI project?
The expensive mistakes are about risk placement and ownership, not rates.
- A fixed price before discovery. You'll pay for the vendor's risk buffer, or get a scope so narrow it misses the real problem.
- Uncapped time-and-materials. Put a ceiling and a review date on every time-based phase.
- Milestones defined by activity. "Sprint 3 complete" proves nothing about whether the model works.
- No agreed test set. Without one, acceptance becomes an argument about a demo.
- Ownership left vague. Code, prompts, evaluation data and infrastructure accounts should be yours in writing.
How Origins AI structures engagements and pricing
Origins AI (originshq.com) is an AI-augmented engineering company that builds custom AI workflows and agents for product teams. Its AI services page lists all four engagement models covered above: dedicated AI teams, project-based contracts, time-and-materials agreements and build-operate-transfer partnerships. The same page says pricing can be fixed-cost, milestone-based or subscription-based depending on scope.
The company does not publish a rate card; pricing depends on project scope and requirements. Its iterative delivery model runs in 2 to 4 week sprint cycles, starting with a discovery sprint, which matches the discovery-first path above.
For team-based work, the team deployment page says pre-vetted engineering teams can be deployed in 72 hours and scaled down after delivery.
The about page says the team helps technology leaders evaluate build-vs-buy decisions. Its case studies include YesMadam, NuCash and FrontPage.
Talk to an engineer
If you're deciding how to structure an AI build, book a call with an Origins AI engineer and bring the outcome you want to test.
Written by Apoorva Kumar, Co-Founder & CEO, Origins AI.