Applied AI and LLM engineering
LLM applications, retrieval and document intelligence — built on existing models, with an evaluation harness rather than vibes.
Worth being precise about scope, because a lot of firms are not. We build applications on top of language models that already exist — hosted APIs like Claude, or open-weight models we run for you. We do not train foundation models, and we do not take on computer vision, deep learning research or bespoke predictive modelling. Those are a different discipline with different people, and if that is what you need we will say so on the first call.
What we do build is the layer almost every AI project actually needs and most underinvest in. The hard part is not the model. It is knowing whether the thing is working — teams ship a demo that impresses a boardroom, then find in month two that accuracy on real documents is nowhere near what the pilot suggested.
So we build an evaluation harness before the feature. A golden dataset drawn from your real inputs, task-appropriate scoring, and a regression suite that runs on every prompt or model change. That harness is what lets you swap models, cut costs, and know immediately if quality moved.
From there: retrieval that respects your permission model, structured extraction with confidence thresholds and human review queues, guardrails against prompt injection and data leakage, and cost controls so a single runaway loop cannot produce a five-figure invoice.
The parts that matter.
- 01
LLM applications and copilots
Domain assistants, drafting tools and in-product copilots built on Claude, GPT or open-weight models, with tool use, structured outputs, streaming interfaces and a fallback when the provider has a bad day.
- 02
Retrieval and enterprise search
Hybrid retrieval over your documents, tickets, wikis and databases — chunking tuned to your content, permission-aware filtering, reranking, and citations so an answer can be verified rather than trusted.
- 03
Document intelligence
Extraction from invoices, purchase orders, contracts, delivery notes, inspection reports and scanned forms. Confidence scoring routes uncertain cases to a human review queue instead of guessing quietly.
- 04
Natural-language reporting
Ask a question of your own operational data in plain language and get an answer with the query behind it shown, so a supervisor can check the working rather than trust a number.
- 05
Evaluation and observability
Golden datasets, automated scoring, side-by-side comparison between models and prompts, full request tracing, and per-feature cost and latency dashboards.
- 06
Guardrails and cost control
Prompt injection defence, PII redaction, output validation against a schema, human approval on anything consequential, and hard per-feature budget ceilings enforced in code.
What you
actually receive.
Named artefacts, not a status report. Every item here is something you can open, run or hand to another engineer.
- 01Evaluation harness with a golden dataset built from your real inputs
- 02Production inference service with caching, retries and rate limiting
- 03Prompt and model version control with side-by-side regression scoring
- 04Guardrails: injection defence, PII redaction, output validation
- 05Human review queue for everything below the confidence threshold
- 06Per-feature token and cost dashboards with hard budget ceilings
Before you ask.
Do you train models or do computer vision?
No. We build on models that already exist — hosted APIs or open weights we run for you. Training foundation models, computer vision and bespoke deep learning are a different discipline, and we will point you to a specialist rather than take the work and learn on your budget.
Will our data be used to train someone else's model?
Not under the configurations we deploy. We use enterprise API tiers with training explicitly disabled, or self-hosted open-weight models inside your own network when the data cannot leave at all.
How do you keep inference costs under control?
Model routing by task difficulty, aggressive prompt caching, batching, and smaller models on high-volume paths. Cost per request is tracked from the first week, with budget ceilings enforced in code so a bad loop fails closed instead of billing you.
What if AI turns out not to be the right answer?
We would rather find that out in week three than month six. Discovery includes a feasibility check against your real data, and we have told clients before that a deterministic rules engine would serve them better and cost a fraction as much.
Tell us what you are building.
A short conversation is usually enough to tell whether we are the right firm for the problem. If we are not, we will say so and point you somewhere better.