Systems integration
Not every problem needs a model. Some need a lookup table
The question has shifted from whether AI can do something to whether it can run at scale, on a budget, without falling over. Cost now scales with adoption rather than with the value being created.
Executive summary
5
moves for teams past the pilot stage, in order
Core conclusions
- A meaningful share of what gets routed to a model is deterministic — a mapping, a threshold, a rules table — and sending it to a model buys nothing while billing per call.
- Route by difficulty, add failover so an outage shifts traffic automatically, and centralise governance in one layer rather than per integration.
- Track cost per completed task, not cost per call — and ask any integrator, including this one, what in scope they recommend not automating yet.
For a period the story was speed: ship the pilot, plug in the frontier model, show the demo. That phase is ending, and what replaces it is a less glamorous question about unit economics.
A meaningful proportion of what gets routed to a model is deterministic. A mapping, a threshold, a rules table. Those have a fixed cost, a predictable latency, and an answer you can explain in a sentence. Sending them to a model buys nothing and bills per call.
Moves for teams past the pilot stage
- Audit what is actually being sent to a model, and move anything deterministic back to code.
- Route by difficulty: a small model or a rule for the common case, the expensive one for the residue.
- Build in failover, so an outage or latency spike at one provider shifts traffic automatically rather than manually.
- Centralise governance in one layer — rate limits, cost tracking, data controls — instead of per-integration.
- Track cost per completed task, not cost per call, so the number reflects work done.
This is one of the four questions we suggest asking any integrator, including us: what in this scope do you recommend we do not automate yet? An integrator with nothing on that list has not looked closely at the problem.
