Discipline
AI that shows its working.
Retrieval, assistants and background agents wired into the systems you already run — scoped to the jobs where a wrong answer is visible, and built so every answer can be traced back to the document it came from.
Where it helps
What automation can and cannot do
An honest account of where a model earns its place, and where a person should keep the decision.
Most of the work labelled AI is ordinary software with a model in one step of it. That step is genuinely useful: it reads unstructured text, drafts a first version, and matches a question to the paragraph that answers it. It is also the least predictable part of the system, so we build everything around it to be dull — typed inputs, recorded outputs, and a way to see exactly what happened.
A model does not know your business. It knows the documents you give it and the tools you let it call. So the first half of an automation project is rarely modelling at all: it is finding where the knowledge actually lives, agreeing what a correct answer looks like, and writing the evaluation set that proves it before anything reaches a customer.
There is work we will tell you not to automate. Decisions with legal weight, judgement calls someone is accountable for, and anything where a plausible wrong answer costs more than no answer at all — those keep a person in the loop, with the model doing the reading rather than the deciding.
What you get
What an automation engagement delivers
The same set of artefacts every time — the parts that turn a working demo into a system somebody can operate.
Source inventory
Where the knowledge lives, what state it is in, and what it costs to keep current.
Evaluation set
A graded set of real questions with agreed answers, run on every change, so quality is measured rather than felt.
Retrieval pipeline
Ingestion, chunking, embedding and ranking, tuned on your own material instead of someone else's benchmark.
Assistant interface
The place people actually ask — your product, your help desk or your chat tool — with citations attached to every answer.
Background agents
Scheduled and event-driven jobs that draft, classify or route work, with a queue a person can inspect.
Guardrails and fallbacks
Limits on what the system may answer or act on, and a defined behaviour for the moment it is not confident.
Traces and cost reporting
Every call logged with its prompt, its sources and its cost, so behaviour and spend stay explainable.
Handover and runbook
Prompts, evaluations and infrastructure in your accounts, documented for the team that keeps them running.
The engagement
From a task to a system you can check.
Five stages, each ending in something you can read, run or score. Nothing ships on the strength of a good demo.
Qualify
We take the tasks you have in mind and keep the ones where the input exists, the output can be checked, and the cost of a mistake is bearable.
Ground
Sources are gathered, cleaned and indexed. Access rules travel with the documents, so an assistant can never answer from a file its reader could not open.
Evaluate
We write the question set with your experts and score a baseline before tuning anything, so every later change is measured against it.
Wire in
The model goes behind a typed interface in your stack, with retries, budgets and a defined fallback for the moment it is unavailable.
Operate
Traces, costs and failed answers land on a dashboard your team owns, and the evaluation set runs on every change from then on.
In use
One answer, grounded in its source.
Walkthrough placeholder — a recorded demo replaces this frame.
Depth
Evaluation, guardrails, handover.
An assistant is easy to demo and hard to keep honest. The difference is a graded question set that runs on every change, so a prompt edit that improves one answer and breaks four is caught before anyone meets it in production.
Guardrails are the other half: what the system may answer, what it must refuse, when it hands over to a person, and what it does when a source is missing. We write those rules down with you and then encode them — and the handover pack carries the prompts, the evaluations and the runbook, in your accounts.
- Graded evaluations, run on every change.
- Defined refusal and escalation paths.
- Prompts, traces and costs in your accounts.
Stack
What we build these on.
- Python
- TypeScript
- Node.js
- FastAPI
- PostgreSQL
- pgvector
- ChromaDB
- Redis
- Anthropic API
- OpenAI API
- Docker
- AWS
Chosen per task — the model is one component, not the architecture.
The two cases above are placeholders standing in for real studies — no client is named and no outcome is quantified.How we present real work
Questions
Questions we get about automation
The four that come up before almost every first call.
Do we need our own model?
Almost never. The work sits in retrieval, evaluation and the interface around a hosted model; we pick the model per task and keep the code able to swap it.
A self-hosted or fine-tuned model earns its cost when data cannot leave your infrastructure, or when the workload is large and narrow enough to pay for itself.
Where does our data go?
Into your accounts. Documents are indexed in a store you own, access rules travel with them, and the only thing leaving is the request to the model provider — with a written record of what was sent.
If nothing may leave at all, we say so early and scope for a model that runs on your side instead.
How do you know the answers are right?
A graded question set written with your experts, scored before anything is tuned and run on every change after. Answers carry citations, so a reader can check the source rather than trust the tone.
We report the score honestly, including the questions the system still gets wrong.
What if it does not work well enough?
Then we say so. Some tasks fail the evaluation however the prompt is written, usually because the source material does not contain the answer. Finding that out in week two is a result, and it costs a fraction of discovering it after launch.
Next step
What did you nearly automate?
Describe the job, the sources it would read and what a wrong answer would cost. We will tell you whether it is a good candidate and what we would try in the first two weeks.