We design the system around the model.
AI projects rarely fail at the prompt. They fail at retrieval, at data quality, at evaluation, at latency and cost, and at what happens when the model is confidently wrong. That is systems architecture, and it is what George has been doing for twenty years.
The unglamorous truth about AI products
A language model is a dependency you call over the network. It is non-deterministic, it is metered by the token, it is slower than your database, and it will occasionally return something plausible and wrong.
Everything that decides whether your AI feature works in production is ordinary, difficult software architecture: what context you retrieve and how, how you measure whether an answer was good, what you cache, what you do when the provider is down, how you stop cost from scaling with your success. That is the work, and that is what we do.
From “should we use AI?” to a system in production
Engagements usually start at the top of this list and move down. You are welcome to stop after the first one.
AI opportunity assessment
A short, paid engagement that examines your product and your data, then tells you where AI creates value, where it merely creates cost, and what building it would take. You get a written plan. Sometimes the honest answer is “not yet”, and we will say so.
- Use-case shortlist, ranked by value and risk
- Data readiness review
- Build, buy or wait recommendation
AI system design
The architecture around the model: how context reaches it, how you know the output is good, what it costs per request, how fast it answers, and how the product degrades gracefully when the model or the provider fails.
- Retrieval and data pipeline design
- Evaluation harnesses and quality guardrails
- Cost and latency budgets
- Fallbacks, caching and graceful degradation
LLM features in existing products
Most of this work happens inside applications that already have users and revenue. We add the feature without destabilising what already earns money, a constraint that greenfield AI demos never have to respect.
- Retrieval-augmented generation over your own content
- Structured extraction and classification
- Agents and tool use, scoped so they cannot do harm
- Assistants and semantic search
Process and workflow automation
The least fashionable and most profitable category: the manual, repetitive, judgement-light work inside your business that a well-bounded model can absorb, with a human still holding the decisions that matter.
- Document and email processing
- Back-office and support workflows
- Human-in-the-loop review steps
Model and vendor selection
Models change every few months; the architecture around them should not have to. We keep the provider behind an interface, choose the cheapest model that clears your quality bar rather than the largest one available, and make switching a configuration change instead of a rewrite.
An architect, not a prompt engineer
Prompting is a skill you can learn in a fortnight. Knowing which part of a system will fall over under load takes rather longer.
Twenty years of production systems
High-traffic APIs, data models that survived real growth, and platforms delivered with no downtime. AI features live inside systems like these, or they never leave the demo.
You get the engineer, not an account manager
The person who scopes your project is the person who architects it and writes the code. Nothing is lost in the handover, because there is no handover.
Told plainly, including the bad news
If AI is the wrong tool for your problem, that is the advice you will get in week one, before the budget is spent. It is a cheaper conversation than the alternative.
Have an AI problem worth solving?
Tell us what you are trying to build. If it is a good fit we will say so, and if it is not, we will tell you that too.