Service
AI integration services
Applied where it removes work, not where it demos well.
For teams who want AI inside the systems they already run, doing specific jobs: reading documents, classifying what arrives, answering questions over their own data, drafting what a person then approves. Built with evaluation and cost control, because a feature nobody can measure is a feature nobody can trust.
The decision
When this is the right call.
Most AI features fail in the same two ways. They are added where they are visible rather than where they save time, and they ship without any way of knowing whether the output is right. A summariser that is wrong one time in twenty is worse than no summariser, because the twentieth case is the one that reaches a customer.
The second failure is cost and latency discovered in production. A prompt that is fine in testing becomes expensive at ten thousand calls a day, and a feature that takes nine seconds will not be used however good it is. Both are design constraints, and both are cheap to handle early and awkward to retrofit.
We start from the task rather than the technology: what work is being done by hand, how often, and what it costs when it is wrong. Then we build an evaluation set before the feature, so the question of whether it works has an answer. Often the right answer turns out not to need a model at all, and we say so.
What you get
What the work covers.
Document extraction
Invoices, purchase orders, statements and forms read into structured fields, with confidence surfaced so low-confidence items go to a person rather than silently through.
Classification and routing
Incoming enquiries, tickets and documents sorted to the right queue, with the rules auditable rather than opaque.
Search over your own data
Retrieval across your documents and records that cites its sources, so an answer can be checked rather than believed.
Drafting with a human gate
Replies, summaries and descriptions prepared for a person to approve. The gate is a design decision, not a disclaimer.
Evaluation before launch
A labelled set and a measured pass rate, so a prompt or model change is a comparison rather than a hunch.
Cost and latency control
Caching, model routing by difficulty, and budget alerts, because per-call pricing becomes a monthly bill nobody scoped.
Stack
What we build it with.
Chosen per project. Nothing here is applied by default, and the team who will maintain it counts as much as the problem.
Models
Claude, GPT or an open-weight model, selected per task on measured quality and cost rather than on brand.
Retrieval
PostgreSQL with pgvector where it is enough, a dedicated vector store where scale justifies one.
Orchestration
Plain, inspectable code by preference. Heavyweight agent frameworks are used only when they earn their debugging cost.
Evaluation
Versioned test sets run in the pipeline, so a regression is caught in CI rather than by a customer.
Privacy
Data residency, retention and redaction decided before the first call, including whether a request may leave your infrastructure at all.
Comparison
Bolted-on AI vs AI that earns its place.
Most AI features fail the same two ways: added where they are visible rather than where they save time, and shipped with no way to know whether the output is right.
| Aspect | Typical bolt-on | How we build it |
|---|---|---|
| Where it goes | Where it demos well - a chat box on the dashboard | Where the manual work actually is, which is usually unglamorous |
| Knowing it works | Someone tried it a few times and it seemed fine | A labelled set from your real cases, with a measured pass rate before launch |
| When it is unsure | Answers anyway, with the same confidence as when it is right | Routes below your threshold to a person, and the threshold is yours to set |
| Cost | Discovered on the first month's bill | Estimated during discovery, with caching, model routing and a budget alert |
| Latency | Found in production, after which the feature quietly stops being used | A design constraint with a number, because a nine-second feature will not be used |
| Changing the prompt or model | A change nobody can evaluate, so nobody dares make it | A measured comparison against the same test set, run in CI |
How it runs
From first conversation to live.
Indicative for work of this shape. The pilot is not optional — nothing is switched over until the people using it say it holds.
- 1 week
Find the work
What is being done by hand, how often, and what it costs when it is wrong. Sometimes the answer is a rule or a better form, and we say so.
- 1 week
Build the evaluation set
Real cases, labelled, before the feature exists. Without this there is no way to tell an improvement from a regression.
- 3-5 weeks
Build and measure
The integration, the human gate, caching and cost controls, measured against the set at every change.
- 2-3 weeks
Pilot and tune
Live on a slice of real volume with the gate set conservatively, then loosened only as the measured numbers justify it.
After launch
What changes.
- The manual step it was built to remove is actually removed, rather than supplemented.
- Low-confidence cases reach a person instead of passing silently, which is what makes the feature safe to leave running.
- A prompt or model change becomes a comparison rather than a gamble.
- The monthly bill is a number someone predicted, not a surprise.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
Will our data be used to train someone else's model?
Not with the configurations we deploy. Enterprise API terms exclude training on submitted data, and where that is not acceptable we run an open-weight model on your own infrastructure instead. This is decided before any integration is built.
How do you know the AI is right?
We build a labelled evaluation set from your real cases before shipping the feature, and measure against it. Anything below the agreed threshold routes to a person instead of proceeding, and the threshold is yours to set.
What does it cost to run?
It depends on volume and the model chosen, and we estimate it during discovery rather than after launch. Caching, routing simple cases to cheaper models, and a monthly budget alert are part of the build.
Do we need AI at all?
Often not. A well-placed rule, a better form or a fixed report solves a surprising share of what gets scoped as an AI problem, at a fraction of the cost and with none of the uncertainty. We will tell you when that is the case.
Can you run a model on our own infrastructure?
Yes, with an open-weight model where data residency or contractual terms require it. The trade is quality and operational overhead against control, and it is worth deciding on measured results for your actual task rather than on principle.
What if the AI gets something wrong in front of a customer?
That is what the human gate and the confidence threshold exist to prevent, and both are design decisions made before the feature ships rather than a disclaimer added after. Where the cost of being wrong is high, the right setting is to draft for approval and never to act unattended.