Ops note · Model agnosticism

Choosing a model like you choose a supplier.

The least useful AI conversation starts with "which model should we use?" as if it were the first question. The most useful one starts with the job: and treats the model as a swappable supplier for that job.

Three thresholds, in order

For every deployment, we evaluate models against three thresholds, in strict order:

  • Compliance comes first. If a model can't meet your residency, retention or audit requirements, it's out before cost matters. No exceptions.
  • Performance earns its place. Measured on your tasks, against your schema: not on a benchmark leaderboard that has nothing to do with your workflows.
  • Cost is checked last, honestly. Total cost per completed unit of work: including retries and eval: not a headline token price.

Notice what's missing: the vendor relationship. Model selection driven by who happens to be our partner is precisely the failure we were built to avoid.

No lock-in, not even from us. Replacing a model is configuration, not a rewrite.

The interface is the insurance

The reason a model swap stays cheap is that every model sits behind a swappable interface: the same discipline we apply to payments, messaging and every external provider. The agent talks to a contract, not to a vendor's SDK. When the job changes, or a supplier's pricing or latency changes, the swap is a configuration change with a re-evaluation: not a project.

This is not theoretical convenience. It is risk management. An AI layer you cannot leave is one you should not have entered into.

What we optimise, then

Not "the best model." The best model for this use case, at this cost, within these compliance boundaries. Sometimes that's a frontier model; more often it's a smaller, cheaper, faster one that does the scoped job at a tenth of the cost and twice the speed. The requirement wins; the logo doesn't.

In practiceDocumented in every engagement's Design phase: scope, expected return, chosen model and the rationale. Decided together, before a line of code.
Your job, your supplier

Bring us a task.
We'll bring the evaluation.

The design phase compares models against your data and your schema: the answer is evidence, not preference.

Run the comparison