What does it actually take to build this?
Engineering.
Every project follows the same idea: the thin line, the simplest path that gets you a working result fast, then grows from there. Here is what that means in practice, from how a project is shaped to the tools we choose and why.
What does an engagement actually look like?
Weeks, not phases.
This is the typical path, not a template we force you into.
Opportunity assessment
- Workshops with the people doing the work, not just the sponsor
- A map of the process as it runs and the data as it is
- Ideas ranked for value, data readiness and risk
- The measure of success agreed and written down
The first thin line
- One process, end to end, on your data, inside your estate
- Tested offline against your real cases
- Shadow-run beside the current process where the decision matters
- Live, within agreed limits
Run and scale
- Monitoring, iteration and training your team to own it
- Another source, another process, another degree of autonomy
- Each on top of something already running
- Each only when the evidence has earned it
Which pattern, and when?
The solution patterns we use most often.
Not seven kinds of AI. Some are techniques, some are applications, some orchestrate the others. We choose from the problem backwards.
Search and retrieval
Finding the right thing in your own content, with the source shown.
- Internal knowledge search
- Product and content discovery
- The foundation under any assistant
Reading and extracting
Documents and messages turned into structured data.
- Classify, extract fields, route
- Invoices, contracts, forms, emails
- Most businesses hold more in documents than databases
Predicting and forecasting
What is likely to happen next.
- Demand, churn, propensity, no-shows
- Usually classical machine learning, not a language model
- The best-evidenced form of AI in business
Analysis and decision support
Business data turned into evidence for a decision.
- What changed, why, and what it is worth
- Patterns, drivers, segments, anomalies
- Often statistics rather than a model
Drafting and generating
First drafts in your voice, grounded in your material.
- Checked against brand and fact
- A person approves anything that leaves the building
- Never unreviewed output to customers
Assistants
Conversational access to what you already know.
- Grounded in your policies and records
- Cites its sources
- Hands over to a person when it should
Automation and workflows
The repetitive thing, done reliably.
- Fits when the steps are known and the same every time
- Costs the least of anything here; often no language model at all
- We insist on calling it a workflow. A model inside a fixed sequence is not an agent
Agents, honestly
Valuable where the work needs investigation.
- Fits when the work is investigation, tool use and adapting, usually behind the scenes
- Costs more: more engineering, more controls, more ways to fail
- We insist on bounded tools, evaluation, and a person signing off where a miss would matter
How do you know it works?
Nothing goes live untested. Nothing widens without evidence.
Before launch
- A test set drawn from your real cases, held back from development
- Normal cases, edge cases, ambiguous ones, known failures, and cases where the right answer is to hand over
- Thresholds agreed with the people who own the outcome
Into production
- Tested offline, at real volume
- Shadow-run beside the current process for a full cycle
- Live on a defined slice, then widened as the evidence earns it, not as the calendar says
In production
- Every run produces auditable telemetry, matched to how sensitive the system is
- Corrections from your team are reviewed before they change how the system behaves
- The performance report becomes part of your normal review
What does tested mean for each kind of system?
- SearchRetrieval quality: does the right thing come back, near the top, with its source.
- ExtractionPrecision and recall, by field, so you can see what it misses as well as what it gets wrong.
- PredictionForecast error against what actually happened, over a full cycle.
- AssistantsGroundedness and citation quality: is the answer supported by the source it cites.
- AgentsTask completion, and the rate of interventions and errors along the way.
The technical metric is not the point. Retrieval quality matters because it moves bookings; forecast error matters because it moves stock. We tie each system to the business number it is meant to move and track both.
What we will not do
Present a demo on a curated dataset as evidence. Publish a number that was not measured. Widen autonomy because the calendar says so. Or scope a programme across eight systems and call it a pilot. One narrow path can be tested against real cases; eight cannot.
What will your CTO ask?
Your estate, your controls, your call.
Five questions every technology lead asks before this goes anywhere near production. Short answers, then the detail.
Does it run in our estate, under our identity and access controls?
Yes, always. Your cloud tenancy, your identity provider, your access policies, with observability and cost controls from the first build.
Does our data leave?
Only if you choose a pattern where it does. Where data must not leave, we use a private model deployment or self-hosted open-weight models, where you have the compute to run them.
Can the model see things it should not?
No. Hosting stops data leaving; it does nothing to stop the wrong data arriving, so that is handled separately: permissions enforced at retrieval, sensitive fields redacted or excluded, and tools with their own permissions. Only approved sources are indexed.
Are we locked in to a model or a vendor?
No. Models are chosen per task and can be swapped. The evaluation harness that proves a swap is safe is yours to keep.
Can we see what it did, and what it cost?
Yes. Auditable telemetry appropriate to the sensitivity of the system, and cost controls per model, from day one. Handover assumes you will own it: run-books, monitoring, the evaluation harness. Dependency on us is not the aim.
How much does it do on its own?
You decide. The evidence moves the dial.
- 1The system informs. A person decides and acts.
- 2The system proposes. A person approves each one.
- 3The system acts on low-risk work. A person reviews the exceptions.
- 4The system acts within policy. It stops and hands over at the edge.
Where a system sits depends on how well it has measured and on what a mistake would cost: the damage, how fast you would notice, and whether it can be undone. Earned by evidence, bounded by consequence.
What do you build with?
We pick per task, and we will tell you why.
One model for long-document reasoning, another for cheap high-volume classification, an open model where data cannot leave your environment and you have the compute to run it. The choice is part of the work, not a house preference.
Foundation models
Claude, GPT, Gemini, and open-weight models including Llama, Mistral and Qwen.
Access and hosting
Direct APIs, plus Azure AI, AWS Bedrock and Google Vertex where the model must sit inside your existing cloud contract. Self-hosting via Ollama or vLLM.
Retrieval and knowledge
Embeddings from OpenAI, Cohere and Voyage. Vector stores including pgvector, Pinecone, Weaviate and Qdrant. LangChain, LlamaIndex, or plain code.
Agents and orchestration
Anthropic and OpenAI agent SDKs, LangGraph, CrewAI, and platform-native agents such as Agentforce and Copilot Studio.
Evaluation and observability
Langfuse, LangSmith, Braintrust, Promptfoo, Arize. This is how the measurement claim is kept.
Classical ML
scikit-learn, XGBoost, Prophet, Python and SQL. Propensity, churn and forecasting are mostly this, not language models.
Where do I start?
Any of that need checking?
Send us the questions your team would ask. We will answer them properly rather than send a capability deck.
