From guardrails to guardians

Enterprises are starting to hand real work to agents: answering customers, checking invoices, updating the systems of record. Most of those agents are governed by a paragraph. Somewhere in the system prompt sits a list of things the agent must never do, and everyone hopes the model reads it the same way on its thousandth run as on its first. That holds up in a demo. It doesn't hold up once agents call tools, hand work to other agents and run for hours with nobody watching.

So we made a decision most platforms won't: the rules that matter don't live in the prompt. They run beside the agent, in the execution loop, on every step it takes. On aixplain, the agents that enforce them are called Guardians.

There are two kinds. Inspectors control what an agent does. They check the request before the agent starts, every tool result and subagent answer along the way, and the final answer before it leaves. Each one judges with a guard from the Marketplace, with your own Python, or with a rule you write in plain words that a judge model checks. You pick the guard that fits what your agent handles, and you can swap the judge for any model you like. A rule asks a simple pass-or-fail question, so a small, fast model makes a good verifier: as good for the job as a large one, and quicker and cheaper on every run.

When a check fails, you decide what happens next. The Inspector can stop the run, send the agent back with its critique, rewrite the content, for example by masking personal data, or only log it. A step that needs a person waits for one: the run pauses until someone approves it.

Bodyguard controls what an agent can reach and what it can spend. Every call to a tool, a data source or a model is checked against the agent's permissions and allow list before it fires, and the agent is held to its limits on credits, run time and tokens. A call that isn't allowed never runs, whatever the prompt says. A run that reaches its cost cap stops planning and answers with the work already done.

Beneath both, aixplain stops any run that loops.

The real reason to build this way isn't compliance. A guardrail is a filter wrapped around a model. It sees text going in and text coming out, and it has one move: block. A Guardian is an agent in the loop. It reads each step, judges it and acts. Agents move faster than people can follow, so the enforcers have to be agents too. A city doesn't stay safe because it writes laws. It stays safe because someone enforces them, every day.

We think of it as the four-eyes principle, applied to agents. A bank never lets one person approve their own payment. We don't let an agent approve its own work. Something else in the loop reads every step, and it can say stop.

Inspectors judge one run at a time. Monitoring watches all of them. It follows every run around the clock and alerts you when latency, escalations or cost drift past your threshold, so a regression shows up the day it starts, not at the end of the quarter.

That changes what you can hand over. When governance lives in the runtime, the question shifts from "what might this agent do?" to "what did it do?", and you can answer it. In the aixplain OS, every agent has an owner, access rules, a budget and an off switch. Every run is recorded step by step: the input, the thinking, each tool call, every Guardian action, the approvals, the tokens and the credits. When your CISO asks what an agent did last Tuesday and why it was allowed to, you open the run and read it.

The same logic extends to where agents run. Guardians go wherever the agent goes: on cloud, in your VPC, on-prem or air-gapped. An agent keeps its controls when it moves inside your perimeter, and Inspectors work on every aixplain agent, on every plan.

Most agent platforms are bets on what the model will do. Ours is a bet on what the system lets it do. Guardrails tell an agent what you expect. Guardians make sure it happened. If an agent can't be held to account, it shouldn't be trusted with the work.