Retrieval that answers in seconds, at a cost per answer you can defend.
An AI system inside a bank is judged twice: once by the people waiting on it, and once by the people who have to account for it. A pipeline that takes thirty seconds to answer is one nobody uses, and a pipeline whose token bill grows faster than its usage is one finance will eventually close. We re-architect retrieval for speed and unit economics together, and build the extraction and audit paths that let the output stand up to scrutiny.
Their customers had stopped waiting for answers
A data and analytics platform used by central and investment banks.
The platform answers research questions across an enormous estate of documents and data, the kind of question that would otherwise cost an analyst a day of reading. In a product like that, speed is what customers are paying for.
Answers were averaging thirty to sixty seconds, and the worst of them took over two minutes. Customers had moved from grumbling to formal complaints, and some had stopped asking questions altogether. From the outside there was no obvious reason why: behind each answer sat a search across a vast corpus, a chain of tool calls running one after another, and far more data than any single question needed. The client had an AI team of its own, and it had been working the problem.
The brief was to make it twice as fast. The client expected running costs to rise to pay for that, and had accepted it.
- 01Redesigned the retrieval pipeline from the ground up, because the limits were built into the design and no amount of tuning would remove them.
- 02Parallelised the tool calls that had been running one after another, removing most of the waiting.
- 03Matched the model to each task, tested against a fixed set of questions, so the most expensive model is used only where it measurably improves the answer.
- 04Stripped out prompt bloat, so every call carried what the task needed and nothing it did not.
- 05Added caching wherever the system was repeating the same work for every question.
- 06Introduced continuous evaluation, so accuracy and speed are measured every time the system changes, not discovered through a customer complaint.
They asked for two times. They got eight, and paid less to run it.
Average response time
Slowest response, time to first token (TTFT)
Running cost
Measured on the client's own question set, before and after the rebuild.
For the same client we also engineered the OCR extraction pipelines and the cloud infrastructure underneath them.
In systems like this, speed, accuracy and cost are decided by the design. When a product feels slow to the people paying for it, the fix usually lies in how the work is structured, not in how much computing power sits behind it.
Where the work usually sits
These are the problems we are asked about most often, not a list of everything we build. Discovery is what decides which one your institution actually needs.
- Retrieval performance
- Slow pipelines re-architected rather than tuned, because the ceiling is usually in the design: sequential tool calls parallelised, prompt payloads stripped back, caching placed where the system repeats itself, and model selection set per task against a fixed question set.
- Running cost
- Token consumption measured per answer rather than per month, so the unit economics hold as volume grows. Accuracy is tracked alongside it, so a saving that quietly degrades answers surfaces immediately.
- Auditable OCR and extraction
- Document pipelines that turn scans, statements and filings into structured data, with every extracted figure traceable to the page it came from and the whole path logged for review.
Proved on your own work before it goes live
No system takes over any part of your operation on the day it is finished. It runs in shadow mode first, alongside the people doing the work today. It answers the same questions against the same corpus, on its own path, while every answer your users see still comes from the pipeline you run today. Your existing process carries on exactly as before, so at no point are you relying on something unproven.
You see its latency distribution, its cost per answer and its accuracy against your own question set, measured beside the system it would replace. Shadow running lasts as long as you want it to, on your own work.
When you are satisfied with the results, you decide when it goes live, and you can start with part of the work. From then on, the system does the work it has shown it can do.
- Case arrives
- Your team works it
- Decision and action
- Same case, mirrored
- System works it
- Output logged only
No write path out of the shadow track. Nothing is sent, filed or actioned from it until you decide to go live.
Questions
Start with a conversation
The first conversation is free. We will talk through where your team’s time is going and tell you plainly whether we can help.