Guardian agents

What is a guardian agent?

A guardian agent is an agent whose subject is another agent. It reads what a second agent produced or is about to do, holds that against a standard you wrote down, and answers one of four ways: fine, change this, stop, or get a person.

The term came from Gartner, which forecast in June 2025 that guardian agents would take 10 to 15 percent of the agentic AI market by 2030 and published a first market guide for the segment in February 2026. A forecast like that is an analyst firm naming a segment it expects vendors to sell into. It tells you budgets are moving. It does not tell you that any particular product catches your mistakes.

One distinction decides most of the design. Agent runtime controls are code: a hook that fires before a tool call and refuses it, a permission rule, a checkpoint. A guardian agent is a model. Both sit between the agent and the action, and only one of them can be wrong about what it is looking at.

The three jobs a guardian agent gets

Gartner splits the category into reviewers, monitors and protectors. In practice those are three different pieces of software with three different cost profiles.

• Reviewing an output before it goes out. A second model reads the drafted reply, the summary or the SQL statement and scores it against your criteria before anyone sees it. It runs on every item, so this is where the bill and the added waiting time land.

• Watching a run while it happens. The checker sits in the loop, sees tool calls and results going by, and can interrupt. It decides fast on partial information, and it is the only one of the three that can stop an action instead of describing it afterwards.

• Watching a fleet. Reading the logs of many runs for a pattern rather than a bad value: this agent started calling the export tool forty times a day. It runs off the critical path, so it is cheap, and it is the job where a model earns its place, because the question is whether something looks unlike the usual.

A model checking a model

If the checker is the same kind of thing as the thing being checked, what does it add? Something real: it sees a finished output the writer never read back, it can be given one narrow question instead of a whole task, and it can come from a different model family.

The published evidence is mixed, though. A team at UC Berkeley ran 21 judge models from nine providers over roughly half a million judgments in 2026. Raw agreement scores flatter a judge badly: correct for the agreement you would get by guessing and between 34 and 41 percentage points come off. Two judges in that set were already running in production, gave the same verdict again on a re-run almost every time, and still strongly preferred whichever answer they happened to see first. A checker can be steady and wrong at once.

A separate experiment injected the same error into a conversation twice, once presented as the user's mistake and once as the model's own. Across fourteen open models the error got corrected when it belonged to somebody else and missed when it belonged to the model itself, on average in about two thirds of cases.

Vendor documentation says the same thing more quietly. Meta's Llama Guard classifies text against a fixed list of fourteen hazard categories and its model card says it is optimised for English. Microsoft's groundedness detection answers one question, whether an answer is supported by the source you passed in. A guardian catches what it was built to look for, and neither vendor pretends otherwise.

Where a guardian beats a rule

A model check earns its cost on judgements you cannot write as a condition. Is this reply rude. Does this answer contradict the document it cites. Does this run look unlike the last thousand.

Take a support agent that drafts replies to warranty claims. A customer writes about a coffee machine that died after a spill. The agent retrieves the warranty terms, which exclude liquid damage, and drafts a warm reply saying the repair is covered. Nothing in it is unsafe and no forbidden word appears. There is no threshold to trip and no phrase to block, because next week the same mistake will be worded differently.

A model check with the retrieved terms next to the draft catches it, because the question is comparative rather than absolute: is every claim here supported by the source. Microsoft sells that check, and the example in their own documentation has the same shape. The answer says the interest rate is 5 percent, the source says 4.5, and the check flags the sentence and hands back the corrected number.

Where a rule beats a guardian

Anything you can write as a condition belongs in code. An amount over a threshold. A recipient outside your own domain. A table nothing may write to. An account number that is not in the supplier master file. Moving one of those into a model is a downgrade: you swap a check that is right every time and costs nothing for one that is usually right and costs a call.

An accounts payable agent shows how that goes wrong. A mail arrives from what looks like a known supplier, with a corrected invoice for 8,400 euro and a new bank account. Everything else lines up: right company name, the reference of a real open order, VAT that adds up, an ordinary polite tone. A model reviewer reads it all and finds nothing, because on the face of it there is nothing. The problem is a fact that appears nowhere in the text: that account number has never been on file for this supplier.

Two lines catch it. If the account number is not the one in the supplier master, stop and ask a person. If the amount is over 5,000 euro, stop and ask a person. No judgement, no model, no monthly bill. Vendors split their own products along this line already: Amazon's guardrails product has word filters that match exactly against a list you supply, and separately a contextual grounding check that weighs the answer against the retrieved passages.

What a guardian costs, and who is still responsible

Reviewing every output means a second model call on every output, and at volume the checking bill approaches the production bill. So you either sample rather than score everything, or you put a smaller and cheaper model in the checker's seat. OpenAI's agent framework builds that in: a fast cheap guardrail in front of a slow expensive agent, with a tripwire that stops the run. Decide the sampling up front, because a checker is the first thing people switch off when the invoice arrives.

A guardian agent does not move responsibility. If your agent sends a customer a wrong quotation, the fact that a second model approved it changes nothing about who owes that customer an answer. Two models agreeing is not two opinions either: run the same family twice and you get the same blind spots twice, plus the tendency of a model to be gentler on text that resembles its own. A second human signature is worth something because the second person knows a different set of things, and that does not carry across.

What to watch out for with guardian agents

For most smaller companies the sensible shape is a stack rather than a product. Put the rules you can express in code, where they are cheap and certain. Put a model check on the judgements you cannot express, and only on those. Then put a person on the small set that matters: the actions that move money, leave the building, or cannot be undone.

The guardian reads attacker-controlled text too. A document with hidden instructions reaches the checker as readily as it reaches the agent, so prompt injection is a problem for both halves of the pair.

Know which way it fails. When the check times out or the API errors, does the output go out or get held? Both answers are defensible and only one is what you meant. Pick it deliberately and log every time that path is taken.

A checker makes the person after it read less carefully. Anything stamped as reviewed gets a lighter human read, which is automation bias through the back door. If a human step exists because the decision matters, do not tell that person the machine already approved it.