Artificial Intelligence

The gap between an impressive AI demo and a dependable AI feature is almost entirely engineering. A demo answers the questions you thought of. A production system faces questions nobody anticipated, users who phrase things badly, documents that contradict each other, and the requirement to be right often enough to be trusted — and to fail safely when it is not.

What we build

• RAG pipelines — answers grounded in your documents, with citations so users can verify them.
• Internal assistants over policies, contracts, tickets or product documentation.
• Document processing — extracting structured data from invoices, forms and correspondence.
• Customer-facing assistants with defined scope, escalation to a human, and logging.
• AI agents that take actions in your systems, with permissions and an audit trail.
• Evaluation harnesses so model or prompt changes can be measured rather than guessed at.

What we insist on before launch

• An evaluation set. Real questions with known-good answers. Without it, “it seems better” is the only available measure.
• Grounding and citation. Answers point at the source, so users can check and you can debug.
• A refusal path. The system must be able to say it does not know. Confident wrong answers do more damage than gaps.
• Data boundaries. What goes to a model provider, what does not, and where it is processed — decided explicitly and written down.
• Cost modelling. Token cost per interaction at realistic volume, because this is where AI projects quietly become unaffordable.

Frequently asked questions

Do we need to train our own model?

Almost certainly not. For the overwhelming majority of business problems, retrieval over your own data with a strong general model is cheaper, faster to build and easier to update than fine-tuning — and it does not go stale when your content changes. Fine-tuning suits narrow, stable tasks with consistent formatting.

How do you stop it inventing answers?

By grounding responses in retrieved source material, requiring citations, constraining scope, and building an explicit path for the system to decline. You reduce hallucination to a manageable level through engineering; you do not eliminate it with prompt wording.

Is our data safe with a model provider?

That is a decision to make deliberately rather than inherit. Enterprise API tiers generally do not train on submitted data, but the right answer depends on your sector, your contracts and how sensitive the content is. Where data cannot leave your environment, we design for that constraint from the start.

How do we know whether it is working?

Against the evaluation set, plus the business measure it was built to move — deflected tickets, time saved per case, error rate against manual processing. If nobody can name that measure, the feature is not ready to be built yet.

How the engagement runs

• Scoping call, then discovery. We establish what you actually need before quoting. You approve scope before we write a line of code.
• Fixed price or capped time and materials. Tightly specified work suits a fixed price; genuinely new work suits a capped retainer. We recommend one rather than offering both and letting you guess.
• Weekly demos. You see working software every week, so nothing surprising turns up at the end.
• You own everything. Repositories, infrastructure and documentation transfer to you on payment. No vendor lock-in, no licensing you do not control.
• NDA as standard, usually before the first detailed call. We will often send one ourselves if you do not.

If you are planning an AI feature and want a straight assessment of scope, timeline and cost, tell us what you are building. We work with clients across the UK, EU and US.