Flagship
Custom AI Solutions
AI agents, LLM integration and intelligent automation built for your data and your workflows — not a wrapper around someone else’s demo.
Most AI projects stall in the gap between a promising prototype and something a business can actually depend on. The demo works; the rollout does not. What is missing is rarely the model — it is the evaluation harness, the data pipeline, the failure handling, and the humans who need to trust the output.
That gap has a specific shape. A prototype is judged by whether it impressed someone in a meeting. A production system is judged by what it does on the inputs nobody anticipated: the malformed PDF, the customer who writes in three languages at once, the request that arrives while the provider is rate-limiting you. Prototypes are optimised for the happy path because the happy path is what gets demonstrated. Production is mostly everything else.
We build AI systems the way we build any production system: with clear boundaries, measurable behaviour, and a path to change them safely. That means retrieval you can inspect, prompts under version control, evaluations that run in CI, and fallbacks for the day the provider has an outage. When output quality drops after a model update — and it will — you should find out from a failing test, not from a customer.
We are model-agnostic by default. The right choice depends on your latency budget, your data residency constraints, and what you are willing to spend per call — not on what is trending this quarter. For a lot of tasks the honest answer is that a smaller model, or no model at all, does the job for a fraction of the cost. We would rather tell you that than bill you for inference you did not need.
The other half of this work is deciding where a human stays in the loop. Full automation is the right answer for reversible, low-stakes, high-volume decisions. It is the wrong answer when a mistake is expensive to undo. Getting that boundary right matters more to the outcome than any amount of prompt tuning.
Agents, specifically
A chatbot answers. An agent acts — which is why it needs different engineering.
Most of what is sold as an agent is a chatbot with a plugin attached. The distinction that matters is not how it sounds in a demo. It is what happens when it is wrong, and who finds out.
- 01
It plans, so it can plan badly
An agent breaks a goal into steps and chooses the next one from the result of the last. That is the capability and the risk in a single sentence: a wrong step early becomes the input to every step after it. The mitigation is structural rather than textual — a defined set of transitions, a budget of steps, and an abort that raises a human instead of retrying forever.
- 02
It uses tools, so it has a blast radius
The moment a model can call your API it can also call it wrongly. The first question worth asking is not what the agent can do; it is what the single worst action in its toolset would cost you to undo. That answer decides which tools it gets, which ones require confirmation, and what it is allowed to touch before a person has seen the result.
- 03
It runs unattended, so you find out late
A copilot is wrong in front of somebody who notices. An agent is wrong at 2am, in a queue, forty times. That moves most of the engineering onto observability: a trace for every run, the cost of each one, and evaluations in CI so a prompt change that degrades a step fails a build rather than a customer.
- 04
The human-in-the-loop boundary is a design decision, not a setting
Full autonomy is the right answer for reversible, low-stakes, high-volume work and the wrong one where a mistake is expensive to undo. No amount of prompt tuning moves that line. Deciding which actions pause for approval affects the outcome more than the model you pick, and it is usually settled in the first week or regretted later.
What is included
- Discovery: what the system must do, and what would make it a failure
- Data preparation, chunking and retrieval design
- Prompt and tool design, versioned alongside the code
- An evaluation suite that runs in CI on every change
- Human-in-the-loop review flows where the stakes require them
- Observability: traces, cost per operation, quality over time
- Fallback behaviour for provider outages and rate limits
- Handover documentation and a runbook for whoever operates it
What we do not do
- Training foundation models from scratch — almost nobody needs this, and if you do, you need a research lab rather than us
- Chatbots bolted onto a website with no defined job
- “AI strategy” engagements that produce a slide deck and no working system
- Projects where the data required does not exist and nobody is willing to create it
How the work runs
- 01
Establish the evaluation first
Before building anything we agree how we will know it works: a set of real inputs with expected behaviour. This is unglamorous and it is the single strongest predictor of whether the project succeeds.
- 02
Build the thinnest end-to-end path
One complete slice through the system — ingestion to output — before adding breadth. It exposes the integration problems while they are still cheap to fix.
- 03
Harden against the messy cases
The malformed inputs, the timeouts, the ambiguous requests. This phase is usually longer than the first two combined, and skipping it is why prototypes stay prototypes.
- 04
Instrument, then hand over
Cost, latency and quality visible on a dashboard your team reads. Runbooks for the failure modes we know about, and a documented path for the ones we do not.
Where we have done this
One project you can read in full.
Shipped with
- React
- TensorFlow.js
- SVG
- Firebase
Taken from the projects above, not from a list of things we have read about.
Capabilities
- AI agents and tool-using workflows
- LLM integration and prompt engineering
- Retrieval-augmented generation (RAG)
- Document extraction and classification
- Intelligent process automation
- Evaluation harnesses and regression testing
- Model selection, benchmarking and cost modelling
- Private and on-premise deployment
- Vector database design and tuning
- Semantic search
- Fine-tuning and adapter training where it earns its cost
- AI feature integration into existing products
Questions we get asked
How long before we have something in production?
For a well-defined first use case, typically eight to twelve weeks from kickoff to production, with something usable to look at within the first three. Projects that take substantially longer usually do so because the required data turned out not to exist in a usable form — which is why we look at your data before quoting a timeline rather than after.
Which models do you use?
Whichever fits the constraints. We benchmark candidates against your evaluation set and show you the trade-off between quality, latency and cost per call. The architecture keeps the provider swappable, so a better or cheaper option later is a configuration change rather than a rewrite.
Can this run on our own infrastructure?
Yes. Open-weight models can be deployed in your cloud account or on-premise, which is often the answer where data residency or regulatory constraints apply. Expect a higher infrastructure cost and lower ceiling on quality than the frontier hosted models — we will quantify that trade-off for your specific case rather than asking you to guess.
How do you stop it producing wrong answers?
You cannot reduce that risk to zero, and anyone who tells you otherwise is selling something. What you can do is measure the rate, ground answers in retrieved sources the user can check, constrain the system to a defined job, and route low-confidence cases to a human. We design for the failure being visible and recoverable rather than silent.
What do you need from us?
Access to representative data, and a person on your side who knows what a good answer looks like. That second one matters more than it sounds — the evaluation set is built from their judgement, and no amount of engineering compensates for its absence.
What does it cost to run once it is live?
It depends on volume and model choice, and we model it explicitly during discovery so the number is not a surprise. Running cost is a design input for us, not an afterthought: it changes what architecture makes sense, and there are usually large savings available from caching, routing simple cases to smaller models, and not calling a model where deterministic code would do.