Overview
Most AI projects fail in the same place. They start from the model — which one, how large, whose API — when the question that actually decides whether the thing works is duller than that: what task is being handed over, what does a correct answer look like, and who finds out when it is wrong.
We build AI into systems that already exist and already matter: the enquiry inbox, the support queue, the document pile, the internal tool nobody enjoys using. The work is scoped one task at a time, wired to your own data, and judged on whether it does that task — not on how well the demo went.
What we build
- AI agents and agentic workflows — multi-step processes where the model plans, calls your tools and APIs, and hands back to a person at the points you choose. Bounded on purpose: an agent with a narrow remit and clear stopping conditions is one you can put in front of customers.
- Chatbots and support assistants that answer from your own documentation, pricing and policies instead of improvising, escalate to a human with the conversation intact, and log every exchange so you can see what people are really asking for.
- RAG search over your own content — retrieval-augmented generation across contracts, manuals, tickets and internal wikis, with citations back to the source paragraph so an answer can be checked rather than trusted. Why that matters.
- Document and data extraction — invoices, purchase orders, forms, CVs and reports turned into structured records your systems can act on, with confidence thresholds that route the uncertain ones to a person.
- AI features inside your existing product — drafting, summarising, classification, tagging, semantic search and recommendations, added to the application you already run rather than sold to you as a second one.
- Workflow automation connecting the systems between which somebody is currently copying and pasting: CRM, email, spreadsheets, ERP and helpdesk.
How we scope it
An AI build starts with a week of unglamorous work: which task, on what data, judged how.
- One task, defined narrowly. “Answer questions about our return policy” is buildable and testable. “An AI assistant for the business” is neither.
- Your data, assessed honestly. If the source documents contradict each other, no model will resolve that for you — and it is worth knowing in week one rather than month three.
- An evaluation set before a line of prompt. A few dozen real questions with known-good answers, so a change can be shown to be an improvement instead of argued about.
- A person in the loop where being wrong is expensive — and nobody in the loop where it is not, because approval queues that never get cleared are how automation quietly stops paying for itself.
Where AI does not belong
Part of this work is telling clients not to buy it. A rules engine, a search index or a better-designed form beats a language model on any task with a right answer and a fixed set of inputs — cheaper, faster and auditable. We will say so. What these models are genuinely good at is the messy middle: unstructured text, ambiguous requests, and work that used to require somebody to read something first.
The stack
Model choice follows the task and the budget: hosted APIs where quality and latency matter most, smaller open models where the data has to stay in your own environment or the volume makes per-token pricing untenable. Around them sits ordinary engineering — Python or Node services, a vector store, queues, caching, retries and rate limits — deployed on infrastructure that can be monitored like anything else you run in production. Where the AI belongs inside a larger build, it is scoped with the rest of the custom software work.
What you get
- A working feature in your own environment, not a proof of concept in a notebook.
- The evaluation set and its numbers, so quality is a measurement rather than an opinion.
- Cost per request, measured — the line item that decides whether an AI feature survives its first busy month.
- Logging, prompt versioning and a rollback path, because providers change their models underneath you.
- Documentation your own developers can work from, and a handover if you would rather run it yourselves.
Getting started
Most engagements open with a short discovery: we look at the task, the data behind it and what “correct” means, then come back with what is worth building, what it will cost to run, and what to leave alone. If it turns out you do not need AI for this one, that is a useful answer too. Tell us what you are trying to automate.