What is RAG in simple terms?

Before the model answers, the system searches a document store for text relevant to the question and pastes the best matches into the prompt. The model then answers using what was fetched instead of only what it memorized in training.

How is RAG different from MCP?

RAG is a technique: retrieve text, add it to the prompt, generate. MCP is a protocol: a standard way for agents to call tools and take actions on live systems. They compose: a RAG pipeline is often exposed to agents as an MCP tool.

Is RAG enough for keeping AI agents aligned with team decisions?

No. Retrieval ranks text by similarity, not by status: it can't tell a binding decision from a rejected proposal or a superseded doc, it can't retrieve a decision nobody wrote down, and it can't stop code that conflicts with one from merging.

RAG (Retrieval-Augmented Generation)

RAG is a technique where a system retrieves relevant documents and adds them to the model's prompt before it answers, grounding output in fetched text.

Retrieval-augmented generation (RAG) is a three-step loop: retrieve documents relevant to the query (usually via embedding similarity search), augment the prompt with them, and generate the answer from that combined context. The model responds using fetched information instead of only what it absorbed in training.

What RAG is good at

Unstructured knowledge at scale. Support articles, wikis, past tickets, policies: corpora far too large for any context window, where "find the passages that probably matter" is exactly the right operation. It's cheaper than fine-tuning and the knowledge updates by re-indexing, not retraining.

A worked example

A support assistant gets the question "Can I change my billing date?"

Retrieve. The question is embedded and compared against an index of help-center articles. The top three matches come back, one of them titled "Changing your billing cycle."
Augment. Those passages are inserted into the prompt above the question.
Generate. The model answers from the passages, ideally citing the article, instead of guessing from training data.

Swap the help center for a repo's design docs and the question for "how do we handle tenant isolation?" and you have RAG for a coding agent.

RAG vs MCP

RAG is a technique; MCP is a protocol. RAG moves text into a prompt before generation; MCP lets an agent call live tools mid-task and take actions, not only read. They compose rather than compete: a common pattern is a RAG pipeline sitting behind an MCP tool. The full comparison is in MCP vs RAG: when to use each.

The limit for decisions

RAG treats everything as text to rank by similarity. Decisions need more than that:

No approval status. A rejected proposal and an approved decision are equally retrievable. Similarity search can't tell which one binds.
No freshness guarantee. The superseded design doc often outranks the Slack message that overturned it, because older docs are longer and better written.
Nothing to retrieve. A decision made in a meeting and never written down isn't in any index. Retrieval can't fix capture; that's decision drift.
No enforcement. Retrieval informs the prompt; it can't flag the pull request that conflicts with a decision.

That's the gap Lockstep works in: decisions captured at the source, human-approved, and served to agents over MCP as structured records with status, not passages ranked by similarity. If your decisions are scattered across tools today, start with a single source of truth for product decisions; the fields worth recording are listed in what a decision register should store.