Service
We take the AI feature that works in your demo and make it survive production.
Retrieval that returns the right document on the tenth thousand query, agents that fail loudly instead of silently, and an evaluation harness that tells you when a model change broke something.
The problem
What this actually looks like
The demo worked. You showed it to three customers, they liked it, and you started onboarding. Then real documents arrived — scanned, badly formatted, in four languages — and the answers got worse in ways nobody could reproduce.
Now there is a prompt file nobody wants to touch, a vector database with no reindexing story, and a growing suspicion that the whole thing is held together by the two examples used during the build.
The uncomfortable part is that you cannot tell whether it is getting better or worse, because there is nothing measuring it.
Deliverables
What you get
Concrete artifacts, not activities. Everything below is something you can point at and say you received it.
- A retrieval pipeline with documented chunking, embedding and reranking decisions
- An evaluation set built from your real queries, with pass rates per release
- Cost and latency instrumentation per request, broken down by model call
- Guardrails and fallbacks for the failure modes we find, not the generic ones
- A runbook for when a provider deprecates a model, because they will
- Handover session recorded, with the architecture notes in your repo
Timeline
How it works
Ranges, not best cases. The dates below are what it usually takes, including the week something goes wrong.
- 01Days 1–3
Read the code and the failures
We go through the pipeline and, more usefully, through the queries where it produced the wrong answer. Those are the specification.
- 02Days 4–7
Build the evaluation harness first
Before changing anything. Without a baseline every subsequent change is an opinion, and opinions are how these systems rot.
- 03Weeks 2–4
Fix retrieval, then generation
In that order, always. Most answer quality problems are retrieval problems wearing a prompt costume.
- 04Weeks 4–6
Instrument cost and latency
Per request, per model call. This is usually where somebody discovers a single endpoint is 60% of the bill.
- 05Final week
Handover
Architecture notes, the evaluation set, and a walkthrough with whoever owns it next. Recorded, because they will watch it twice.
Approach
How we think about this
We start from the failure cases, not the architecture diagram. An agent framework choice matters far less than knowing which twenty queries embarrass you, and teams almost never have that list written down.
We prefer boring, inspectable pipelines over frameworks that hide control flow. When a customer asks why the system said something, you need to be able to answer, and you cannot answer through four layers of abstraction you did not write.
What we refuse to do
- We will not ship an agent with no evaluation set. It is not a system, it is a demo with a cron job.
- We will not fine-tune a model to paper over a retrieval problem, because it costs more and hides the actual fault.
- We will not build on a framework we cannot debug at 3am, however good the launch demo was.
Engagement
How this is usually bought
Shape
Audit first, then a fixed-scope build
From
$18K
demo figure
Most AI work starts with the Build Audit, because the difference between a two-week fix and a two-month rebuild is not visible from outside the repo.
Full pricingFAQ
Questions people actually ask
Can you work with the model provider we are already on?
Yes. We have shipped on OpenAI, Anthropic and open-weight models running on our clients own infrastructure. The provider is rarely the interesting decision — the retrieval and evaluation layers are, and they are mostly provider-agnostic.
What does this actually cost to run per month once it is live?
We instrument that during the build and hand you the numbers, because it is usually the question nobody asked before launch. For a mid-volume internal tool it is typically tens of dollars a month; for a customer-facing feature at scale it can be thousands, and the difference is almost always retrieval design rather than model choice.
Our accuracy is bad but we cannot say why. Is that something you can fix?
That is the normal starting point, and the first thing we build is the measurement, not the fix. Once there is an evaluation set built from your real queries, "bad" becomes a number and a list, and the list is usually shorter than people fear.
What if a model update breaks it after you leave?
That is what the evaluation harness is for. You run it, you see the pass rate drop, and you know before your customers do. The runbook covers pinning, rolling back and re-qualifying a new model version.
Will you use our data to train anything?
No. Data handling is written into the engagement: your data stays in your infrastructure, nothing is used for training, and we sign an NDA before repo access.
What if you find the whole approach is wrong?
We tell you in week one rather than month three, and we say what we would do instead and what it would cost. If that means the engagement is smaller than quoted, it is smaller than quoted.