Don't Buy AI. Buy Outcomes.

Somewhere right now, a procurement team is writing a requirements document that names a specific AI model. By the time the contract is signed, that model will have been superseded twice. By the time the system ships, the named version may be scheduled for deprecation.

This is not a niche mistake. It is the default way organisations are buying AI in 2026: shopping for model brands the way they once shopped for database licences. And it produces the predictable result — systems specified around a component that was always going to be swapped, bought from whoever said the fashionable name most confidently.

Our position, as a company that builds these systems: stop buying AI. Buy outcomes, under constraints, with evidence. The model is a part. You are buying a machine.

The RFP that names a model is already obsolete

Frontier models now turn over on a cadence of months. Prices drop, capabilities jump, yesterday's benchmark winner becomes today's mid-tier option. Any document that hard-codes a model name has embedded a depreciation schedule into its own requirements.

But the deeper problem is not staleness. It is that model choice was never the decision that determines whether you get value. We have seen impressive models wrapped in careless systems fail in production, and modest models wrapped in disciplined systems quietly run whole workflows. The difference was never the logo. It was the system around it: retrieval quality, guardrails, integration depth, failure handling, evaluation. That is the machine you are actually buying — the thing we mean by agentic systems.

Specifying the model is like chartering a flight by dictating the engine manufacturer, while leaving the destination, the pilot and the safety checks to the vendor's imagination.

What to specify instead: outcomes and constraints

A good agentic procurement document fits on a few pages and contains almost no technology words. It has two sections that do all the work.

Outcomes — observable, testable, owned:

• What the system must produce: "first-draft proposals from our template and past-proposal archive, in under an hour, factually consistent with source documents."
• The quality bar and how it is measured: acceptance tests on real historical cases, not vendor demos on curated ones.
• The human gate: who approves what, and what the system may do without approval (usually: nothing external).

Constraints — the non-negotiables:

• Data boundaries. What may leave your environment, what must not, where embeddings live, who can audit.
• Cost ceilings. Cost per interaction or per outcome at target volume — not just licence price.
• Escalation behaviour. What happens on low confidence: silence, guess, or hand to a human? (Only one of those answers is acceptable.)
• Observability. Every action logged, every output traceable to its sources.
• Exit. Your prompts, your workflows, your data, your evals — portable at termination. If the vendor flinches here, you have learned something important early.

Specify the destination and the guardrails. Let the builder choose the engine — and make them contractually responsible for swapping it when a better one exists.

Notice what this does: it converts model churn from your risk into your advantage. When the underlying models improve — they will, quarterly — a system bought on outcomes gets better under the same contract.

Ten questions that separate builders from resellers

Use these in the vendor conversation. They are not gotchas; a real builder enjoys them.

1. Show me your evaluation harness. How will we both know the system still works next quarter?
2. What happens, step by step, when the model returns nonsense?
3. What happens when the model provider deprecates the version you shipped on?
4. Which parts of the system are deterministic code, and which are model judgment? Why that split?
5. How does the system behave at ten times the demo volume?
6. Where does our data go, exactly — and what is retained after we leave?
7. What does the human approval flow look like at 6 p.m. on a Friday?
8. What is the cost per outcome at our volume, worst case?
9. Which failure in production are you most proud of handling? (Builders have stories. Resellers have slides.)
10. What will you refuse to automate for us, and why?

The pattern behind all ten: production evidence over demonstration charisma. The gap between the two is the entire subject of The Demo-to-Production Chasm, and why the wrong vendor class keeps winning deals is the subject of Why Your Integrator Can't Build Agents.

Why this is harder than it sounds

Outcome-based buying demands something uncomfortable from the buyer: you have to actually define the outcome. "We want AI in customer service" is a wish. "Sixty percent of tier-one tickets resolved without human touch, measured on last quarter's real tickets, with escalation on anything involving money or anger" is a specification. The vendor cannot do this part for you — and a vendor who offers to is selling you your own homework, marked generously.

It also demands honesty about constraints. If legal will never allow customer data in a third-party model, that belongs in the document on day one, not in month four. Constraints discovered late are how AI projects die quietly.

There is a bonus for European buyers: funded innovation programmes already think this way. Grant applications ask for measurable outcomes, milestones and verification — so an outcome-specified AI project is halfway to being a fundable one. If you are going to write acceptance criteria anyway, you might as well let public funding pay for part of the build — Portuguese and EU instruments commonly co-finance 45–75% of eligible costs on qualifying projects, which turns a €60k build at 60% into ≈€24k net.

What this looks like in practice

House rule as always: no invented clients, no fictional metrics. Our own operation, and an archetype.

How we scope engagements. Every Gravitnomad project starts with an outcome definition and acceptance tests before architecture is discussed — because we would rather lose a deal at the specification stage than win a vague one. Our own systems are built model-agnostic on principle: the publishing hub that turns one brief into blog, LinkedIn and Facebook posts runs on deterministic rails with model calls at judgment points, so swapping the model under it is a configuration change, not a rebuild. The multi-tenant engine rendering this website treats generation and rendering as separate layers for the same reason. Rails first, engines swappable — the philosophy we unpack in Determinism Is a Feature.

The archetype: an SME buying a support agent. The outcome-based version of that purchase specifies deflection rate on historical tickets, tone constraints, escalation triggers, cost per resolved ticket, and a monthly eval report — and never mentions a model name. Three vendors respond. The one who asks for your ticket archive to build the acceptance tests before quoting? That one is a builder.

The pilot, structured properly

"Let us start with a pilot" sounds prudent, and most pilots are structured to prove absolutely nothing. Vendor-curated data, no acceptance criteria, no volume, and at the end a demo everyone claps for — followed by a production project that behaves like a stranger. The pilot was theatre; the applause was the deliverable.

A pilot worth running has five properties. Real historical data — your ugliest quarter, not a sanitised sample. Acceptance tests agreed before it starts — pass marks defined by you, on cases you chose. A price — free pilots select for vendors selling hope on their own balance sheet; a paid pilot selects for builders who expect to be measured. A fixed window — six to eight weeks; anything longer is a project wearing a pilot's badge. Portable artifacts — the eval suite, the workflow definitions and the findings are yours at the end, whichever vendor you pick for the real build.

Structured that way, even a failed pilot is cheap information: you learn where your data is weaker than you thought, which constraints bite, and what the outcome specification should have said. Structured the usual way, a successful pilot is expensive noise. Buy information, not applause.

The checklist

Before your next AI purchase, one page: the outcome in numbers; the acceptance tests and who runs them; data boundaries; cost per outcome at volume; escalation and approval gates; observability; exit terms; model-swap responsibility. If a proposal cannot answer the page, the proposal is marketing. And for calibration while you read the quotes: a focused automation of one workflow, production-hardened, typically runs 4–8 weeks and €18k–45k; an agentic system with retrieval over your company knowledge, 6–12 weeks and €30k–70k; ongoing evolution, €2k–6k a month. A quote far outside those shapes is not necessarily wrong — but it owes you an explanation.

We are happy to pressure-test an outcome specification before you send it to anyone — including before you send it to us. Get in touch; bring the wish, and we will help you turn it into a specification a builder can be held to.