Guardian Agents: The Emerging Discipline of Agents That Watch Agents

I didn't set out to build a guardian agent. I set out to build a pipeline that worked. It was a three-agent system: one agent pulled context from a knowledge base, one reasoned over it, one generated a response. Clean handoffs. Sensible prompts. It ran beautifully in testing. Then I deployed it, walked away for two hours, and came back to find the reasoning agent had been confidently answering questions about topics it had zero context for, and the response agent had been faithfully packaging those wrong answers and shipping them to users. No errors. No alerts. Just quiet, confident wrongness, compounding across every turn. That's the problem guardian agents solve. Not "what if the agent breaks?" but "what if the agent keeps working, just badly, and you can't tell?" Why Watching Agents Is Different From Watching Software Here's the thing about traditional software: it fails loudly. A null pointer throws an exception. A timeout surfaces a 500. Something breaks and the logs light up. You know where to look. Agents don't do that. When an AI agent breaks, you get a clean response that is silently wrong. The reasoning agent in my pipeline wasn't crashing. It was hallucinating and outputting structured, grammatically correct, confident nonsense. It looked healthy from every external signal. The only way to catch it was to watch what it was actually saying, not whether it was saying something. This is the core problem in multi-agent systems. Hallucination amplification happens when hallucinated information propagates across all agents: one agent's wrong answer becomes the next agent's input, which builds on it, which passes it forward again. By the time a bad fact reaches the end of a five-agent chain, it's been endorsed, elaborated on, and cited three times. Nobody flagged it at step two because there was nobody watching step two. Avivah Litan, VP Distinguished Analyst at Gartner, put it plainly in June 2025: "As enterprises move toward complex multi-agent systems communicating at breakneck speed, humans cannot keep up with the potential for errors and malicious activity." Gartner didn't say that as a warning against agents. They said it as a prediction: by 2030, guardian agent technologies will account for at least 10 to 15% of the agentic AI market. Watching agents is going to be its own industry. Right now, it's mostly something you build yourself when you get burned. I got burned. So I built one. What a Guardian Agent Actually Does The term sounds impressive. The implementation is more pragmatic than it sounds. A guardian agent is just an agent that sits in your pipeline and watches what the other agents are doing, intercepting their outputs before those outputs become inputs for the next step, checking them against a set of rules, and either passing them through, flagging them, or blocking them entirely. Gartner breaks guardian agent functions into three categories: Reviewers, which identify and review AI-generated output for accuracy and fair use; Monitors, which observe and track agentic actions for human or AI-based oversight; and Guardrails, which adjust or block actions and permissions using automated responses during operations. In my pipeline, I needed all three. But I started with the monitor. The first version was embarrassingly simple: after the reasoning agent produced an output, my guardian agent sent that output to a separate LLM call with a short prompt: "Does this response rely on information not present in the provided context? Answer yes or no, and flag the unsupported claim if yes." That's it. A second LLM judging the first one. It caught 14 hallucinations in the first 24 hours of running. The response agent had been confidently generating answers from 14 separate moments of made-up context. I'd had no idea. The Three Places a Guardian Needs to Stand Once I had the basic monitor working, I realized there were three distinct interception points, and I'd only covered one of them. Before the LLM call (pre-input). This is where you catch scope drift: when a user or upstream agent sends something to your agent that falls outside what it's supposed to handle. A major airline uses pre-LLM guardrails to redact PII from customer support conversations before they ever leave the corporate environment. In my case, the pre-input guardian checked whether the context being passed to the reasoning agent was actually populated. Empty context plus a question equals a hallucination waiting to happen. The guardian caught the empty-context case and returned a structured escalation instead of forwarding a bad payload. After the LLM call (post-output). This is the one I built first. It catches what the LLM produced before it propagates downstream. Another team uses a post-LLM hallucination guardrail that catches unsupported claims and automatically feeds them back to the agent for correction before the user ever sees the response. The key design decision here is whether to block, flag, or self-correct. Blocking is safest. Self-correction (feeding the flagged output back to the agent with "try again without the unsupported claims") adds latency but often produces a usable result. I used blocking for my first version. Better to surface an escalation than to trust a retry loop I hadn't validated. At handoff points between agents. This is the one most teams skip because it's harder to instrument. The channel where hallucination propagation occurs is the inter-agent communication channel, and frameworks do not log it by default. Agent A sends a message to Agent B. If that message contains a wrong fact, Agent B doesn't know. It just builds on it. A guardian sitting at that handoff point can compare Agent A's output against the source context it received, flag discrepancies, and either block the handoff or annotate it with a confidence flag that Agent B can use to decide whether to trust the input. Getting this third interception point right took me three iterations. The first version added too much latency. The second had too many false positives, flagging valid inferences as unsupported claims. The third used a confidence threshold: outputs above 0.85 similarity to source context passed through; outputs below that threshold got reviewed. Not perfect. But working. What It Caught That I Didn't Expect The hallucinations were expected. What I didn't expect was catching scope drift mid-pipeline. Scope drift is when an agent starts doing something adjacent to its task but outside its intended scope, and keeps going because nothing stops it. In my system, the context agent (the one pulling from the knowledge base) started retrieving documents from a section of the knowledge base it wasn't scoped to, because a user query happened to be semantically close to content in that section. The retrieval worked. The content was real. But it was from a product line we weren't supposed to be advising on in this context. The reasoning agent didn't know that. It used the documents. The response agent packaged an answer that was technically accurate but operationally wrong: it was advising a user about a product they hadn't asked about and we weren't authorized to recommend in this channel. The guardian caught it, not because the content was hallucinated, but because the retrieved documents came from an explicitly blocked source namespace. A simple metadata check. The kind of thing you can only build if you're already watching every handoff. Two different things drift in long-running multi-agent sessions, and most fixes only address one. Factual drift happens when an agent forgets what was decided or built. Alignment drift happens when an agent forgets why. The scope drift I caught was alignment drift. The agent hadn't forgotten a fact. It had forgotten its lane. The Limitation Nobody Mentions Here's where I have to be honest: guardian agents have a structural problem that's easy to miss until you've been running one for a few weeks. The guardian only sees what it's positioned to see. The GA-Agent sits in the communication route as an inserted node or hook that enforces policies individually per turn. That means any communication that doesn't go through the hook is invisible to it. In frameworks like AutoGen or LangGraph, agents can communicate through side channels: shared memory, direct tool calls, external state, all of which bypass the main message bus. If your guardian is only watching the message bus, those side channels are completely dark. I discovered this when I realized my context agent was writing intermediate results to a shared cache that the reasoning agent was reading directly, bypassing the handoff I was monitoring. The guardian had been faithfully watching the wrong door. A 2026 Gravitee survey found that only 24.4% of organizations have full visibility into which AI agents are communicating with each other. The remaining 75.6% have blind spots. A guardian agent doesn't fix that. It just makes the monitored paths trustworthy. The unmonitored paths stay dark. The fix is architectural: make all inter-agent communication go through a single observable bus, and make that a hard constraint before you build the guardian, not after. I had to refactor the shared cache into a message-passing pattern before my guardian became genuinely comprehensive. That took a week I hadn't planned for. What Deutsche Telekom Got Right (And What It Cost Them) I'm not the only one who's built this. The most publicly documented production implementation of a guardian-style multi-agent system is Deutsche Telekom's RAN Guardian Agent, launched in November 2025. The system monitors mobile network performance, assisting in troubleshooting and optimization, with AI agents capable of analyzing network behavior, identifying performance anomalies, and autonomously initiating corrective actions. It's a three-agent setup: one agent scans for upcoming public events that will spike network traffic, one evaluates network capacity against those predictions, one executes configuration changes. Processes that previously took roughly an hour can now be completed within just a few minutes. Since its launch in November 2025, the system identified 237,000 events for 2026. During the February Carnival season in Germany, it identified around 130 Carnival events and parades, each expected to draw over 10,000 participants, served by 611 mobile sites, all pre-checked for issues by RAN Guardian, with most also monitored live. Only 5 sites experienced peak loads; RAN Guardian optimized those during the event. That's a real guardian pattern in production: watch, predict, validate, act, and the acting agent's decisions are informed by the monitoring agent's observations, not made in isolation. Ahmed Hafez, who led the deployment, conveyed the significant effort and brainpower needed to get RAN Guardian Agent into operations. They had to create guidelines on managing AI and agentic AI from scratch, since it's a new system with its own challenges. "From scratch" is the important phrase. There is no established playbook yet. Deutsche Telekom wrote theirs in production. I wrote mine by breaking things in a smaller system. The discipline is being built in real time, from real deployments, and anyone building multi-agent systems right now is contributing to it whether they realize it or not. How to Start Without Overbuilding The mistake I almost made, and that I see other teams make, is trying to build a comprehensive guardian before you've deployed anything. You end up with a governance layer for problems you haven't encountered yet, and you miss the problems you're actually having. Start with one guardian, one rule, one interception point. Pick the highest-risk handoff in your pipeline: the one where a bad output would cause the most downstream damage. Put a guardian there. Give it one job: check whether the output is within the expected topic scope. Log every intervention. After a week, look at what it caught. That log will tell you where to add the next rule. Every guardrail trigger should produce a trace event, just like any other span in your agent, so you can see how often each guardrail fires, what it catches, and whether self-correction attempts succeed. The log is the product, in the early stages. It's how you learn what your pipeline actually does when you're not watching. One thing I got right early: I made the guardian emit structured JSON for every intervention: timestamp, intercepting agent ID, flagged output hash, rule that fired, action taken (block/flag/pass), downstream agent that would have received it. That log became the audit trail that let me explain to my team, and eventually to stakeholders, exactly what the guardian was catching and why. When someone asked "how do we know the agents are behaving?" I could show them 14 days of intervention logs. That conversation is easier than most people expect. The Thesis Gartner's prediction that guardian agents will capture 10 to 15% of the agentic AI market by 2030 is interesting context. It's not what convinced me this discipline matters. What convinced me was sitting in front of a pipeline that looked healthy, was logging cleanly, and was quietly wrong about 8% of its outputs. The agents were working fine. The pipeline was failing. A guardian agent isn't a safety net. It's not a compliance checkbox. It's the layer that lets a multi-agent system be autonomous without being unsupervised, because "autonomous" and "unsupervised" are not the same thing, and conflating them is how you end up in a post-mortem you could have prevented. You don't need to wait for the discipline to mature to start practicing it. Build the first guardian. Give it one rule. Watch what it catches. The log will tell you everything. Sources Gartner press release, June 11, 2025: https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030 Deutsche Telekom RAN Guardian Agent launch, November 11, 2025: https://www.telekom.com/en/media/media-information/archive/ai-agents-for-mobile-network-1099054 Deutsche Telekom and Google Cloud Carnival season results: https://www.telekom.com/en/media/media-information/archive/mindr-ai-agents-in-the-network-1102724 Deutsche Telekom RAN Guardian Agent analysis, Omdia, November 2025: https://omdia.tech.informa.com/om138387/deutsche-telekoms-ran-guardian-agent-proves-agentic-ai-is-not-just-hype GUARDIAN: Safeguarding LLM Multi-Agent Collaborations with Temporal Graph Modeling, NeurIPS 2025: https://arxiv.org/abs/2505.19234 Guardian-Agent AI Oversight Framework overview, EmergentMind: https://www.emergentmind.com/topics/guardian-agent-ga-agent Multi-Agent AI Systems: Architecture and Failure Modes, Augment Code: https://www.augmentcode.com/guides/multi-agent-ai-systems Best Practices for Building Agents: Guardrails, Arthur AI, April 2026: https://www.arthur.ai/blog/best-practices-for-building-agents-guardrails AI Agent Security in 2026, AGAT Software (Gravitee survey data): https://agatsoftware.com/blog/ai-agent-security-enterprise-2026/ \