AI & agentic automation
AI that does a specific job, measurably well
Assistants over your own documents, agents that complete workflows, and extraction that empties an inbox — built with evaluation from day one, so you know whether it actually works.
We'll tell you honestly if a rule engine would do the job cheaper.
What applied AI means here
Applied AI is using language models to do a specific, scoped job inside your business — answering questions from your own documentation, pulling structured data out of unstructured files, drafting a first response, or completing a multi-step workflow with a human approving the result.
It is not a strategy deck, and it isn't a model we train from scratch. Nearly every worthwhile business use case today is built by combining a good general model with your data, your rules, and a way to measure whether the output is right. The engineering is in the retrieval, the guardrails and the evaluation — not in the model.
The honest framing: AI is very good at reading, summarising, drafting and classifying, and unreliable at arithmetic, at anything requiring guaranteed correctness, and at admitting when it doesn't know. Good systems are designed around that shape rather than in spite of it.
Where AI earns its keep — and where it doesn't
We run this test before quoting. Roughly a third of the AI enquiries we get are better solved another way, and we'd rather say so.
Good fit
High volume of unstructured text
Support tickets, contracts, CVs, emails, forms. Anything where a person currently reads something to decide what happens next.
Answers exist but are hard to find
The information is in a wiki, a policy PDF or six years of tickets, and people ask a colleague instead of searching.
A first draft saves most of the time
Responses, summaries, reports and proposals where a human edits rather than writes from scratch.
Tolerant of being occasionally wrong
A human reviews the output, or an error is cheap and visible. This is the single most important criterion.
Use something else
Deterministic rules would do it
If the logic can be written as conditions, write it as conditions. It's cheaper, faster, testable and it won't surprise you.
Arithmetic and reconciliation
Never have a language model do the sums. Have it find the numbers and hand them to code that can add.
Zero tolerance for error, no review
Anything where a wrong answer ships straight to a customer or a regulator without a human seeing it first.
You don't have the data yet
If the documents are scattered, inconsistent or nonexistent, the data work comes first. That's a data engineering project, not an AI one.
We have no incentive to oversell this — we'd rather build you a small thing that works than a large thing you switch off in six months.
What we build
Six patterns that cover most of what businesses actually need from AI today.
Internal knowledge assistants
Ask questions of your own documentation, policies and history, with citations back to the source so answers can be verified rather than trusted.
Document extraction
Turning invoices, contracts, forms and statements into structured data — with confidence scores and a review queue for the cases that need a human.
Agentic workflows
Multi-step automations where the model plans and calls your systems: triage a request, gather context, draft the action, and stop for approval before anything is committed.
Support automation
Draft replies, ticket classification and routing, and deflection of repetitive questions. Pairs with our chatbot service for the customer-facing side.
Evaluation harnesses
The part most projects skip: a test set, scoring, and a regression suite so you can tell whether a prompt or model change made things better or worse.
AI features in your product
Search, summarisation, drafting or classification built into software you already ship — including the cost controls and rate limits to keep it viable.
Prompting, RAG, or fine-tuning?
Three techniques, frequently confused, with very different costs. Most business problems are solved by the middle column.
| Prompt engineering | Retrieval (RAG) | Fine-tuning | |
|---|---|---|---|
| What it does | Instructs a general model carefully | Gives the model your documents at question time | Adjusts the model's weights on your examples |
| Best for | Style, format, general reasoning tasks | Answering from your own knowledge | A consistent narrow behaviour or format |
| Setup cost | Lowest | Moderate — pipeline and indexing | Highest — needs a labelled dataset |
| Updating knowledge | Rewrite the prompt | Re-index — new documents work immediately | Retrain the model |
| Can it cite sources? | No | Yes — this is its main advantage | No |
| Common mistake | Stuffing an entire manual into every prompt | Poor chunking, then blaming the model | Reaching for it before trying retrieval |
If someone proposes fine-tuning before you've tried retrieval, ask why. It's usually the more expensive answer to a question retrieval already solves.
How we keep it safe to deploy
Five controls that turn a demo into something you can put in front of staff or customers.
Grounding and citations
Answers are drawn from retrieved passages and show their sources. Anyone can check the answer rather than take it on faith, which is what makes adoption possible.
Refusal over invention
Systems are built to say "I don't have that" when retrieval comes back empty. A confident wrong answer costs far more trust than an admitted gap.
Human approval on actions
Agents that change data, send messages or spend money stop for a human first. Read-only autonomy is a very different risk profile from write autonomy.
Data boundaries
What is sent to a model provider, what is retained and where it is processed are decided explicitly and documented — which matters under DPDP and for any client with data-residency obligations.
Cost and rate controls
Token budgets, caching and per-user limits from day one. AI features that are viable in a pilot and ruinous at scale are a well-trodden failure.
How an AI project runs
Deliberately front-loaded with evaluation — the only way to know if it's working.
Use-case review
We run the fit test above against your actual problem, and estimate what a good result would be worth. Sometimes the outcome is that you shouldn't build it.
Evaluation set
Before building, we assemble real questions with known-good answers. This becomes the measure of whether the system works and whether changes help.
Prototype
A working pipeline over your real data within a few weeks, scored against the evaluation set. Real documents, not a curated demo.
Harden
Guardrails, cost controls, monitoring, fallback behaviour and the review queue. This is where most of the engineering actually lives.
Deploy & watch
Rolled out to a small group first, with logging of what people ask and where it fails — which is the best roadmap you'll get.
If the prototype doesn't beat the evaluation baseline, we stop and tell you. That's a cheap failure, and far better than a slow expensive one.
FAQ
AI questions
Will our data be used to train someone's model?
Not on the configurations we deploy. We use enterprise API tiers where the provider contractually does not train on submitted data, and we document exactly what leaves your environment. Where data cannot leave your infrastructure at all, we'll design around self-hosted models and tell you honestly what capability you give up.
Which model do you use?
It depends on the task, and we build so it can be swapped. Reasoning-heavy work, extraction and cheap high-volume classification have genuinely different best answers, and the answer changes every few months. Systems locked to one provider age badly, so we abstract that boundary.
How do you stop it making things up?
Ground it in retrieved sources, show citations, and build it to refuse when retrieval returns nothing relevant. Then measure hallucination rate against a fixed evaluation set so it's a number you track rather than an anxiety. You can't eliminate it entirely, which is why anything high-stakes keeps a human in the loop.
What does an AI project cost to run, not just to build?
Running cost scales with usage, and it's the part most proposals gloss over. We model it during scoping — tokens per interaction, expected volume, caching savings — so you see the monthly number before committing. For most internal assistants it's modest; for high-volume customer-facing features it needs designing for.
How is this different from your chatbot service?
The chatbot service is a productised, customer-facing conversational bot across messaging channels — quicker to deploy, packaged. This practice is custom AI engineering: assistants over your internal knowledge, extraction pipelines, agentic workflows and AI inside your own product. Many clients use both.
Do we need our data sorted out first?
Usually to some degree, and we'll be straight about it. Retrieval quality is dominated by how good and how well-organised your source material is — a model can't compensate for three conflicting versions of a policy. If the data work is the real project, we'll scope that first through our data practice rather than sell you an AI layer over a mess.
Related services
Describe the task you'd want AI to do
Be specific — who does it today, how often, and what happens when they get it wrong. That's enough for us to tell you whether it's a good fit.