Agents Guardrail Introduction 12 of 12 steps written

A guardrail’s value is set by where it sits, not by how good it is

Twelve steps, four parts — six families of check, three streams of traffic, six arrangements, and no arrangement winning twice.

Introduction

You are about to put guardrails on an agent, and the advice available to you is a list of things to install: a safety filter, a policy check, a grounding step, a review queue.

The list is not the hard part. This volume runs the same six families of check over three streams of traffic, in six different arrangements, and gets three different winners with no arrangement winning twice. Four of those arrangements contain the identical six families and differ only in where the checks sit.

The whole thing, before any of the argument

Every box below is something you can install, and the rest of this volume is about which of them your own traffic actually needs.

a request goal, query, task user or business applications and interfaces chat UI API tools enterprise apps the answer or a refusal response to user guardrails six families safety harmful content, jailbreaks, toxicity policy & compliance org policy, regulation, PII data source verification, access, leakage grounding fact-checking, citations, hallucination tool & action permissioning, parameters, human-in-the-loop behavior goal alignment, ethics, runtime monitoring the agent workflow input processing understand intent, classify planning decompose the goal, pick tools execution the model, tools, data, other agents evaluation check outputs, verify facts response generate, cite, state confidence your data and tools knowledge bases APIs, databases documents observability traces and logs violations audit trail on the way in and again on the way out and it does not stop when the answer ships monitoring real-time detection evaluation automated and human review feedback improve rules, update policy incident response alert, roll back, mitigate human-in-the-loop escalate the uncertain what it learns goes back in the core flow guardrails and controls your data and tools what you can see afterward every box in this picture is something you can install. none of them is free, and on the traffic measured here the set with every family in every position was the cheapest on nothing at all. steps 7 to 11 are how you decide which of them your own traffic needs.
What moves: a request enters at the left, drops through the six guardrail families, crosses the five stages of the workflow while data feeds in and traces leave, and the answer returns up through the same six families. The band beneath lights last and points back into the workflow. Twenty-two seconds end to end.
This is the densest drawing in the series. Click it to open it full-screen — arrow keys or two-finger scroll to pan, pinch or the controls to zoom, Esc to close.

What a guardrail is

A guardrail is a check that can refuse.

Not a policy document, not a system prompt, not a warning in the output, not a dashboard somebody looks at on Tuesday. It runs while a request is in flight and it has the authority to stop it. Everything hard about the subject comes from taking that definition seriously:

because it…the consequence
decides nowit runs in the request's own time. Whatever it knows at the moment it runs is all it will ever know
decides from what it can seea check at the door sees a request. What the agent will do with it has not happened yet, and this is the constraint the rest of the volume is built on
refuses real peoplea guardrail that stops a harmful request and one that refuses a legitimate user are the same event seen from two sides

The result, up front

streamwhat it ischeapest setcostposition spread
A · ordinarymostly legitimate traffic, and the harm in it is crudedoor$254.802.2x
B · adversarialthe same harms, phrased to get past a check at the dooracting$515.4813.7x
C · leakybenign requests whose answers leak or inventexit$449.909.6x
The maximalist stack never wins, and not because it catches less. The configuration with every family in every legal position catches exactly what the winning configuration catches on all three streams — and costs between 1.4 and 2.2 times as much. Stacking bought overlap, not coverage.
And on one stream, the check at the door is worse than no guardrail at all. It catches zero attackers on traffic phrased to get past it, refuses 49 legitimate users anyway, and costs more than having bought nothing. That is the first thing most teams install, failing on the exact traffic it was bought for.

Why position decides it

A check cannot run before the evidence it needs exists. A grounding check at the door is not badly tuned — there is no claim yet. That single rule empties most of the design space and creates the trade the whole volume turns on: early is cheap and blind, late is informed and expensive.

familyearliest stage it can runwhy not before
safetyinputharmful phrasing is in the request itself
policyinputso is regulated content the user sent
toolplanningnothing to permission until a tool has been chosen
dataexecutionnothing to check until a source has been touched
behaviorexecutiondrift is only visible once the agent is acting
groundingevaluationa claim and a source must both exist to compare them

The four kinds of money

Three of them are usually left off the comparison, and one of those three is paid entirely by people who did nothing wrong.

what costs moneyhow muchwho pays it
screening one request with one detector$0.002you, on every request, whether or not anything fires
one harmful request that got through$40.00you, once, when it reaches the world
one legitimate request wrongly refused$2.50a real person who wanted something reasonable
a stage of finished work thrown away$0.40you, every time a check fires late

Is this for you?

if…then
you are deciding which guardrail product to buystep 10 — the gap between the best and worst arrangement of the same checks is larger than any gap between checks
your input filter is not catching what you expectedstep 8. There are two different reasons for that and they need opposite fixes
your requests look fine and your answers do notstep 9. No improvement to the input filter can help
somebody wants every check turned on everywherestep 7, then step 10
you are arguing about how much an incident is worthstep 12, which measures how little that argument decides

The three streams of traffic

Twelve hundred requests each. They are premises rather than a survey — constructed to disagree, and labeled as constructions everywhere they appear.

streamharmfulof those, invisible everywherewhat it teaches
A · ordinary882the cheapest check at the door catches everything catchable
B · adversarial2325the door catches nothing, and costs more than nothing
C · leaky1723nothing is observable until the answer exists

How to read the source labels

labelmeans
conceptargued from first principles. Quotes nothing from a lab
measureda lab measured it. Every figure is read from labs/design.json
hands-onyou run it yourself, on your own traffic
Nothing here is a benchmark. Three constructed streams of traffic, one cost model, and detectors treated as fixed instruments with known blind spots. Adversarial machine learning — how to build a check that resists evasion — is a real field and is not this one. The question here is where to point the instruments you have.
Build state: 12 of 12 steps written.