AI Integration
AI features built into your product, with the guardrails that keep them trustworthy
Assistants, document processing, semantic search and classification, wired into your real data and evaluated against real cases before anyone depends on them.
Recognise any of these
What usually brings people here
A demo impressed everyone in the room and then fell apart on real customer data.
The model is confidently wrong often enough that nobody trusts its output.
Token spend is climbing and no one can explain which feature is responsible.
You need AI in the product but cannot risk it saying something indefensible to a customer.
Deliverables
What the engagement produces
Concrete outputs, not activity. Each of these is something you can point at when the work is done.
A working feature inside your product
Not a proof of concept in a notebook. The feature ships behind a flag, connected to your data, with the same testing and monitoring as anything else in the codebase.
An evaluation set built from your real cases
Fifty to two hundred graded examples drawn from your actual work. Every prompt change is scored against them, so improvement is measured instead of felt.
Guardrails at the boundary
Input validation, output schema enforcement, refusal handling and a deterministic fallback for the moment the model returns something unusable.
Cost and latency instrumentation
Per feature token accounting and response time tracking, so spend is attributable and a slow prompt is visible before the invoice arrives.
A retrieval layer that returns the right context
Chunking, embedding and ranking tuned against your corpus. Most bad answers are a retrieval failure, not a model failure.
A human review path
For anything consequential, an interface where a person approves, edits or rejects the output, and where those decisions feed back into the evaluation set.
Process
How the work runs
- 01
Case selection
Rank candidate use cases by value and by tolerance for error. The first thing built should be valuable enough to matter and forgiving enough to survive being imperfect.
- 02
Build the evaluation set first
Collect real inputs and write the expected outputs before writing a prompt. Without this there is no way to tell whether a change helped.
- 03
Prototype against the evaluation set
Prompt design, retrieval strategy and model selection are iterated until scores clear an agreed bar. Costs and latency are recorded at every step.
- 04
Integrate and guard
Wire the feature into the product with schema validation, rate limiting, timeouts, fallbacks and logging. Ship it dark, then to a slice of traffic.
- 05
Monitor and iterate
Watch real usage, add the failures to the evaluation set, and tighten. AI features are never finished at launch, and the system is built to expect that.
The gap between a demo and a feature
Almost anyone can produce an impressive AI demo now. The demo works because the person running it knows which inputs to use. The feature has to work when a customer types something nobody anticipated, at nine in the morning, when the third party API is slow.
Closing that gap is mostly unglamorous engineering. What does the interface do while the model is thinking. What happens when the response does not parse. What happens when the answer is plausible and wrong. What stops a single user from spending two hundred dollars of tokens in an afternoon.
Every one of those questions has an answer in the build. That is the actual work, and it is why a feature takes longer than the demo suggested.
Evaluation is the part most projects skip
The single strongest predictor of whether an AI feature survives contact with users is whether the team built an evaluation set. Without one, prompt engineering is guesswork: someone changes a sentence, tries three inputs, decides it feels better, and ships a regression.
The set does not need to be large. Fifty well chosen cases covering the common path, the awkward edges and the inputs that should be refused will catch most regressions. It gets built before the first prompt, and it grows every time something fails in production.
This is also what makes model changes safe. When a faster or cheaper model appears, the question of whether to switch is answered by running the set, not by opinion.
Choosing a model, and changing it later
Model choice is treated as a configuration decision rather than an architectural one. Provider calls sit behind a single interface, so moving between Claude, OpenAI or a smaller local model is a change in one file rather than a rewrite.
In practice most workloads split. A large model handles the reasoning heavy path where quality matters most, and a small fast model handles classification, routing and extraction, which is where the volume is. That split is usually worth a large reduction in cost with no visible change in quality.
Questions
AI Integration questions we get asked
Which AI models do you build on?
Primarily the Claude and OpenAI APIs, selected per use case rather than by preference. Provider access sits behind one internal interface, so switching models later is a configuration change and can be validated by rerunning the evaluation set.
How do you stop the AI giving customers wrong answers?
Four layers. Retrieval grounds answers in your own documents rather than model memory. Output schemas are enforced, so malformed responses are rejected before display. Scope limits keep the assistant from answering outside its remit. Anything consequential goes through human review. The residual error rate is measured against the evaluation set and reported, not hidden.
What does an AI feature cost to run each month?
It depends almost entirely on volume and on which model handles which step. A support assistant on a few thousand conversations a month typically runs in the low tens of dollars. Cost projections come out of the prototype phase with real measured token counts, before you commit to shipping.
Can you work with our private or regulated data?
Yes, and the architecture is designed around it. Data can stay inside your infrastructure, retrieval can be restricted per user, and prompts and responses can be logged or deliberately not logged depending on your obligations. The specific controls are agreed in discovery rather than assumed.
Is a chatbot always the right AI feature?
Usually not. Chat is the most visible pattern and often the least valuable one. Classification, extraction, summarisation and search tend to deliver more with far less risk, because they run inside a workflow instead of freely conversing with a customer. Case selection deliberately happens before anyone commits to a chat interface.
Often paired with
- Full Stack DevelopmentCustom web applications and platforms built end to end, from schema design to the interface your customers use every day.
- AI Literacy TrainingRole specific, hands on training built around your real workflows, with a usable AI policy and a prompt library your team keeps.
- Business AutomationRepetitive work between your systems mapped, automated and monitored, with alerting so a silent failure never goes unnoticed.