Reference architecture

How a production AI system is put together

Most of a working AI system is not the model. It is the workflow that controls execution, the tools that reach real business systems, and the data and observability layer that makes the result auditable afterwards.

Flow controls the process. Crews perform specialised work. Agents hold defined roles. Tools connect AI to business systems. The application layer delivers the experience. Not every system needs crews, and many need a single agent or none at all — the architecture is selected against the business problem.
Layer by layer

What each layer is responsible for

And the failure each one prevents when it is present, or causes when it is not.

LayerResponsibilityFailure it prevents
ApplicationDelivers the experience: web, mobile, SaaS or API. Holds identity, permissions and the user-facing contract.AI capability with no way for a business to actually use it
Flow orchestrationSequencing, durable state, conditional routing, retries, validation and human approval. Written as deterministic code.Workflow logic hidden in a prompt, where it cannot be tested or reasoned about
CrewsGroups of specialised agents that collaborate on one part of the problem, under the orchestrator.One oversized agent trying to hold an entire process in a single context
AgentsA defined role, an explicit tool grant, a typed output contract, a timeout and a documented fallback.An agent that can take an action nobody authorised
Tools and integrationsEvery external effect: APIs, CRM and ERP, databases, documents, search. Permissioned and logged.A model that appears to act but changes nothing real
Model layerLanguage, embedding and vision models behind an adapter, selected per task and cost profile.Vendor lock-in, and a rewrite every time a model is replaced
Data and observabilityApplication database, vector store where needed, workflow state, logs, tracing and an append-only audit trail.A production incident nobody can reconstruct
Design rules

Decisions we apply on every build

Six rules, each visible in the public code or a live system on this site.

The model reads and drafts. It does not decide.

Extraction, classification and drafting are language work. Scoring against a rule, computing a figure or committing an irreversible action belongs in deterministic code.

Withholding beats guessing

A field the system is not confident about is returned empty and flagged, never filled with a plausible value. In retrieval, a relevance floor decides whether an answer is composed at all.

Human approval is a workflow state

Not a convention in a prompt. The run pauses, persists, and resumes on a person’s decision, with the approval recorded.

Accuracy is measured, not asserted

A held set of real cases, scored on every change, with precision and recall reported separately rather than as a single number.

Providers sit behind an adapter

Changing model or vendor is a configuration decision. One system we built runs two providers on a single orchestration layer.

Every run is reconstructable

Inputs, tool calls, latency and cost per execution. If it cannot be replayed, it cannot be debugged at two in the morning.

A worked example

The same rules, in code you can read

Our public retrieval system applies these decisions end to end: a grounding threshold that stops generation, filters applied inside the query, agents with documented fallbacks, and citations verified against live records.

Bring us your architecture

Sixty minutes on the system you have or the one you are planning, and an honest read on where AI belongs in it.

A 60-minute architecture review · no charge · the notes are yours either way