Do you have a project in your
mind? Contact us.
Contact Us
AI implementation and optimisation
AI implementation
Getting a model to do something useful, reliably
We build AI features into products and internal systems, and we fix AI features that already exist but cost more than expected or return answers nobody trusts.
The model is rarely the hard part. Most of the work sits around it: getting the right context in front of it, deciding what happens when it is wrong, and being able to measure whether a change made things better or worse.
Building something new
There is usually a specific job inside a business that a language model can do well: sorting inbound email by intent, pulling structured fields out of invoices and PDFs, answering questions against your own documentation, or drafting a first version of a reply that a person then edits.
We build that job into the systems you already run, connect it to wherever the data actually lives, and put checks around it so failures are visible rather than silent.
Improving something that already runs
A feature shipped and it mostly works. The monthly bill is higher than anyone forecast, or it produces confident wrong answers often enough that your team has quietly stopped relying on it.
We start by measuring quality against a fixed set of real examples, because without that any change is guesswork. The fixes from there are usually unglamorous: retrieval that puts the right context in front of the model, a smaller model for the easy cases, caching repeated calls, narrowing what the feature claims to do, and adding a path for the questions it should decline to answer.
Tools and systems
What we work with
Models
Retrieval and storage
Evaluation and monitoring
Systems we connect to
What to expect
How a project runs
Scoping
We agree what the feature has to do, what a good answer looks like, and what should happen when the model cannot produce one. Most of the risk in an AI project is removed here, and this is the stage clients most often expect to skip.
Data and access
We map where the content lives, what condition it is in, and what is allowed to leave your infrastructure. This takes longer than people expect, usually because the same customer exists under three different identifiers in three different systems.
A baseline you can measure
Before building, we assemble a set of real inputs alongside the outputs you would accept as correct. Every change after this point is measured against that set.
Deciding the business logic
What the model is allowed to decide on its own, what needs a person to approve it, and where the boundary sits. This is a business decision rather than a technical one, and it belongs to you. We make sure it gets made explicitly instead of being settled by default.
Build
Retrieval, prompts, tool calls, and the application code around them. From the outside this looks like the whole project. It is rarely the longest part.
Evaluation
We run the test set on every change and compare results, rather than judging quality by how the output reads on a handful of examples.
Error handling
We decide explicitly what happens on a timeout, a refusal, a malformed response, or an answer the system is not confident about. These paths get built and tested rather than left to whatever the framework does by default.
Handover
You get written documentation, the evaluation set and instructions for running it, cost reporting, and an explanation of how to change a prompt without breaking the checks. If you want to take the work in house afterwards, that is a reasonable outcome and we will set it up for that.
Reducing what AI costs to run
AI cost optimisation
Most teams meet the bill after the feature ships. A prompt that looked inexpensive while it was being tested turns out to run constantly, or a retry loop quietly doubles the spend. Reducing it is usually straightforward once someone measures where the money actually goes.
- Measure first. Cost per request, broken down by feature, before anything is changed. Savings claimed without a baseline are guesses.
- Model routing. The straightforward cases go to a smaller and cheaper model, and the expensive one is kept for the requests that genuinely need it.
- Caching. Repeated and near identical requests should not be paid for twice.
- Context trimming. Most prompts carry more context than the answer needs, and every token of it is billed on the way in.
- Batching and scheduling. Work that nobody is waiting on can run in cheaper ways than work that blocks a person.
- Budgets and alerts. A hard ceiling per feature, so a loop cannot run up a bill overnight before anyone notices.
The cheapest AI is sometimes none
When a model is the wrong tool
Some of what we get asked to build with a language model would work better as a database query, a set of rules, or a regular expression. Those cost a fraction as much to run and they return the same answer every time.
We say so when that is the case, before you have committed to a build.
Scope
When you should not hire us
- If you want a chat assistant on your public website that answers from pages you have already published, buy one of the products built for that. It will be running this week and a custom build will not.
- If the capability already exists in your CRM or helpdesk, use it. We would rather point you at it than build a second version of something you are paying for.
- We do not train foundation models, and we do not write AI strategy documents. We build features that run in production, and we maintain them if you want us to.
Where enquiries usually go next
Related work
Automation and integration
Most AI work arrives attached to a process that is still being done by hand. If the goal is to remove the manual step rather than add a model, start here.
See what this coversCustom apps and software
When the feature needs an interface, a workflow and a database around it rather than a model bolted onto something existing.
See what this covers