AI that reaches
production.
The gap between an impressive demo and a system your team relies on is not the model. It is retrieval quality, structured output, evaluation, failure handling, and knowing exactly which decisions a human still has to make. That gap is the entire job — and it is what we do.
Three things we believe about AI in business
One — AI is a component, not a product. It belongs inside a workflow that already works, doing the specific step that rules cannot do. An AI feature bolted onto a broken process produces a faster broken process. This is why our AI work almost always follows CRM and automation work rather than preceding it.
Two — if you cannot measure it, you cannot ship it. "It seems to work" is not a deployment criterion. Every system we build gets a golden set of real examples with known-correct answers, and a measured accuracy figure before it touches a customer. Without that number, nobody can tell whether a prompt change made things better or worse.
Three — the right output is structured, not conversational. The highest-value applications rarely look like a chatbot. They look like a field being filled in correctly, a document being routed to the right person, a record being scored, a summary appearing where somebody needed it. Chat is a fallback interface for when you have not worked out the workflow yet.
Where AI projects actually fail
- No definition of correct. Nobody wrote down what a good output looks like, so nobody can tell whether it is working.
- Garbage retrieval. The model is fine; it was handed the wrong three documents. Retrieval quality determines answer quality far more than model choice.
- Free text where fields were needed. The output cannot be filtered, reported on or acted upon by the next step.
- No human checkpoint at the point of consequence. Something wrong reached a customer, trust collapsed, and the project was cancelled.
- Cost discovered in month two. A per-record call at production volume that nobody modelled beforehand.
- Compliance considered at the end. Personal data went to a provider with no agreement in place, and legal stopped the rollout after the build.
What we build, specifically
Ordered roughly by how quickly they pay for themselves in a mid-market commercial organisation.
Conversation intelligence into CRM fields
A sales call ends. The recording is transcribed, then a structured extraction pass fills in what was actually established: budget signal, decision timeline, stakeholders named, competitors mentioned, objections raised, agreed next step and date. It writes into CRM fields, not a note.
- Confidence score per extracted field; anything below threshold is flagged rather than written
- A short summary and the proposed next action drafted for the rep to approve, edit or discard
- An objection library that builds itself from real conversations, feeding enablement
- Why it pays: reps stop losing twenty minutes per call to admin, and pipeline data becomes complete enough to actually analyse
Inbound triage — email, forms and documents
Everything arriving at a shared mailbox gets classified by intent, urgency and topic, has key entities extracted, is matched to an existing record, and is routed to the right owner with a draft response prepared.
- Handles enquiries, applications, complaints, supplier correspondence and invoices in one pipeline
- Attachments parsed — PDFs, scans with OCR, spreadsheets — into structured fields
- Drafts prepared in your tone from your own historical replies, never sent without approval
- Why it pays: response time drops from hours to minutes, and nothing sits unread in a shared inbox over a weekend
Retrieval over your own knowledge
An assistant that answers from your proposals, specifications, SOPs, contracts and product documentation — with citations back to the source document and section, so an answer can be verified in one click.
- Ingestion pipeline with document-aware chunking, metadata and permission filtering
- Hybrid retrieval — semantic plus keyword — with reranking, because pure vector search misses exact terms like part numbers and clause references
- Explicit refusal behaviour: when the corpus does not contain the answer, it says so rather than inventing one
- Freshness handling so superseded versions do not get cited as current
- Why it pays: the tacit knowledge held by two long-serving people becomes available to everyone, including new hires
Lead qualification and enrichment
Scoring that reads unstructured signals rather than checking a form field. Website, filings, job postings, technology footprint and news assessed against a written ICP definition, producing a score with a stated reason.
- ICP criteria defined explicitly and versioned, so scoring changes are deliberate and traceable
- Each score carries a justification a rep can read in five seconds and disagree with
- Feedback loop: closed-won and closed-lost outcomes recalibrate the criteria quarterly
- Why it pays: rep time concentrates on the top of the list instead of being spread evenly across it
Voice agents
Inbound call handling and outbound qualification or appointment setting where volume genuinely justifies it — with an explicit, well-designed escalation path to a human.
- Disclosure that the caller is speaking to an AI system, stated up front — a transparency obligation under the EU AI Act and, frankly, the right thing to do
- Narrow, well-scoped tasks only: qualification, scheduling, status, routing. Not negotiation, not complaints
- Immediate handover to a person on request, on confusion, or on any emotional signal
- Full transcript and outcome written to the CRM record
- Why it pays: after-hours and overflow coverage without staffing for peak. Worth being honest, though — this is the use case with the widest gap between demo and production, and we will tell you when your volume does not justify it
Document generation and review
Proposals, statements of work, specifications and reports drafted from structured record data plus your own library of approved language — then checked against a rules list before a human signs off.
- Assembly from approved clause blocks rather than free generation, so commercial terms stay controlled
- Review pass flagging missing sections, inconsistent figures and deviations from standard terms
- Inbound document review — supplier contracts, tenders — summarised with the clauses that need attention surfaced
- Why it pays: proposal turnaround measured in hours, and fewer errors in the documents that create obligations
How we actually build it
The unglamorous part, which is where the reliability comes from.
Evaluation first
Before writing a prompt we assemble fifty to two hundred real examples with known-correct outputs. That golden set becomes the regression test. Every change is measured against it, and accuracy, precision and recall are tracked per version. It is the only way to know whether "improving" the prompt improved anything.
Structured output, enforced
JSON schemas and tool-use definitions rather than parsing prose. The model is constrained to a shape the next system already understands, with validation on the way out and a defined behaviour when validation fails. This single decision eliminates most integration fragility.
Model selection and routing
We are provider-independent and use Claude, GPT and Gemini according to fit. Cheap fast models handle classification and routing; frontier models handle reasoning-heavy extraction and drafting. Routing by task keeps cost proportionate to value, and the abstraction means swapping a model is a configuration change.
Retrieval as its own discipline
Chunking strategy matched to document type, metadata for filtering, hybrid search, reranking, and evaluation of retrieval separately from generation. When an answer is wrong it is usually retrieval, and if you cannot measure the two independently you will spend weeks tuning the wrong one.
Guardrails and containment
Input validation and prompt-injection defence, output filtering, refusal behaviour when confidence is low, hard limits on what any agent can actually do, and every tool call scoped and logged. An agent that can write to production without a bounded permission set is an incident waiting for a date.
Human-in-the-loop by design
We decide explicitly, per use case, where a person approves: always, above a value threshold, below a confidence threshold, or on sampled audit only. Approval queues are built into the workflow rather than being an email someone forgets. Anything customer-facing defaults to human approval until the measured error rate earns otherwise.
Observability and cost control
Every call traced with prompt version, model, token counts, latency and outcome. Cost per transaction is a monitored figure with an alert threshold, prompt caching is used where the workload allows, and there is a written answer to "what does this cost at ten times the volume?" before go-live.
Versioning and rollback
Prompts live in version control with the eval results for each version attached. Changes go through staging with a measured comparison. Rollback is one deployment, not an archaeology exercise through someone's chat history.
Data minimisation
Personal data is redacted or pseudonymised before leaving your environment wherever the task allows it. Retention on prompts and completions is set deliberately, and zero-retention or no-training terms are used where the provider offers them. What is not sent cannot leak.
AI, GDPR and the EU AI Act
If you have European customers or employees, these are design constraints from day one — not a compliance review at the end that stops the project.
Data protection
- A lawful basis documented per processing activity, and a Data Processing Agreement with every AI provider in the chain
- Model providers engaged as processors, on terms that exclude training on your data
- Transfer safeguards where processing happens outside the EEA, with regional endpoints used wherever available
- Records of processing updated to include AI activities — routinely forgotten, routinely asked about in an audit
- A Data Protection Impact Assessment where the processing warrants one, particularly for anything affecting individuals
- Deletion and export requests executable across the AI pipeline, not only the primary database
EU AI Act
- Every system classified by risk tier before build, and the classification written down with its reasoning
- Transparency obligations honoured: people are told when they are interacting with an AI system, and synthetic content is marked as such
- Deliberate avoidance of high-risk categories unless there is a compelling reason — recruitment screening and creditworthiness assessment carry substantial obligations, so we design around them by keeping AI in an assistive rather than deciding role
- AI literacy obligations supported through the training and documentation we hand over
- Human oversight, logging and technical documentation built in as engineering practice rather than paperwork produced afterwards
How an AI engagement runs
Short, evidence-driven phases with a genuine stop-or-continue decision at each gate.
Use-case selection — 1 week
We look at the whole operation and shortlist candidates by value, feasibility and risk. The winner is usually the highest-volume repetitive judgement task with a clear definition of correct — and it is frequently not the use case people arrive asking for. Output: a ranked shortlist with an estimate and expected payback per item.
Evaluation harness — 1 to 2 weeks
Collect real historical examples, define correct output with the people who do the work today, and build the scoring harness. This phase is why our projects do not stall in "it seems fine" limbo. Output: a golden dataset and a measurement pipeline you keep.
Pilot — 2 to 3 weeks
Build against the eval set until accuracy clears the agreed bar, then run in shadow mode on live traffic without acting on the output. Compare against what humans actually did. Output: a measured accuracy figure, a cost-per-transaction figure, and a documented go or no-go.
Production — 2 to 4 weeks
Integrate into the real workflow, with approval queues, error paths, monitoring, alerting and rollback. Roll out to a subset of users first. Output: a live system, a runbook, and dashboards showing accuracy, volume and cost.
Operate and improve — ongoing
Accuracy tracked over time because inputs drift, models change and edge cases accumulate. New examples added to the golden set from real failures. Model and prompt updates tested against it before release. Output: a quarterly review with the numbers, and the next use case queued.
AI questions we get asked most
Is our data used to train the models?
Not under the terms we deploy. The major providers offer business and enterprise agreements where inputs and outputs are excluded from training, with defined retention. We configure zero-retention or short-retention endpoints where they are available, agree the terms in writing before any real data is processed, and document per system which provider handles what. If you require processing that never leaves your infrastructure, that is a legitimate constraint and we build for it with open-weight models on your own hardware — accepting the trade-off in capability that comes with it.
What accuracy can we expect?
It depends entirely on the task, and anyone quoting a number before seeing your data is guessing. As rough calibration from work of this kind: well-defined classification with clean inputs performs very reliably; structured extraction from good-quality documents performs well with a small tail of ambiguous cases; retrieval-based question answering over a well-curated corpus is dependable when the answer exists in the corpus and depends heavily on how well that corpus is maintained.
The real answer is that we measure it on your data during the pilot, before you commit to production. If it does not clear the bar we agreed, we say so and you have spent a small pilot budget instead of a large implementation one.
Will this replace people on our team?
In every deployment we have been involved in, it removed administrative load rather than headcount — reps got calling time back, coordinators stopped re-typing, back office stopped assembling documents by hand. We are also clear-eyed that this is a decision you make, not us. What we will say plainly is that automation projects framed internally as headcount reduction tend to fail, because the people who hold the process knowledge required to build it correctly have no incentive to help you build it. The ones that succeed are framed as capacity — the same team handling more volume without more hours.
What does it cost to run?
Model inference is usually the smaller line item — the cost that matters is building and maintaining it properly. For most workflows the per-transaction inference cost is small enough that it is dominated by the labour it replaces, but the failure mode is real: a naive design that sends a large document to a frontier model on every record can multiply that by two orders of magnitude. We model cost per transaction during the pilot, route cheap tasks to cheap models, cache aggressively, and give you the figure at current and at ten-times volume before you go live.
Can we start small?
You should. One use case, one evaluation harness, one pilot with a real accuracy number. It is a small fixed-fee engagement that either proves the case with evidence or tells you honestly that this particular task is not ready — both of which are worth considerably more than a twelve-month AI strategy document. Roughly half of our AI clients started with a single pilot in one department.
Bring us the task nobody wants to do.
The repetitive judgement call your team makes forty times a week. We will tell you whether it is a good AI candidate, what it would take, and what it would cost — or that it is not, which is also an answer.