Home / AI solutions

Applied AI

AI is easy to demonstrate and hard to put into production

We build automation, triage and knowledge assistance that survives contact with real users, real data and an audit requirement. Guardrails, human review and a measurable case for the spend, or we tell you not to bother.

Talk through a use case Where it works

Our position

Most AI projects fail somewhere between the demo and the second month

The pilot works because someone knowledgeable is watching it. Then it meets messy data, edge cases nobody catalogued, and a user who does something the design never anticipated. The interesting engineering is all in that gap, and it is the part most proposals skip.

01
Start where the cost is known. A task somebody does hundreds of times a week has a measurable baseline. Without one you cannot tell whether it worked.
02
Keep a person in the loop where it matters. Review before action for anything consequential. The productivity gain is in the drafting, not the deciding.
03
Log everything. If you cannot reconstruct why the system produced a given output, you cannot defend it to an auditor, a regulator or a complainant.
04
Be honest about running cost. Model pricing moves, and a workflow that only works at current prices is a risk you should price in now.

Where it works

The use cases that hold up

These have a clear baseline, a tolerable failure mode and a person who benefits immediately. That combination is rarer than the market suggests.

Correspondence triage

Classifying and routing inbound volume, drafting a first response, and flagging the cases that need a human immediately. The reviewer stays in place; the sorting goes away.

Summarisation and extraction

Turning long documents, case files or transcripts into structured fields a person can check in seconds rather than reconstruct in an hour.

Knowledge assistance

Answering internal questions from your own documented material, with citations back to the source so the answer can be verified rather than trusted.

Data quality and matching

Deduplication, reconciliation and messy record matching during migrations, where the rules are too varied to write by hand but the output still has to be checked.

Drafting at volume

First drafts of repetitive written output, produced to your house style, always reviewed before anything is sent or published.

Evaluation and assurance

Test sets, measurement and a documented evaluation of how a system performs on your data, including where it fails. Usually the missing piece.

How we approach it

Four stages, and most ideas stop at the second

That is the point of having a process. The cheapest AI project is the one you decide not to run.

Baseline

Establish what the task costs today in time, error rate and delay. Without a baseline there is nothing to measure against later.

Feasibility

A short test against your real data, not a curated sample. This is where most ideas are ruled out, which is a good outcome.

Build with guardrails

Human review, logging, fallback behaviour and an evaluation set. Built to be inspected, not just to work.

Measure and hand over

Compare against the baseline, document the operating procedure, and leave your team able to run and monitor it.

Governance

The parts that make it defensible

In healthcare and government especially, the question is not whether the output is good. It is whether you can explain how it was produced, show what data it saw, and demonstrate that a person remained accountable for the decision. We design for that from the first workshop, because retrofitting it is close to impossible.

If you cannot explain to an affected person how a decision about them was reached, do not automate that decision.

Our line on scope

Human in the loopReview before action on anything with a consequence.

Audit trailInputs, outputs and model version logged so any result can be reconstructed.

Your keys, your dataClients hold their own API credentials. We do not sit in the middle of your data.

Documented evaluationMeasured performance on your data, including the failure modes.

Cost visibilityPer task running cost surfaced, so the business case stays honest.

Common questions

Before you get in touch

These come up on almost every first call.

Which models do you use?

Whichever suits the task and your constraints on data residency and cost. We are not tied to a vendor and we have no reseller arrangement, so the recommendation is based on fit rather than margin.

Where does our data go?

That is a design decision we make with you before anything is built, and it constrains which options are available. Clients normally hold their own API credentials so the relationship with the provider is theirs, not ours.

Will this replace people?

The work we take on is aimed at removing volume from people who are already overloaded, which is a different thing. If your objective is headcount reduction, say so at the outset, because it changes the design and the honesty of the business case.

What about the EU AI Act and UK regulation?

Scope and risk classification are worth establishing early, particularly in healthcare and public services. We will flag where an obligation looks likely to apply, but this is general information rather than legal advice and you should take your own.

Can you just review what we have already built?

Yes. An independent evaluation of an existing system, including where it fails and what it costs to run, is often more useful than building something new.

Start here

Bring us a task, not a technology.

Tell us what somebody in your organisation does repeatedly and reluctantly. That is a better starting point than a tool you have been shown.

Talk through a use case How we build things