Buying · 8 min read · Aug 19, 2026
Twelve questions. Four of them decide it.
A demo proves that someone can build a demo. These are the questions that tell you whether a system will still be working, and still be yours, in the second year — including the four most vendors would rather you did not ask.
Why the demo tells you almost nothing
Every vendor in this market can show you something impressive in forty minutes. The hard parts of this work are invisible in a demo: reconciling to a number an outlet manager already believes, the one legacy system with no API, the process that has to keep running when a model provider changes its pricing. None of that shows up on screen.
So the useful questions are not about capability. They are about what happens after the excitement — who owns the result, what it costs to keep alive, and what the vendor does on the day it gets something wrong.
The four that decide it
If you only ask four, ask these. Each has a specific, checkable answer, and vagueness on any of them is itself the answer.
- What do we own at the end, exactly? The source code, the repository, the cloud accounts, the model API keys, the data. Get the list written into the contract rather than described warmly on a call. "You own your data" is not the same as owning the system that produces it.
- What does it cost to run each month at our volume? Not the build price. Inference, infrastructure and integration, sized against your actual transaction volume, with the growth curve for each. A vendor who cannot answer has either not run at your scale or would rather you found out after signature.
- What happens when it gets something wrong? Ask for the specific mechanism: what is held back for review, what is logged, who is alerted, and which actions the system is never allowed to take on its own.
- Who builds it, and are they still here in month nine? Named people, not a capability deck. Ask what the maintenance arrangement is once the build team rolls off, and what it costs.
The pattern worth noticing: all four are about the second year. Vendors optimise their answers for the first, because that is when the decision gets made.
The rest of the list
| Ask | What a real answer sounds like |
|---|---|
| Have you integrated a system like our oldest one? | A named system, how it was ingested, and what the fallback was — usually a local sync agent or batch export, not an API |
| What did you get wrong on your last project? | A specific technical wrong turn and what it cost to unwind. Nobody who has shipped has a clean answer here |
| Can we talk to a client running this in production? | A reference on a system that is 12 months old, not one that launched last month |
| What is the pilot, and what would make you stop? | A single entity, a defined success test, and a stated point at which the plan changes |
| Which model do you use, and what happens when it changes? | Model as configuration per task, at least two vendors, no model identifier hard-coded in application code |
| Where does our data sit, and who can read it? | Named region, named tenancy boundary, and whether isolation is enforced by the database or by application code |
| How do you handle our entity structure? | The hierarchy in the data model from day one — outlets to brands to legal entities — not a filter added later |
| What is not included? | A list. Every fixed-price engagement has one, and the ones that claim otherwise settle it in change requests |
Custom build or off-the-shelf?
Worth asking before you shortlist anyone. Buy where the process is identical to your competitors' — invoice capture, document extraction, standard CRM automation are commodity, and a platform-maintained agent will beat a bespoke one on price and reliability. Build only where the advantage depends on your own estate.
A vendor who never recommends buying something has an incentive problem. The reasonable answer to "could we just use an off-the-shelf tool for this?" is sometimes yes, and hearing it once is a good sign.
Contractors, agencies, and who picks up the phone
An independent contractor is usually cheaper per day and carries a single point of failure. An agency costs more and should be buying you continuity, a second pair of eyes on architecture, and someone to call when the person who built it is unavailable. If an agency is not visibly providing those, you are paying agency rates for contractor risk.
Ask directly whether the work is subcontracted, and to whom. It is not disqualifying. Discovering it in month four is.
What ends the conversation
- A refusal to quote running cost before signature.
- Ownership described but not written down.
- A pilot scope that covers every entity at once, because it means nobody intends to be measured on the first one.
- An accuracy claim with no stated way to check it in your own data.
None of these are exotic requirements. They are what Ontilus commits to in scoping calls, and the reason to publish them is that a buyer who asks all twelve gets a better system whoever they end up hiring. The running-cost detail is in what an AI operating system costs to run, and the failure-handling detail is in what happens when an agent gets it wrong.
Dealing with this in your own group?
We answer scoping questions before there's a contract in sight — including the ones about cost and data handling.