What are RAG, AI agents, evals, and MCP?

What are RAG, AI agents, evals, and MCP?

RAG, agents, evals, and MCP are the techniques on the using side of AI: the standard parts a team assembles when it builds a product on a model it rents. None of them involves training anything. Each one names a way of getting a rented model to do reliable work inside real software.

The previous lesson split AI work into a small pool that builds models and a much larger pool that uses them. These four words describe what the using side actually does all day, which is why they fill job descriptions and resumes. A req that lists RAG and MCP is describing product engineering. A candidate who can talk through their evals has operated an AI feature with real users on it.

This lesson defines each technique, adds the words that travel with them, and ranks them from common skill to rare one.

What is RAG?

RAG stands for retrieval-augmented generation. It means finding the relevant parts of a company's own documents and handing them to a model along with the question, so the answer draws on that material.

The name describes the steps in order. Retrieval: search the company's documents for the pieces that match the question. Augmented: add those pieces to the prompt. Generation: the model writes its answer with the real material in front of it. Without this, a model can only answer from its training data, which contains none of the company's contracts, policies, or product docs and stops at a cutoff date. With it, a support assistant can quote the current refund policy because the policy was placed in its context window moments before it answered.

RAG is one of the most common AI features in production. Every product that answers questions over a knowledge base, a document store, or a help center is running some version of it. The engineering behind it is search plus databases plus APIs, which means it sits close to ordinary backend work, and developers with backend experience pick it up quickly.

What is the difference between a chatbot, a workflow, and an agent?

A chatbot answers questions in a conversation. An AI workflow runs a fixed sequence of steps that a person wrote in advance, with a model doing the work inside some of the steps. An AI agent is given a goal and chooses its own steps toward it. All three usually run on the same large language model. What separates them is who decides what happens next: the user in a chatbot, the builder in a workflow, the software itself in an agent.

The word "agent" borrows its older human meaning: a travel agent takes a goal and picks the steps. Give an AI agent "find every March invoice that failed to send and retry them," and it queries the database, reads the result, and decides its next move from what it found. Nobody scripted that sequence.

The line that matters for hiring is action. A chatbot's output is text, and a human decides what to do with it. An agent changes things: records get updated, emails get sent, tickets get filed. Software that acts in real systems needs permissions deciding what it may touch, error handling for the steps that fail, and testing for paths nobody predicted. That is why agent work carries more engineering weight than chatbot work on the same model, and why "built an agent" and "built a chatbot" describe different amounts of it.

Workflows sit between the two. They are the right build when a task is predictable and high volume, because a fixed sequence can be tested step by step and trusted at scale. When a resume says "built AI automations," a workflow is usually what it means, and the reliability habits behind one transfer to any production system.

What is an eval, and why does it signal maturity?

An eval is a repeatable test of an AI system's output quality. It plays the same role for AI behavior that automated testing plays for code: run the system against a set of known cases, score the results, and find out whether the latest change made things better or worse.

Evals exist because model output varies. The same feature can succeed on a task Monday and fail on it Tuesday, so a single passing demo proves very little. An eval runs the system against dozens or hundreds of real cases and reports a score, which turns "it seems better" into a number a team can watch. Change the prompt, rerun the eval, compare.

This is why evals signal maturity. A team gets to a working demo without them. A team keeps an AI feature healthy in front of paying customers only with them, because without a score, nobody can tell whether this week's change quietly broke last month's cases. A candidate who describes the evals behind their AI feature has operated it past the demo stage, and a team that runs evals has been through the part of AI work where things break quietly.

What are tool use and MCP?

Tool use is how a model reaches beyond text. A tool is one specific action a developer allows the model to trigger: search the web, query a database, send an email. The developer hands the model the list, the model picks from it, and the developer's code carries the action out. On its own a model can only read and write text. Tools are what turn its decisions into effects, and every agent is built on them.

MCP, the Model Context Protocol, is the standard way to connect those tools. Anthropic introduced it in November 2024 and released it as an open standard, and rival AI companies adopted it within months. Before it, every pairing of an AI product and a tool was custom work, rebuilt each time. After it, a tool wrapped in MCP once is reachable by any agent that speaks the protocol, the way one USB plug fits every port.

An MCP server is the wrapper itself: a small connector program that offers one tool or one set of data to any agent that connects. A payments company ships one so agents can look up transactions. Most MCP servers are thin layers over an API the company already had, so building one is well-scoped work at the scale of days or weeks.

Two facts follow from the history. Any MCP experience began in late 2024 at the earliest, so on every resume it means months rather than years. And a candidate who names MCP at all is working on the using side, wiring models into products.

What is a voice agent?

A voice agent is an agent that listens and speaks. Two steps wrap the usual machinery: speech recognition turns the caller's audio into text the model can read, and speech generation turns the model's reply back into audio. Everything in between is the same model, tools, and decision loop as a text agent. Phone support, appointment scheduling, and order taking are the common uses.

The audio wrapper is where the extra difficulty lives. On a phone call, a pause longer than about a second feels broken, so every part of the system gets tuned for speed. Callers interrupt mid-sentence, talk over hold music, and speak with accents on bad connections, and the system handles all of it live. A developer who has shipped a voice agent has solved real-time problems under hard constraints, on top of everything agent work already requires.

Which of these are rare skills?

Ranked from largest talent pool to smallest, using how far each skill sits from ordinary backend work.

RAG and workflows are the common end. Both are assembled from search, databases, APIs, and reliability habits that existed long before AI, so the pool of developers who have done them or can ramp into them fast is large. A req built around "answer questions over our docs" or "AI pipelines" draws from that wide pool, and strong backend candidates without the exact buzzword ramp quickly.

Chatbot work sits in the middle. The mechanics are common by now, and the skill that separates the good ones is evaluation discipline. Eval experience itself is the quiet differentiator across all of these: any developer can learn the technique, and the developers who have run evals against live traffic remain a minority, because that only happens on teams that shipped.

Agents are the newer and smaller pool. The patterns are still settling, production experience only dates from the last couple of years, and the boundary work around software that acts on its own is where most of the difficulty lives. Voice agents are the smallest pool of all: agent engineering plus real-time audio, two demanding skills in one req.

The ranking also reads in reverse. A req demanding years of MCP experience is describing something the calendar rules out. A req that lists RAG as a hard requirement is pricing a common, learnable skill as if it were rare, and the wider pool of backend developers meets it. What a company says it built with these parts is the next lesson.