AI Engineering
Most AI projects do not fail at the model. They fail at everything around it — the retrieval that returns the wrong chunk, the evaluation nobody built, the cost curve that only appears at scale. We engineer the parts that decide whether a prototype becomes a product.
The gap between a demo and a system
A working demo takes an afternoon. A system that answers correctly on the four-hundredth question, at a cost you can defend, with a trace you can debug when it goes wrong — that is a different discipline, and it is the one we practise.
We start by writing down what correct means for your use case, because a team that cannot measure quality cannot improve it. That means an evaluation set drawn from real inputs, graded against real expectations, run automatically on every change. Everything else follows from having that in place.
What we build
Retrieval systems
Document pipelines that handle the messy reality of enterprise content — inconsistent formats, tables that matter, permissions that must be respected at query time. We tune chunking and ranking against your evaluation set rather than against defaults.
Agent workflows
Multi-step processes where the model calls tools, checks its work and hands off to a human at defined points. We are deliberate about where autonomy helps and where it introduces risk you would rather not carry.
Evaluation harnesses
Test suites for non-deterministic systems: graded sets, regression detection, and dashboards that show quality moving over time instead of vibes reported in a meeting.
Inference infrastructure
Routing between models by task, caching what repeats, batching what can wait. Cost per request becomes a number you watch and control, not a surprise on the monthly invoice.
Guardrails and review
Input validation, output constraints, escalation paths and audit logging — designed with your compliance requirements in the room, not retrofitted after the first incident.
Model operations
Versioned prompts, staged rollouts, and the ability to roll back a change in minutes when quality drops. The same rigour you would expect of any other production dependency.
How an engagement runs
Write down what correct means
Two weeks, usually. We build the evaluation set with the people who will judge the answers, from real inputs rather than invented ones. Nothing else starts until this exists.
Get the retrieval right first
Most quality problems are retrieval problems wearing a model costume. Chunking, ranking and permissions are tuned against the evaluation set before anyone touches a prompt.
Put it in front of ten real users
A closed pilot with logging on everything. The failures that matter are the ones nobody predicted, and they only appear when the questions stop being ours.
Harden the cost and the traces
Caching, model routing and a cost line per feature. Every answer traceable back to the documents that produced it, because you will need that on the day it is wrong.
Hand over the evaluation set
The harness is the asset. Your team should be able to change a prompt, run the suite and know whether they made it better — without us in the room.
What you are left with
Evaluation harness
A graded set that runs in CI, with the scoring rules written down and argued over.
Cost model
Spend per feature and per thousand requests, with the levers that move it identified.
Traces
Every response linked to its retrieved context, retained long enough to investigate a complaint.
Runbook
What to do when quality drops, the provider degrades, or a model version is deprecated.
How we work
We prefer to start narrow. One workflow, one measurable outcome, four to six weeks. That is long enough to hit the real problems — the awkward documents, the edge cases, the latency budget — and short enough that you find out early if the approach is wrong.
From there the work compounds. The evaluation harness built for the first workflow serves the second. The retrieval layer gets reused. The team that shipped it stays on it, so nothing is relearned from scratch at each phase.
- A defined evaluation set before any model work begins
- Weekly demos against real data, not curated examples
- Cost and latency tracked from the first week
- Your engineers in the codebase throughout, not handed a black box
When not to hire us
If the honest answer to your problem is a database query, a report, or three lines of business logic, we will tell you that in the first call and not send an invoice.
We also turn down work where nobody on your side can say what a correct answer looks like. Without that, an AI system cannot be evaluated, only demonstrated — and demonstrations are not something we are willing to charge for.
Common questions
For most teams, start with a commercial API. The quality is higher, the operational burden is lower, and you learn what you actually need before committing to infrastructure. Self-hosting earns its keep when data residency requires it, when volume makes the unit economics clearly favourable, or when you need a level of latency control the APIs cannot give you. We help you work out which case you are in rather than assuming.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.