How do we get an AI system into production and keep it there?
Production AI systems
Production AI systems are internal copilots, workflow agents, research agents, voice agents, multi-agent systems, and LLM middleware built to run unattended against real data. They are not prompt chains. The design work sits in data access, permissions, auditability, failure modes, human review, and reliability — the parts that decide whether a system survives contact with real operations rather than demonstrating well once.
The gap between a demo and a system
A demo has one happy path, a curated input, and a human watching. A production system has every input the business can generate, no one watching, and a consequence attached to being wrong.
Closing that gap is most of the engineering. It means deciding what happens when the model is unavailable, when the input is malformed, when the output fails validation, when a downstream system rejects a write, and when someone needs to know six months later why a particular decision was made.
What the design actually covers
- Data access and permissions
- What the system can read and write, acting on behalf of whom, and how that is enforced rather than assumed.
- Failure modes
- What happens on timeout, malformed output, rate limit, partial write, and downstream rejection — each one designed rather than discovered.
- Evaluation
- Regression suites that run when prompts or models change, so a quality drop is caught before users find it.
- Human review
- Where a person sits in the loop, what they are shown, and how their corrections feed back.
- Auditability
- A record of what ran, on which inputs, producing which output — the thing that makes the system answerable afterwards.
Safe by default
The engineering defaults matter more than the model choice: idempotent operations so a retry cannot double-write, dry-run modes so a change can be inspected before it lands, audit logs as a by-product rather than an afterthought, and kill switches that work.
These are unglamorous and they are the difference between automation that is clever and automation that is safe to depend on.
What you get
- Working system running against production data
- Evaluation and regression suites
- Human review paths and escalation routes
- Audit logging and observability
- Runbook and handover documentation
Start here if
- A prototype works but nobody will let it near production
- An AI feature shipped and quietly degraded
- There is no way to tell whether output quality has changed
- The system needs to write to a system of record
Copilots · Multi-agent · LLM middleware · Evals
How do you evaluate an AI system that has no single right answer?
By separating the parts that do from the parts that do not. Structure, schema, and factual grounding can be checked deterministically. Genuinely subjective quality is scored against a fixed set of graded examples, so the question becomes whether today's output is worse than last week's rather than whether it is perfect.
What happens when the model provider changes the model underneath us?
This is exactly what the regression suite exists for. Without one, a silent provider-side change is discovered by users. With one, it is caught on the next run and the routing layer can pin or reroute while the difference is assessed.
Related
Last reviewed · Tayyeb Mahmud, 1AYM