RAG, Agents, Fine-Tuning, Governance: The Four Pillars of an Enterprise AI Dev Platform
When buyers ask "is your AI platform a RAG product or an agent product?" the answer is yes. Here is why all four pillars belong on one platform and how to choose between them per workload.

The fastest way to misjudge an enterprise AI platform is to evaluate it by its loudest feature. Buyers learn the categories — RAG, agents, fine-tuning, governance — and then ask the vendor to pick one. The honest answer is that a serious enterprise stack needs all four, because each one solves a problem the others cannot. This piece walks through what each pillar is for, how they share a base layer, and how to decide which one a given workload starts on.
Pillar 1: RAG Studio — grounding output in your own documents
Retrieval-Augmented Generation grounds a language model's response in a specific corpus of documents that the model never trained on. The model retrieves the relevant passages at query time, includes them in the prompt, and is instructed to answer only from what it retrieved. RAG is the lowest-risk way to put generative AI into an enterprise workflow because it solves the hallucination problem at the retrieval layer rather than asking the model to be careful.
The technical work is not the prompting — it is the retrieval. Hybrid search (lexical + dense vector) outperforms either method alone on enterprise documents because exact-string matching catches policy numbers, case IDs, and proper nouns that semantic search misses, while semantic search catches paraphrases. A reranker on top of the hybrid index lifts answer quality further, particularly for long-context queries.
Use RAG when the source of truth is documents (policy manuals, contracts, claim files, case law, knowledge base articles, internal wikis) and the cost of a wrong answer is high enough that "trained on similar things" is not good enough. Our managed product is RAG Studio, and the services equivalent is RAG Knowledge Base Setup.
Pillar 2: Agent Builder — orchestrating multi-step work
An AI agent is a workflow that loops: the language model proposes a tool call, a tool runs, the result feeds back into the model, the model proposes the next step, and the loop terminates on a stop condition. Agents are the right pattern when the work has multiple steps that depend on each other and on external systems — pulling a customer record, checking eligibility, drafting a response, filing the outcome. RAG answers one question; an agent completes a task.
Production agents need three things RAG does not. They need a typed tool catalogue so the model cannot call a tool with malformed arguments. They need a stop condition that does not depend on the model's discretion — a hard step budget and a human-in-the-loop gate for irreversible actions. And they need replayability: the entire trace of (prompt, tool call, result) tuples persisted so a failure can be reproduced, a regression can be debugged, and an audit query can be answered.
Use agents when the workflow is genuinely multi-step and the cost of building one-off integrations between systems exceeds the cost of letting a model orchestrate them. Our managed product is Agent Builder; the services equivalent is AI Agent Implementation.
Pillar 3: Fine-Tuning Ops — specialising the model itself
Fine-tuning continues training a base model on a curated dataset so that its weights better fit a specific domain, style, or task. It is the right pattern when the model needs to behave differently from its baseline — different tone, different output format, different vocabulary — in a way that no amount of prompting reliably produces. It is the wrong pattern when the problem is "the model does not know about my documents," because that is what RAG is for.
Production fine-tuning is mostly a data problem. The training set needs to be representative, deduplicated against the evaluation set, and screened for personal information that would breach Section 11 if used as training data without a basis. The evaluation harness needs to be in place before the first training run, because without it there is no way to know whether the next checkpoint is better or worse than the last.
The most common mistake is to reach for fine-tuning when RAG would solve the problem. Fine-tuning costs more, takes longer, is harder to update when the underlying data changes, and creates a model artefact that itself becomes subject to POPIA Section 11 because it now encodes information derived from personal data. Default to RAG; reach for fine-tuning when you can articulate why prompting and retrieval will not get you there.
Pillar 4: Governance Hub — the layer that turns the other three into a platform
Governance is the pillar buyers undervalue at procurement and over-spend on six months later. A Governance Hub gives the platform owner a single surface for the access controls, audit logs, evaluation metrics, bias monitoring, and explainability artefacts that the other three pillars produce. Without it, each cluster has its own log format and its own policy surface, and the compliance officer has to assemble the picture by hand.
The minimum viable Governance Hub answers four questions in one query: who used what, on which data, with what model, under which lawful basis. Anything that cannot answer all four in one query is not a Governance Hub — it is a logging system with marketing copy. The bias and explainability layer (Fairlearn for fairness metrics, SHAP for per-prediction attribution) sits on top of that base. Both are required outputs in our standard AI Governance & Ethics Audit.
Governance is also where the platform earns its place against a build-it-yourself alternative. A team building one cluster at a time will under-invest in governance until an incident forces it. A platform that ships all four pillars together cannot under-invest in governance because the other three pillars feed it.
RAG vs Fine-Tuning vs Agents — when to use each
| If the problem is… | Start with | Cost profile | Update cycle |
|---|---|---|---|
| Answer questions over our document corpus accurately | RAG | Low — embedding + storage + inference | Minutes (re-index) |
| Execute a multi-step workflow across our systems | Agents | Medium — agent loop + tool integration + observability | Hours (deploy new tool) |
| Produce output in our domain's tone, format, or vocabulary that prompting cannot reliably elicit | Fine-tuning | High — dataset curation + training + evaluation | Days to weeks (re-train) |
| The model must reason over data that changes daily | RAG (never fine-tune on it) | Low | Minutes |
| Prove to the regulator who used what, on which data, with which model, under which basis | Governance Hub | Built in (platform-level) | Continuous |
Why all four pillars share a base layer
Each pillar needs an identity layer, an observability layer, and an audit layer. If those are duplicated per pillar, the platform grows three operational burdens for every product capability it adds. The architectural commitment behind the AI Dev Platform is that the four pillars share one identity provider, one observability stack, and one POPIA-aligned audit log. That choice makes the Governance Hub possible — and Governance Hub is what makes the other three pillars defensible at the procurement table.
This is also why the four-pillar shape is not arbitrary. The pillars are the smallest set that covers the failure modes an enterprise AI deployment actually faces. RAG handles "the model does not know our content." Agents handle "the model cannot reach our systems." Fine-tuning handles "the model does not sound like us." Governance handles "we cannot prove what happened." Drop any one of them and the platform is missing a category of failure it will eventually have to answer for.
How to start
The fastest path into production is rarely the most fashionable one. Most enterprise AI projects we work on should start with RAG, instrument the Governance Hub against the very first retrieval, and only add agents when the workflow demands it. Fine-tuning comes last, if at all, because the cases that genuinely need it are narrower than the discourse suggests.
The cluster as a whole — RAG Studio in Q4 2026, Agent Builder in Q1 2027, Fine-Tuning Ops and Governance Hub through 2027 — is on the public roadmap. The strategy context is in the pillar piece, and the compliance posture that the Governance Hub is built around is in the POPIA deep-dive.