Architecture

Enterprise AI Architecture

How enterprise AI systems are actually put together. Retrieval design, when to fine-tune instead, agent architectures, and migrating off a hosted API without breaking production.

The architecture decisions that matter in enterprise AI are rarely about which model to use. They are about how context reaches the model, what the system is allowed to do with the answer, and whether you can measure quality well enough to know when it slips.

This is the material aimed at the people who have to build and operate the thing, and who tend to be the ones asked whether a proposal is actually credible.

Common questions

Should we use RAG or fine-tune a model?

Retrieval for knowledge that changes, fine-tuning for behaviour that does not. If the requirement is that the system knows current facts from your documents, retrieval is almost always right, because retraining every time a document changes is impractical. Fine-tuning earns its place when you need a consistent format, tone or task structure the base model does not reliably produce.

What decides whether an enterprise RAG system works?

Retrieval quality, far more than model choice. A stronger model retrieving the wrong context still produces the wrong answer. Chunking strategy, the embedding model, how permissions are applied at query time, and whether you can measure retrieval quality separately from answer quality account for most of the difference between systems that work and systems that demo well.

How do we evaluate an AI system before production?

Build a held-out evaluation set with domain experts, define correctness specifically enough that two reviewers agree, and measure against the human baseline for the same task rather than against an abstract threshold. Evaluate retrieval and generation separately, or you cannot tell which one failed.

When do multi-agent architectures make sense?

Less often than the interest in them suggests. They fit when a task genuinely decomposes into steps with different tools and different success criteria. They are a poor fit when a single well-scoped call would do, because each additional agent multiplies the failure modes, the latency and the blast radius of a compromised step.

How do we migrate off a hosted API without breaking production?

Put an abstraction layer in front of the provider before you need it, build an evaluation set that runs against any backend, then move one workload class at a time behind a flag with both paths measurable. The common failure is treating it as a swap rather than a migration: prompts tuned against one model rarely transfer unchanged.

What is usually missing when a pilot cannot reach production?

Observability and evaluation. Pilots are judged by impression, production needs measurement. Systems that stall generally have no way to tell whether quality is degrading, no logging sufficient to reconstruct an interaction, and no agreed threshold that would trigger a rollback.

Want a second opinion on your own position?

We work with large organizations on private AI deployment, strategy, and governance. If you have a decision in front of you, that conversation is available.

Get in touch