RAG is dead, long live the Agent : How your knowledge base learned to act
It’s 2:14 a.m. A monitoring endpoint flags an HTTP 504 timeout on an e-commerce client’s site. Something identifies the cause in the Nginx logs, restarts the offending PHP-FPM pool, checks that the pages are responding correctly, and sends a timestamped incident report. Total time: under 90 seconds. Without anyone asking it a single question.
This “something” is an AI agent. And it bears no resemblance to the chatbot you query from a browser. The example is technical. It could just as easily be medical, financial, logistical. What changes is the architecture.
In the first part of this trilogy, we saw how a model is aligned: how you infuse it with values so that it behaves predictably and usefully. The question in this second article is different, and more immediate: now that we have a well-aligned model, how do we give it hands? How do we go from an AI that answers to an AI that acts?
The answer runs through a break with the architecture that dominated 2023 and 2024 (RAG) and the emergence of a new paradigm: the agent.
RAG, or the brilliant librarian who never leaves the room
What RAG accomplished, and why it’s no longer enough
Retrieval-Augmented Generation was a genuine revolution. Its full pipeline is worth understanding in detail, but the central promise was simple: ground the model’s answers in real, private, up-to-date documents, and cut hallucinations by a factor of two to five depending on the implementation. In 2023, that was exactly what companies needed in order to start trusting LLMs with their own data.
Except that RAG is structurally passive. It reads. It retrieves. It synthesizes. But it always waits for a question to be asked. And if a piece of information is missing from the vector store, it fails or makes things up, exactly the problem it was supposed to solve.
The limit nobody states clearly
Even with massive context windows (Cache-Augmented Generation, which lets you inject hundreds of pages in a single shot), the underlying problem remains intact. “Reading the whole manual” isn’t “knowing how to fix the machine.” Knowing the entire Nginx documentation isn’t enough to diagnose why a PHP-FPM pool collapses in production at 11:47 p.m. You have to query the logs in real time, form a hypothesis, test, observe the result, adjust. It’s a loop, not a search.
RAG is an extraordinarily well-indexed library. The agent is a colleague who uses that library among other tools, and who knows when to step outside the building.
A clarification is in order here, to avoid the misunderstanding the provocative title might create: RAG isn’t dead. It’s been demoted to the rank of one tool among others. In most production agents, it survives as an MCP resource or a context-retrieval tool that the agent calls when it needs to, not as the central architecture, but as a component. This is the shift to grasp before going further.
Anatomy of an agent: what really happens in the loop
The ReAct pattern: Reason, Act, Observe
The dominant cognitive framework of today’s agents is called ReAct (Yao et al., 2022). Its principle is brutally elegant: rather than producing one answer to one question, the model enters an iterative four-beat cycle that repeats until the objective is resolved.
Before getting into the detail, a conceptual formula to anchor the idea, in the spirit of the DPO equation from the first article, but without the math:
Agent = LLM (Reasoning)
+ Tools (Actions)
+ Memory (Context)
+ Planning (ReAct loop)
Remove any one of these four terms and you no longer have an agent: you have either a chatbot, a script, or an API. It’s their combination that creates something qualitatively new.
Thought: the model reasons out loud about the state of the problem. Not an answer, an internal deliberation. “The logs report a 504 timeout. I need to identify whether it’s Nginx, PHP-FPM, or the database before acting.”
Action: the model calls a tool. Not text generation, a function. nginx_read_logs(lines=200). The tool can be an API, a SQL query, a shell command, a REST endpoint.
Observation: the model receives the result and integrates it into its context. That result becomes a new piece of data that reshapes the next round of reasoning.
Next thought: the cycle restarts with this new context, until the task is solved or a stopping condition is reached.
┌─────────────────────────────────────────────────┐
│ GOAL │
└─────────────────────┬───────────────────────────┘
│
▼
┌───────────────┐
┌───▶│ THOUGHT │ Internal reasoning
│ │ (Reason) │ "What should I do?"
│ └───────┬───────┘
│ │
│ ▼
│ ┌───────────────┐
│ │ ACTION │ MCP tool call
│ │ (Act) │ get_logs() / restart() / ...
│ └───────┬───────┘
│ │
│ ▼
│ ┌───────────────┐
│ │ OBSERVATION │ Real result
│ │ (Observe) │ returned by the tool
│ └───────┬───────┘
│ │
│ Task solved?
│ No ──┘ Yes ──▶ FINAL ANSWER
│ + timestamped log
└────────────────────────────────────
Code language: PHP (php)Here’s what this cycle looks like on a real network case, diagnosing a loss of connectivity on a UniFi’s IoT VLAN:
💭 THOUGHT "The complaint has concerned the IoT VLAN since 6 p.m.
I'll check the port status on the relevant switch."
⚡ ACTION unifi_get_port_status(switch="USW-Pro-24", vlan=20)
👁 OBS. Port 14 in error: high CRC rate since 6:32 p.m.
💭 THOUGHT "A high CRC rate suggests a physical problem or a failing
device. I'll check which device is on this port."
⚡ ACTION unifi_get_client(port=14)
👁 OBS. File server, MAC xx:xx:xx:xx.
💭 THOUGHT "I'll restart the port to test whether the problem persists
before concluding hardware failure."
⚡ ACTION unifi_restart_port(switch="USW-Pro-24", port=14)
👁 OBS. CRC back to zero. Connectivity restored.
✅ ANSWER Port 14 showed CRC errors since 6:32 p.m.
Restart performed, connectivity restored.
Monitor the file server: possible hardware failure.
Code language: PHP (php)What this sequence illustrates: the agent didn’t search a document base. It acted on the infrastructure, observed the real effects, and built its answer from the real world. RAG could have done nothing here: there was nothing to retrieve, only something to diagnose.
From “Chat” to “Task”: the mental shift
The break the agent imposes isn’t technical first and foremost, it’s cognitive. You no longer ask questions. You hand over objectives.
Before: “Explain to me what a CRC error means in a network switch.” After: “My VLAN has been unstable since 6 p.m. Find out why and fix it.”
The first phrasing calls for an answer. The second calls for an action plan, an execution, a verification, and a report. It’s no longer a transaction, it’s a delegation.
It’s a shift in posture as deep as the one separating “looking something up on Google” from “entrusting a mission to a colleague.” And as with a colleague, the quality of the result depends as much on the clarity of the objective as on the agent’s capabilities.
Long-term memory: learning from experience
An agent with no memory is doomed to reinvent the wheel every session. Modern frameworks like LangGraph or Mem0 make it possible to store successes, failures, and identified patterns, in a dedicated vector store, separate from the business knowledge base. It’s a principle I explored in detail in the context of Claude Code’s persistent memory: an agent’s long-term memory isn’t a luxury, it’s what turns a one-off tool into a colleague that improves.
Concretely: if the agent has already diagnosed a PHP-FPM pool collapsing under load on the same server three times, it learns to check that point first the fourth time. If an Odoo migration failed with a particular error message, it memorizes the rollback sequence that worked. It’s the difference between a contractor who rediscovers your infrastructure on every job and a colleague who knows its habits, and its recurring weak points.
MCP: the nervous system that connects the agent to the world
The problem it solves
Before the Model Context Protocol, connecting an LLM to an external system meant writing a custom connector for every API, in every application, for every model. OpenAI had its function-calling format, Anthropic had its own, LangChain had its own abstractions. An SSH connector written for GPT-4 didn’t work with Claude without a complete rewrite.
MCP, proposed by Anthropic in late 2024, whose technical specification is public and quickly adopted as a de facto standard by the industry (OpenAI, Google, and Microsoft followed in the months after), solves this problem with an immediate analogy: it’s the USB-C of AI. A standardized protocol that lets any compatible model connect to any MCP server, with no specific adaptation for each model-tool pair.
What it changes in practice
An MCP server exposes two types of interface: tools (functions the agent can call to change the world) and resources (data it can read to observe the state of the world). This distinction isn’t trivial. A tool acts. A resource informs. And in a responsible deployment, you don’t grant these two categories the same permission levels.
In a web-hosting or system-administration ecosystem, an MCP server can expose, in a standardized way, functions like nginx_read_logs(lines) to read the latest access or error entries, php_fpm_restart(pool) to restart an application pool, mysql_kill_query(thread_id) to interrupt a blocking query, wp_deactivate_plugin(slug) to isolate a faulty WordPress plugin, or odoo_restart_worker(pid) to relaunch a stuck worker. The agent doesn’t need to know the exact syntax of each tool or the paths of every log file. It calls plainly named functions: the MCP server handles the translation to the underlying commands.
WebMCP pushes this logic all the way to web interfaces themselves, opening the door to agents able to interact with any site the way a human would, with no fragile scraping, no dedicated API, no prior agreement with the service’s owner. The field remains very much in flux in 2026, though: anti-bot protections adapt fast, and real-world effectiveness depends heavily on the vision capabilities of the model in use. Claude 3.5/4, GPT-4o, and their successors do well on stable, structured interfaces. On dynamic or heavily obfuscated pages, the results stay uneven. It’s a promise in the process of being realized, not a turnkey solution.
The agent as conductor
What emerges from this architecture is fundamentally new: the agent is no longer a text generator augmented with a knowledge base. It’s an orchestrator that has a palette of heterogeneous tools (reading, writing, computation, communication, system actions) and chooses which ones to call, in what order, based on the objective it’s been given.
This isn’t sophisticated function calling. It’s an architecture of delegation.
The agent in the real ecosystem: from concept to use case
The crashed-server scenario: the full walkthrough
Let’s take the hook from the introduction and walk through it step by step, to show each building block of the architecture in action on a real infrastructure.
It’s 2:14 a.m. A monitoring endpoint flags an HTTP 504 timeout on an e-commerce client’s site. The agent (running in the background on the monitoring server) receives the alert and enters its loop.
💭 THOUGHT "504 timeout at 2:14 a.m. Nginx is responding but returns a
gateway error. Probably a PHP-FPM or database problem.
I'll check the Nginx logs first."
⚡ ACTION nginx_read_logs(type="error", lines=50)
👁 OBS. Multiple "connect() to unix:/run/php/php8.2-fpm.sock
failed (11: Resource temporarily unavailable)"
💭 THOUGHT "PHP-FPM is saturated or crashed. I'll check the pool's
state before restarting."
⚡ ACTION php_fpm_status(pool="www")
👁 OBS. Pool saturated: 128/128 workers active, queue of 47 requests
waiting. No worker available for 4 minutes.
💭 THOUGHT "Clear saturation, not a crash. Restarting the pool is a
reversible, justified action. I'll execute it."
⚡ ACTION php_fpm_restart(pool="www")
👁 OBS. Pool restarted. 0/128 workers active, queue cleared.
⚡ ACTION http_probe(url="https://client.com", expected_status=200)
👁 OBS. HTTP 200. Response time: 312ms. Site operational.
💭 THOUGHT "Incident resolved. I'll document and notify."
📋 REPORT "2:14 a.m. incident: 504 timeout resolved.
Cause: PHP-FPM pool saturation (128/128 workers).
Action: restart of the www pool.
Estimated downtime: 4 minutes.
Site operational since 2:16 a.m.
[See full logs]"
Code language: PHP (php)Total time: under 90 seconds from initial detection. The agent reasoned, acted, verified, documented, and alerted, without anyone asking it a single question. That’s exactly what RAG cannot do.
Code self-correction: the WordPress plugin case
A second use case, more everyday and perhaps even more revealing of what the agent changes in practice.
An automatic update has just broken the homepage of a client’s WordPress site. The theme editor reports no YAML error, but the front end is blank. In a classic workflow: connect to the server, check the PHP logs, identify the faulty plugin, disable it via WP-CLI or phpMyAdmin, verify the rendering, document. A manual loop that can take thirty minutes at 3 a.m. on a site you don’t maintain daily.
With an agent that has access to the PHP logs and a WP-CLI tool: it reads the errors from the last ten minutes, identifies the offending plugin in the stack trace, disables it, probes the front end to confirm restoration, and submits a report with the diff for a decision before any irreversible action (full rollback, backup restore).
This last point isn’t a detail. It’s the human-in-the-loop architecture that makes the agent reliable in production. We’ll come back to it in the next section.
Notice, by the way, the final notification in the crashed-server scenario: it doesn’t just inform, it offers a link to the full logs and leaves the question of the post-incident investigation open. The agent resolves the emergency, but hands control back to the human for anything involving a conscious decision (understanding why the pool saturated, adjusting the configuration, investigating a potential attack). The report becomes a handover interface, not just a log.
The gray areas: what nobody tells you about agents in production
The real cost: when the agent drains your wallet in tokens
This is the field’s taboo. A ReAct loop on a complex task generates dozens of successive calls, each with an accumulating context: the previous thoughts, the observations received, the available tools. On cloud APIs (Claude, GPT-4o), an uncontrolled agent session can cost several tens of euros in a few minutes on a poorly defined task.
Three levers to control this cost. Prompt caching first: in a ReAct loop, the system prompt, the list of available tools, and the agent’s instructions stay identical from one call to the next, only the accumulated context (thoughts, observations) varies. A well-architected agent that caches these stable parts can cut its bill by a factor of ten on long tasks, making the economics of cloud deployment genuinely viable. Local models next, but that’s precisely the subject of the third article in this series. Explicit stopping conditions, finally: a maximum token budget, a cap on the number of iterations, mandatory human validation beyond a certain action threshold.
The practical rule is simple: never let an agent run without a defined budget. It’s the equivalent of handing a no-limit credit card to a zealous, enthusiastic assistant.
The infinite-loop risk
An agent can find itself in a logical dead end. Action A fails. The agent tries B to work around it. B fails too. The agent goes back to A with a slight variation. And loops, until the budget runs out or a forced timeout kicks in.
Modern frameworks like LangGraph handle this risk through iteration counters, pattern-repetition detectors, and explicit error states that force the agent to surface the failure rather than keep at it. The logic is close to that of hooks in Claude Code: execution guardrails that intercept deviant behavior before it gets expensive. On a homemade orchestration without these mechanisms, the infinite loop isn’t an edge case, it’s a likely scenario the moment the task strays off the beaten path.
Security: handing an agent the keys to the server
This is the question every practitioner has to ask before connecting an agent to a real infrastructure. An agent that has SSH access, write access to the GitHub repo, a connection to the database, is a potential attack vector if the model is manipulated through an indirect prompt injection: a system log containing disguised instructions, a booby-trapped API response, a malicious configuration file in the RAG store. Unlike direct injection (a user trying to manipulate the model in the prompt), indirect injection arrives through the data the agent reads, and that’s precisely what makes it dangerous: the agent trusts its sources by design. This risk ranks high in the OWASP LLM Top 10, and LLMs in production are already falling victim to it in less critical contexts.
The best practices aren’t negotiable. Principle of least privilege: each MCP server exposes only the tools strictly necessary to the agent concerned. Network isolation: MCP servers with no direct internet access. Exhaustive logging: every agent action timestamped and stored. And mandatory human validation for any irreversible action: data deletion, firewall rule changes, database rollback, external communication.
Sandboxing isn’t optional. It’s the baseline architecture of a deployment that doesn’t end in disaster.
Alignment 2.0: from politeness to reliable actions
In the first article of this series, we saw how RLHF and DPO make it possible to align a model with values, the HHH triad. But aligning an agent raises a qualitatively different and higher demand: we no longer just want it to be polite, we want it to be reliable in its actions.
A sycophantic model that makes up a textual answer is annoying. A sycophantic agent that executes an action to validate the user’s enthusiasm (without checking the prerequisites, without assessing the side effects) can drop a database table because it was asked “to clean up the obsolete data.” The distinction between intent and instruction has never been so critical.
The classification rule that works in practice: distinguish reversible actions from irreversible ones. Restarting a service, disabling a plugin, reloading a configuration: reversible, the agent can act with a log. Deleting data, changing firewall rules, sending an external communication, performing a production deployment: irreversible, explicit human validation mandatory, no exceptions.
This isn’t distrust of the agent. It’s responsible engineering. And it’s actually the state of the art in 2026: the best production agents aren’t fully autonomous, they’re semi-autonomous. They act alone on what’s fast, reversible, and well-defined; they request human validation on what’s slow, irreversible, or ambiguous. Full autonomy isn’t an end in itself, it’s a destination you reach gradually, as trust in the agent is built on mastered use cases.
The end of the chat interface, and the question that remains
The thesis of this article can be summed up in one sentence: the chatbot is a transitional interface. We ask it questions because we haven’t yet learned to hand over objectives.
The agent marks the shift, not toward the science fiction of conscious AI, but toward something more immediate and more profound: an AI that integrates into processes rather than into conversations. In time, the “open a chat window, type a question, read an answer” interaction will disappear for a large share of professional use cases. The agent will be a background service that monitors, anticipates, acts, and surfaces only when it needs a validation or has produced a result. Like the electrical system: everywhere, invisible as long as it works.
But this vision raises a question the next article will have to tackle head-on. If an agent has access to your server logs, your code repository, your database, your email, if it’s the one orchestrating all of your critical processes, do you trust an American cloud service to run that brain? Or would you rather it ran on hardware you control, in your server room, under your jurisdiction, without every request setting off across the Atlantic? It’s a question Mistral and the French armed forces asked before you, and one that the open-source movement is in the process of making concretely solvable.
This is the question of local open source. And it’s less technical than it looks. It’s a question of sovereignty.
Second part of a trilogy on modern AI. First part: From RLHF to DPO, the quest for perfect alignment. Third part forthcoming: The choice of independence, local open source.