The gap between an AI demo and an AI system in production is mostly engineering: deterministic outputs, evaluation, failure handling, cost control and observability. That is the work.
A prototype that works in a notebook is not the hard part. The hard part is what happens when the same system runs thousands of times a day against real inputs, produces a wrong answer, and nobody notices until a customer does. Almost all of the engineering effort in a production AI system is in the parts that are not the model.
You have AI features committed and need them built to the same standard as the rest of your platform — with the same expectations around reliability, observability and cost.
You need to know what can be shipped credibly and what the quality bar actually is, rather than discovering the limits after launch.
AI is central to your product thesis and you need engineering judgement about what is achievable, applied to your specific case rather than demonstrated on a toy problem.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
The distance between prototype and production is where most AI investment is currently lost. The prototype is often 20% of the work and looks like 80% of it.
A feature that is usually right is, from the user's perspective, a feature that cannot be relied on. The tolerance for unpredictability is far lower than teams expect.
Per-request cost that is negligible in testing becomes a material line item at production volume. It is a design constraint, and it is much cheaper to design for than to retrofit.
Each of these is work we carry out, not an area we advise on.
Integrating model capabilities into an application that already has users, data and constraints — rather than building a separate AI product alongside it.
Downstream code needs to be able to rely on what comes back. Constrained output formats, validation and deterministic fallbacks are what make an AI component usable by the rest of a system.
You cannot improve what you cannot measure. We build evaluation sets from real cases so prompt and model changes can be assessed against evidence rather than impression.
Define what the system does when it is uncertain, when it is asked something out of scope, and when the model provider is unavailable. An AI system without a defined failure mode has an undefined one.
Instrumentation over inputs, outputs, latency, cost and failure rates, so the system's behaviour in production is visible rather than assumed.
Model selection, caching, batching and prompt design treated as cost decisions, because they are. Sustainable unit economics are a requirement of the design, not an optimisation afterwards.
For many workflows the correct architecture is AI-assisted rather than autonomous. Deciding where the human belongs is a design decision with a large effect on both quality and cost.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Before design, establish what happens when the system is wrong, how expensive that is, and who notices. This determines how much validation, how many guardrails and how much human oversight the system needs — and it varies enormously between use cases.
An evaluation set drawn from real inputs turns AI development from opinion into engineering. Without one, every decision about prompts and models is a guess, and every regression is invisible.
Treat the model as an unreliable dependency and design the interface accordingly — validated schemas, defined fallbacks, and no assumption that a response is well-formed.
Observability is built in from the start rather than added after an incident. Cost and behaviour are both unknowable without it.
Decide what the system does when uncertain, unavailable or out of scope — and make that a user-facing experience that has been designed, not an error state that was never considered.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
A four-week automated publishing engagement on Facebook. The objective was not to increase posting volume for its own sake but to establish whether consistent automated output could expand reach beyond the existing follower base. It did — and the mechanism by which it did was more interesting than the headline growth.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
See AI Automation for scheduled, notification and summarisation workflows.
See the AI Quality Engineer solution.
When retrieval is the right answer to the problem, which it often is not. Retrieval adds a dependency, a failure mode and a latency cost, and it is frequently reached for when better prompt structure or a smaller corpus would have been sufficient. We will say so when we think it is unnecessary.
Whichever fits the requirement, and we keep that decision reversible. Model capability and pricing change quickly, so the architecture should make substitution cheap rather than betting on one provider.
Yes, and that is a common starting point. The most frequent gap in an existing implementation is the absence of an evaluation set, which makes it impossible to know whether a change improved anything. That is usually the first thing we build.
As a design constraint from the start, not a later review. What data reaches a model provider, under what terms and with what retention is an architectural decision, and it constrains which models and which deployment patterns are viable. We establish that before designing anything.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.