RAG, MCP and Agents: The Map Every Developer Needs Before Building AI Features.

First: A way to Think About All of This.

Before we get into specific concepts, here's a simplified mental model that I've used to keep the concepts as simple as possible, because it makes all the distinctions much clearer.

Imagine you're bringing in a brilliant external consultant. Smart, well-read, genuinely capable. But they've never met your company before. They know nothing about your products, your customers, your history, your systems. Left to their own devices, they'll give you generic advice at best, and confidently wrong advice at worst.

Every concept in this post is a layer you add to make that consultant more useful:

• RAG gives them all your company documentation to read before the first meeting. Now they know your products, your policies, your history.

• MCP gives them actual access to your systems - your booking platform, your CRM, your database - so they can do things, not just advise.

• Agents means you hand them a goal and trust them to figure out the steps themselves.

Keep that in mind as we go through each one.

RAG: Giving AI Your Data.

What it is: Retrieval-Augmented Generation. The name is a mouthful but the concept is refreshingly simple: before the AI generates a response, it retrieves relevant information from your data and uses that as context.

Without RAG, an AI model only knows what it was trained on - which almost certainly doesn't include your product documentation, your customer records, or your company's internal knowledge base. With RAG, you give it access to that information at the exact moment it needs it.

This is the most immediately useful concept for most applications. Knowledge bases, documentation search, customer support assistants, internal tools that actually answer questions rather than guessing - all of these are RAG in some form.

How it works (the short version): Your content gets converted into embeddings - numerical representations of meaning, stored in your database. When a user asks a question, that question also becomes an embedding, and you find the stored content that's most mathematically similar. That retrieved content gets passed to the AI alongside the user's question, and the AI generates an answer grounded in your actual data rather than fabricating one.

The magic is semantic similarity. Search for "how do I cancel?" and it finds documents about "booking cancellation policy" even if those exact words don't appear in the query.

In Laravel: The Laravel AI SDK has this built in. You generate embeddings using Str::of($content)->toEmbeddings() , store them in a vector column in your database, and retrieve semantically similar content using the SimilaritySearch tool.

 1<?php
 2 
 3use Illuminate\Support\Str;
 4 
 5// Index your content — queue this, it involves an API call
 6$article->embedding = Str::of("{$article->title}\n\n{$article->content}")->toEmbeddings();
 7$article->save();
 8 
 9// Query semantically at runtime — pass the string directly, Laravel embeds it automatically
10$relevant = KnowledgeBaseArticle::query()
11    ->whereVectorSimilarTo('embedding', $userQuery)
12    ->limit(5)
13    ->get();

No full-text search configuration. No Elasticsearch cluster. Just meaning-based retrieval against your existing database.

MCP: Giving AI Your Tools.

What it is: Model Context Protocol. This one trips people up because the name sounds abstract, but the concept is concrete. MCP is an open standard that defines how AI models interact with external tools - how they call an API, query a database, take an action in your system.

Think of it as USB-C for AI integrations. Before USB-C, every device needed a different cable. Before MCP, every AI integration needed its own custom code. MCP standardises the interface so any AI client that speaks the protocol can connect to any server that implements it.

The thing that makes this genuinely interesting for application developers isn't just using MCP to connect your AI to external tools -it's the other direction. Your application becoming something AI can use. Your booking system, your inventory management, your customer platform - these can all become AI-native interfaces that any MCP-compatible client can interact with through a standardised, controlled interface.

We've been in conversations with a client about exactly this. They want to open up their booking system via MCP - so that AI assistants and AI-powered tools can search availability, check pricing, and initiate reservations through a proper interface, rather than having humans navigate the application manually on behalf of AI recommendations. The booking logic stays exactly where it is in Laravel. MCP is just the standardised door.

In Laravel: The official laravel/mcp package (built by the Laravel team, just hit v1.0) gives you a clean class-per-tool structure, Artisan generators, and first-class testing support.

 1<?php
 2 
 3// php artisan make:mcp-tool SearchAvailabilityTool
 4 
 5use Illuminate\Contracts\JsonSchema\JsonSchema;
 6use Laravel\Mcp\Request;
 7use Laravel\Mcp\Response;
 8use Laravel\Mcp\Server\Attributes\Description;
 9use Laravel\Mcp\Server\Tool;
10 
11#[Description('Search for available booking slots on a given date. Returns available options with times, capacity, and pricing. Use when the user wants to find or check availability.')]
12class SearchAvailabilityTool extends Tool
13{
14    public function handle(Request $request): Response
15    {
16        $validated = $request->validate([
17            'date'       => 'required|date',
18            'passengers' => 'integer|min:1',
19        ]);
20 
21        $slots = Booking::query()
22            ->whereDate('departure_date', $validated['date'])
23            ->where('available_capacity', '>=', $validated['passengers'] ?? 1)
24            ->available()
25            ->get()
26            ->map(fn($b) => [
27                'id'              => $b->id,
28                'time'            => $b->departure_time->format('H:i'),
29                'available_seats' => $b->available_capacity,
30                'price_per_person' => $b->price_per_person,
31            ]);
32 
33        return Response::structured($slots->toArray());
34    }
35 
36    public function schema(JsonSchema $schema): array
37    {
38        return [
39            'date' => $schema->string()
40                ->description('The date to search (YYYY-MM-DD)')
41                ->required(),
42            'passengers' => $schema->integer()
43                ->description('Number of passengers')
44                ->default(1),
45        ];
46    }
47}

You register tools in a Server class and expose it in routes/ai.php :

1<?php
2 
3// routes/ai.php
4Mcp::web('/mcp/booking', BookingServer::class)
5    ->middleware(['auth:sanctum']);

Any AI that speaks MCP can now call search_availability and get structured, usable results back. Your existing application logic doesn't change.

Agents: Letting AI Reason.

What it is: An AI agent is a system that can plan, decide, and chain actions to achieve a goal-rather than simply responding to a single question.

The distinction matters. A standard LLM call is question in, answer out. An agent is goal in, and then the AI decides what steps to take, what tools to call, in what order, and what to do with the results -iterating until it achieves the goal or reaches a defined limit.

We've been shipping agents into production applications for the past several months. A lead qualification agent that retrieves contact information, scores it against criteria, and updates the CRM. A document processing agent that reads uploaded files, extracts structured data, and flags anything needing human review. Once you've built a couple, you start to see clearly where agents genuinely earn their complexity - and where they don't.

In Laravel: The Laravel AI SDK structures agents as clean, testable classes.

 1<?php
 2 
 3use Laravel\Ai\Contracts\Agent;
 4use Laravel\Ai\Contracts\HasTools;
 5use Laravel\Ai\Promptable;
 6 
 7class DocumentProcessingAgent implements Agent, HasTools
 8{
 9    use Promptable;
10 
11    public function instructions(): string
12    {
13        return 'EOT'
14            You process uploaded documents and extract structured information.
15 
16            Rules you must follow:
17            - Always extract text before attempting to validate or save anything
18            - If any required field is missing or ambiguous, flag for human review — do not guess
19            - If the document type is unrecognised, flag for review and stop immediately
20            - Never process the same document twice — check first
21            - If a tool returns an error twice, flag for review and stop
22        EOT;
23    }
24 
25    public function tools(): iterable
26    {
27        return [
28            new CheckAlreadyProcessedTool(),
29            new ExtractDocumentTextTool(),
30            new ValidateExtractedDataTool(),
31            new SaveToRecordTool(),
32            new FlagForHumanReviewTool(),
33        ];
34    }
35}
36 
37// Dispatch from a queued job
38$agent = new DocumentProcessingAgent();
39$response = $agent->prompt("Process document ID {$document->id} and extract the required fields.");

The agent decides which tools to call and in what order. It adapts based on what each tool returns. If the document is unrecognised, it calls FlagForHumanReviewTool and stops - it doesn't need to be explicitly programmed for every case.

Beyond the Big Three.

RAG, MCP, and agents get most of the headlines, but there are several other concepts worth understanding if you're serious about building with AI.

Context Engineering.

Is probably the most underrated of all of them. It's the evolution of what used to be called "prompt engineering" - except it's much bigger than tweaking a prompt. Context engineering is the discipline of designing everything the AI sees at inference time: your system instructions, what data you retrieve, what conversation history you include, what tools you make available. When you write a CLAUDE.mdfile for a project, you're doing context engineering. When you define your agent's instructions carefully, you're doing it. The quality of your context determines the quality of the AI's output far more than model choice. We'll have a whole post on this.

Guardrails.

These are the constraints you put on AI behaviour in production. What the AI should never say, never do, never assume. In your agent class, this might be explicit instructions ("never modify existing records without a prior validation step"). In a user-facing feature, it might be content filtering, output validation, or hard limits on actions that require human confirmation. Guardrails aren't optional once you're in production.

Structured Output.

Is something you'll reach for quickly once you start building real features. Instead of getting free-form text back from the AI, you define a schema and the AI returns valid, typed data that maps to it. The Laravel AI SDK's HasStructuredOutput interface makes this clean. For any feature that consumes AI output programmatically - rather than just displaying it to a user - structured output is essential for reliability.

Embeddings.

These deserve a mention in their own right. They're the vector representations that power RAG - a way of encoding meaning mathematically. Similar meaning produces similar vectors. The key insight: embeddings represent meaning, not keywords. This is what makes semantic search genuinely different from search you've built before.

AI Observability.

Is the bit most teams discover they need after they've shipped something. Standard application monitoring - request latency, error rates, exception tracking - doesn't tell you whether your AI is hallucinating, whether your retrieval is returning irrelevant documents, or whether your agent is taking twenty steps when it should be taking five. There are tools for this (Langfuse is widely used), and we'll cover this properly in its own post.

Our Honest Take.

The most common mistake we've seen - and made ourselves, to be fair - is trying to add all three layers at once before establishing whether you actually need them.

Most applications that "need AI" need RAG. They need to answer questions about their own data intelligently, without hallucinating. That's it. Start there.

Add MCP when you need AI to take actions in your system, not just answer questions about it. When your application needs to be callable by AI interfaces beyond your own, that's the MCP conversation.

Add agents when you have a workflow that requires autonomous multi-step reasoning - where the AI needs to make decisions about what to do next based on what it found in the previous step. If you can predict the steps in advance and they're always the same, an agent is probably overkill. Build a pipeline instead.

These layers compound. A genuinely sophisticated AI feature might use all three - RAG for context, MCP for system access, agents to orchestrate. But you earn that complexity. You don't start there.

What We're Watching.

Multi-agent systems - where specialised agents collaborate rather than one agent trying to do everything - are where we think this goes next. AI evals (systematic testing of AI quality, not just application behaviour), which are to AI features what Pest tests are to regular code. The fine-tuning vs RAG decision, which every client asks about eventually. And AI observability, which is woefully underserved in the PHP ecosystem right now.

We'll be covering all of these in this series, each with real Laravel implementations and the honest version of what we found when we actually built it.

Is there an AI concept you're wrestling with in your own projects that we haven't covered here? Drop us a message - we build these posts around real questions, and chances are someone else is thinking about the same thing.

Building AI features into your Laravel application? We've been doing exactly that - from production agents to RAG-powered knowledge bases. Get in touch and let's talk about what makes sense for your project.