Stop your agent before it breaks a policy

Your agent is about to do something: issue a refund, grant access, approve a purchase. The check that runs in between — yes or no, before anything happens — is the most important component in an agent that can act. It is usually the weakest.

An agent that can only talk is a nuisance when it is wrong. An agent that can act is an incident.

Why most guardrails fail

A sentence in the system prompt. "Never approve refunds over the limit." That is a wish, not a control. Nothing enforces it.

A second model asked whether the action looks acceptable, in prose. It can be talked round by the same input that talked round the first, and its answer is a paragraph somebody then has to parse — which is where the check quietly breaks.

Why a yes-or-no decision model helps

Jev, from TypeSafe AI, has a question type that returns a yes-or-no probability. No prose, nothing to parse, and because answers are fixed in advance it cannot return something that is not an answer. That removes the parsing failure entirely.

It does not remove the harder problem: a well-typed yes about the wrong limit is still a breach — just a tidier one.

What the check actually needs to know

The agent wants to refund a customer. Is that allowed? The refund policy sets a limit. The limit depends on the role of whoever is authorising — defined in a different document. And this customer's contract has its own exception.

Hand the check only the refund policy and it approves something it should not. Missing the exception is not a rare case; it is the case the guardrail exists for.

That chain — policy, section, rule, limit, role, and the exception that modifies it — is what FastMemory walks, using references your documents already contain. The state the check sees is the complete set of rules governing this action, with the route.

Build it

1. Build the map locally from your policies, role definitions and customer agreements. These are exactly the documents that should not be sent out to be indexed.

cargo install fastmemory
fastmemory build ./policies

Put your role definitions where the build can read them. Roles change most — promotions, reorganisations, a raised approval limit — and a check that reads last year's org chart enforces last year's rules.

2. Write the check narrowly. Not "is this acceptable" — that is a mood. Ask: is this action permitted by the rules in the state? Put the action in the state as structured fields — amount, requester, target — rather than a description; TypeSafe emphasises structured program state as input. Add a second question: does anything in the state conflict? A conflict is a reason to stop, not to guess.

3. Decide which way it fails. For anything irreversible, it fails closed: uncertain means no, and a person decides. A refund can be issued tomorrow; it cannot easily be taken back today.

4. Put it where the agent cannot route around it. If the agent can call the refund tool directly, your check is advice. The tool should only run when the check says so. No wording in any prompt achieves that — only the shape of your system does.

Run it in shadow first

Before it blocks anything, run it in shadow: it sees every real action and records what it would have decided, while your current process carries on. After a fortnight you know where it would have blocked something good and — the list that matters — where it would have allowed something bad. Set your threshold so that second list is empty, then turn it on.

What a person sees when it says no

The proposed action, the rules it was checked against, the route to each rule, and the probability. A near miss reads very differently from a clear refusal. Record the person's decision beside the model's — it is the best evaluation data you will ever have.

Why compliance will sign it off

Every check stores the action, the rules, the route and the probabilities, at that moment. Months later, when somebody asks why a refund was allowed, you do not reconstruct anything — you show them.

One threat specific to this design

The state includes documents. If a stranger can write into them — a ticket, a shared page — they can write into your check. Treat outsider-written text as untrusted wherever it is stored, and keep policy documents in the chain and customer-written text out of it unless you have a reason. The route tells you which document supplied each line.

Honest caveats, and where this is wrong

• There is no official integration; the gate is yours to build.
• Jev is in early access — shadow mode is not optional.
• This does not replace least privilege. An agent should still hold only the tools it needs.
• If a rule can be written as code, write it as code. A hard cap on an amount is exact and free. Use the model for the rules that need reading — exceptions, conditions, context.

Try it

List every tool your agent can call that changes something. For each, write down what currently stops it being called wrongly — and which documents define "wrongly". Count how many had nothing but a sentence in a prompt.

FastMemory is free and open source: github.com/FastBuilderAI/memory.