AI that does a specific job properly, rather than a chatbot nobody uses
Most AI projects fail for boring reasons: the demo worked, nobody tested it against real inputs, the token bill arrived, and it was quietly switched off. We build the unglamorous parts — grounding, evaluation, cost caps, human review — because that is what decides whether an AI feature is still running a year later. And we will tell you on the first call when a rule, a script or a hire is a better answer than a model.
Engagement
Two ways to start. A fixed two-week paid assessment that maps candidate tasks, ranks them by value against risk, and hands you a written recommendation including the cases where not using AI is correct — so you are not committed to a build before you know what is worth building. Or a two-week proof on one task, fixed price, that ends with a working system and a real pass rate on your data. Either way the evaluation suite is a deliverable, not an upsell.
What you get
Deliverables, not adjectives
This is what lands in your hands at the end. If something is missing from this list, it was not in scope — and we will say so before we start rather than after.
A written scope defining exactly which task the model does, what it must never do, and how we will know it is working
Retrieval grounded in your own content — contracts, policies, product data, tickets — with citations back to the source document
An evaluation suite that runs against real examples from your business and gives a pass rate you can put in front of a board
A human review queue, so low-confidence and high-stakes outputs wait for a person instead of going straight to a customer
Hard cost controls: per-request ceilings, caching, cheaper models where they are good enough, and an alert before the bill surprises you
Privacy handled properly — data minimisation, redaction, and a clear answer on whether anything is leaving your infrastructure
Integration into the systems you already run, not a standalone chat page nobody opens
Monitoring for drift and failure in production, with a plain-English alert when quality drops
A documented handover so your team can change prompts, swap models and extend it without coming back to us
When to call us
The situations where this is the right conversation
If you recognise one of these, that is probably enough to justify a 30-minute call.
01
You tried an AI tool and it was useless in practice
Almost always the same cause: no grounding and no evaluation. The model answered from its own weights instead of your documents, and nobody had a test set to catch it. We fix the retrieval and build the evals first, then improve the prompt.
02
Your team is doing work a model could plausibly do
Reading and extracting from invoices, triaging inbound email, drafting standard responses, summarising long documents, copying data between systems. We map the actual task volume first, then automate the parts where the error cost is low and the volume is high.
03
You want a chatbot for customers that will not embarrass you
A public chatbot that invents a policy is a worse problem than having no chatbot. We ground it in your real content, make it say "I do not know" when the answer is not in the source, and hand over the refusal cases as a deliberate design decision rather than an accident.
04
Legal or compliance will not sign off on data leaving the building
Common, and solvable. We can keep sensitive data on your own infrastructure with an open-weight model, or strip identifiers before anything is sent externally. We will produce the data-flow description your DPO needs, not just working code.
05
You are worried about being left with a bill nobody predicted
Token costs scale with usage, and usage scales with success. We put ceilings in place, cache repeated work, route simple requests to a cheaper model, and alert you at a threshold you set — before the invoice, not after.
How we build it
The tools we would reach for
Not a shopping list. These are what we would actually pick for this kind of work, and we will tell you if a different tool fits your constraints better.
- OpenAI API
- Anthropic Claude API
- Self-hosted open-weight models
- Python
- FastAPI
- TypeScript
- PostgreSQL
- pgvector
- Pinecone
- promptfoo
- Langfuse
- Temporal
- n8n
- Next.js
Examples
The shape of work this usually turns into
Illustrative scenarios, kept anonymous. Specific case studies with client names and evidenced metrics appear on our work page as clients approve them.
Grounded support assistant over existing documentation
Answers customer questions from the help centre and past tickets, with a citation to the source for every answer. Below a confidence threshold it stops and queues for a human, so it degrades into something useful rather than into a confident guess.
- RAG
- Citations
- Human review
Document extraction pipeline for incoming paperwork
Reads supplier invoices and purchase orders in whatever format they arrive, extracts the fields into your system, and flags anything it is not confident about. Built around structured output validation, so a malformed response is caught and retried rather than silently written to the database.
- Structured output
- Validation
- Back office
Internal workflow automation with an approval step
Drafts the routine operational work — summaries, first-draft responses, meeting notes with action items — and routes anything with a commercial or contractual consequence to a named person for approval before it goes anywhere.
- Workflow
- Approval gate
- Internal
Evaluation harness before go-live
A set of two hundred real examples from the client's own history, run against every prompt and model change as part of the deployment pipeline. A change that drops the pass rate fails the build instead of reaching customers.
- Evals
- CI/CD
- Regression
Questions
AI & automation: what buyers ask
Straight answers, including where the answer is that you probably do not need this.
Not if you use the API tiers we build on, which have zero-retention terms — submitted data is not used for training. Where a model provider's terms are not acceptable to you, we run an open-weight model on your own infrastructure and the data never leaves. We will tell you which case applies before you commit, in writing.
Frequently, yes, and we will say so rather than dress it up. The value is rarely the model call. It is knowing which task is worth automating, retrieving the right context, validating the output, handling the failure cases, keeping the cost predictable, and integrating it into a system people actually use. Any competent developer can call an API; most AI projects die in the parts around it.
By building an evaluation suite before we build the feature. We take real examples from your own history, define what a correct answer looks like, and run the suite on every prompt and model change as part of the deployment pipeline. You get a pass rate you can report, and a change that degrades quality fails the build instead of reaching your customers.
We design for it rather than hoping it does not happen. Grounding with citations so answers can be checked, structured output validated against a schema, confidence thresholds that route uncertain cases to a person, and monitoring that alerts on a drop in quality. For anything with a legal or financial consequence, the approval step is not optional and we will say so.
The cheapest one that passes your evaluation suite, which is frequently not the largest one. We start small, measure against real examples, and only move up when the evaluations show a larger model is actually needed. Self-hosted open-weight models are a genuine option where data sensitivity or unit economics demand it.
Token spend scales with volume, so we build in ceilings, caching and model routing from the start, and you get an alert at a threshold you set. You are never surprised by an invoice. We will also be straight in the assessment if the running cost approaches the cost of the person doing the work — at that point it is the wrong project.
No. The hard parts here are software engineering, data plumbing, evaluation and integration, not modelling. We build the whole thing, and we leave behind a documented system your engineers can extend — because a system only one vendor can change is a liability, not an asset.
We are not lawyers and we will not give you legal advice. What we will do is engineer to the requirements: document the system's purpose and risk classification, keep a technical log where the Act expects one, provide the transparency notices for systems that interact with people, and hand your counsel the technical detail they need to make the call. UK GDPR applies in parallel and we treat data flows accordingly.
Related
Often needed alongside this
Got a ai & automation project in mind?
Send us the problem and the constraint. You will get a written responsewithin one uk business day, uk hours, 9:00-18:00, monday to friday, and an honest view on whether we are the right fit.