LLMs, agents and assistants from the team that already builds and runs your product. The model ships inside the roadmap, not beside it.
Nothing here is a pilot we hand over. The people who build it stay on it, through the first ugly week and every release after.
AI map
Most AI projects stall at the same point. The demo works, but no one can say what it costs to run, who maintains it outside office hours, or how it behaves when the model returns a bad answer.
We treat model work as product work: same discovery, same reviews, same release process as everything else we ship. Select a line on the left — every one of them is work we do in house.
Retrieval, prompting and evaluation — the unglamorous parts that decide whether an answer is any good, and the only parts that tell you when it stops being good.
Agents that take actions inside your tools, inside limits you set in advance. Support and sales assistants that hand off to a person instead of guessing. And classical models where the pattern is real but no rule can describe it.
Sector context is most of the work. The same retrieval pipeline is a compliance problem in one industry and a latency problem in another.
The model is rarely what separates the two. What separates them is knowing which failure the business cannot absorb.
The tooling, review rules and guardrails our engineers work inside every day. A short review that names what to build first — and what not to build at all.
And what the tooling saves, measured on real delivery rather than taken from a vendor presentation.
We will not put a model in front of a decision you cannot afford to get wrong without a human in the loop. We will not ship a feature we cannot evaluate.
And we will not call something AI when a database query would answer it faster, cheaper and correctly every time.
Usually with an existing product. AI features land on top of a codebase, a data model and a support team that already exist.
Which is why this sits beside the product and platform work rather than in a separate lab down the corridor.
The map above is what we build. What follows is how a model project actually runs here — the tests an idea has to survive before it becomes a feature, and who owns the thing once it is live.
Every idea gets the same first test: would a query, a rule or a lookup table answer this? If it would, we say so, and the feature does not become a model. That answer has cost us work and it has never cost us a client.
When a rule genuinely cannot do the job — ranking, forecasting, anything where the pattern is real but nobody can write it down — that is how we run machine learning work instead.
A demo proves a model produced one good answer. It says nothing about the next thousand. So every feature carries a set of real questions with graded answers, built from your own material, and that set runs on every change. It belongs to you, not to us.
It is the only honest way to claim a change made something better, and it is what keeps language-model features maintainable a year after launch. Same discipline as the rest of our QA and testing work — the subject is just harder to pin down.
Model choice, context length, caching and routing each move two numbers: the monthly bill and the time a user spends waiting. We size those against the job during the build, not after the first invoice. A cheap model with good retrieval usually beats an expensive one reading a long context badly.
Every AI feature leaves with a cost model and a runbook for the day the provider deprecates something or the latency doubles overnight. Keeping it alive after that is the same retainer that covers the rest of your product.
Before a line is written we put the data path in writing: which provider sees what, whether anything is retained on their side, what is stripped before it leaves your systems, and which parts never leave at all. On regulated work that document arrives before the design, not after it.
Sector context decides most of the answer. The same retrieval pipeline is a compliance problem in financial services and a latency problem in freight and logistics.
Start with the AI readiness assessment. It is a short, fixed engagement and it ends with a written plan rather than a pitch: the first thing worth building, the thing to leave alone for now, and what either would cost to run once the demo is over.
Model work is one column of what we do, not a department off to the side. The services map has the whole of it, and technologies lists what any of it actually runs on.
Tell us what you want to build or improve. We reply with a plan, an indicative budget and a start date.