New Primitives: Multi-Agent Systems, RAG, MCP

Overview

Three terms you’ll meet constantly. This topic is about what each one is for and what it costs — not how to implement it. Modules 4 and 5 go into mechanics; here you need enough to reason about structure.

RAG — retrieval-augmented generation

What it’s for: answering from information the model was never trained on. You retrieve relevant material from your own data, put it in front of the model, and ask it to answer from that.

What it’s actually solving is a knowledge-freshness problem. That framing matters, because it tells you when retrieval is not the answer — if the model’s reasoning is wrong rather than its facts, retrieval won’t help.

What it costs:

• Answer quality now depends on retrieval quality, which depends on how good your documentation is. Any projection that assumes a share of questions is answerable from the docs quietly assumes those docs are correct. If they aren’t, this fails in a way that looks like a model problem but isn’t.
• Every answer costs more, because you’re sending retrieved material along with the question.
• You now own a pipeline: keeping the index current as the source material changes. That’s an ongoing operational obligation, not a one-time build.

Agents and multi-agent systems

What it’s for: letting the system decide its own steps rather than following a fixed sequence. An agent can plan, use tools, check its own work, and loop.

You need this when the right sequence depends on what the system finds along the way — look something up, check availability, make a change, confirm.

A multi-agent system splits that across several specialised agents that coordinate — one planning, others executing, perhaps one checking the others’ work.

graph LR
  A["<b>Single call</b><br/>ask, answer<br/><i>predictable, cheap</i>"] --> B["<b>Chain</b><br/>fixed sequence<br/><i>still predictable</i>"]
  B --> C["<b>Agent</b><br/>decides its own steps<br/><i>flexible, harder to debug</i>"]
  C --> D["<b>Multi-agent</b><br/>several coordinating<br/><i>powerful, expensive,<br/>hard to reason about</i>"]

Increasing autonomy, left to right. Cost, latency and debugging difficulty all rise with it — so the honest default is the leftmost thing that works.

What it costs: this is where the probabilistic problems compound. An agent that takes five steps has five chances to go wrong, and the fifth step’s input is the fourth step’s output. Cost becomes variable and hard to predict. Reproducing a specific bad outcome is genuinely difficult.

The honest default: most problems don’t need an agent. Multi-agent especially is often reached for when a single well-designed call would do.

MCP — Model Context Protocol

What it’s for: a standard way for a model to reach tools and data. Without a standard, every connection between a model and a system is custom glue, and the glue multiplies.

Architecturally, MCP is a seam — a defined boundary between the model and everything it can touch. That’s the part worth caring about. It gives you a single place to ask what is this allowed to reach?, which is precisely where guardrails belong.

What it costs: a standard is a dependency and a constraint. It’s also young, and young standards change. Adopting it is a bet that consolidation is worth more than flexibility — usually right when the alternative is bespoke glue, but it is a bet.

Which primitives this initiative actually needs

RAG — yes, it’s the core. The product documentation and ticket history are exactly the kind of private, changing information a general model has never seen. But the 38% projection assumes those docs are correct and current, and nobody has verified that.

Agency — only partly. “Reschedule this job” genuinely needs it: look up the job, check technician availability, make the change, confirm. “How do I export a report?” needs retrieval and a single call — no agency at all. Applying an agent to both would pay the cost of autonomy where there’s nothing to autonomously decide.

MCP — yes, on security grounds. The agent needs to reach the scheduling system, the billing system for credits, and device management. Three custom integrations, each with its own permission handling, is three places to get security wrong. One standardised boundary is one place — and it’s where the guardrails from the previous topic attach.

How to hold these

Primitive	Reach for it when	Be suspicious when
RAG	The model needs facts it can’t know	Your documentation is poor — fix that first
Agent	Steps genuinely depend on what’s found	A fixed sequence would work
Multi-agent	Distinct specialities must coordinate	One agent would do, and you want it to be interesting
MCP	Several tools need reaching safely	You have exactly one integration

The pattern: each of these buys flexibility and charges you in predictability, cost, and debuggability. That’s the same trade you already know from distributed systems — these primitives just move it into a new layer.

Feeds the workbook

Your context diagram should show what the platform touches, including external model providers. At least two of those boundaries will make your compliance lead’s job harder — find them now.

Check your understanding

1. Documentation is mediocre in places. What does that do to a RAG-based business case, and what would you do first?
2. “How do I export a report?” versus “reschedule tomorrow’s failed jobs” — which needs an agent? Why?
3. What does a standardised tool boundary give you architecturally that three custom integrations don’t — beyond less code?

---

→ These all depend on the system being understandable — by people and now by machines. — AI-Readiness