Design-time checks test what an agent might do. After-the-fact reviews find what it did. Neither touches the action itself. Enforcement has to happen at the moment of execution, against the facts as they stand then, because that is the only point where a wrong action can still be stopped and the only point where every relevant bound is known.
What are the three moments a control can act?
Every control on an agent acts at one of three moments. Each is useful. Only one can stop a specific action.
| Moment | Examples | What it can do | What it cannot do |
|---|---|---|---|
| Before deployment | Design review, testing, certification, prompt review | Establish that the agent is competent and well bounded in general | Stop a particular action on a particular day |
| At the moment of action | A check on each tool call against current bounds, returning a verdict | Allow, hold, refuse or withhold this action now | Fix a badly designed agent |
| After the fact | Monitoring, sampling, audit, complaint handling | Find patterns and mistakes, and improve the agent | Undo an action that cannot be undone |
Firms tend to invest heavily in the first and third rows, because they map onto familiar processes: change approval and audit. The middle row is newer, and it is the one agents most need.
Why aren't design-time checks enough?
Certification and testing establish that an agent behaves well across a set of cases. That is necessary. But the conditions an agent was tested under are not the conditions it acts under on any given day.
Between certification and action, many things can change. The agent's certificate may have lapsed. The customer's limits may have been lowered. A source the agent relies on may have been reclassified. The account it is about to pay into may have been flagged an hour earlier. None of these can be known at design time. All of them decide whether the action should go ahead.
There is also the agent's freedom to choose. A tested agent took certain paths through certain cases. In production it may combine tools in an order nobody tested. A design-time check cannot cover a path that had not been taken when the check ran.
Why isn't after-the-fact review enough?
Monitoring and audit find problems. They are how firms learn. But some agent actions cannot be reversed once they happen: a payment on an instant rail, a message to a customer, a report to a regulator, a deleted record. For those, finding the problem afterwards produces a well-documented mistake.
Even for reversible actions, after-the-fact review shifts cost onto the customer. A wrongly applied fee that is refunded a week later still caused a week of harm, and possibly knock-on charges.
What does enforcement at the moment of action check?
The check runs on each attempted action, reads the current state of every bound, and returns a verdict before anything changes. The guide on how to enforce an AI agent's bounds at the moment of action covers the mechanics. In outline, it asks five questions at once:
- Is this capability inside the agent's role?
- Does the agent hold a current certificate for it at this depth?
- Do the facts this action rests on come from sources strong enough to support it?
- Is the action within the customer's own limits, as they stand right now?
- Does any platform guardrail forbid it outright?
The lowest answer wins, and the verdict records which bound decided. That last part matters: a verdict that says "held because the amount exceeded the customer's limit of 500" is both enforceable and explainable.
What is the gap between check and use?
There is a subtle failure even when checks happen close to the action. If the check runs, then the agent does some other work, then the action executes, conditions may have changed in between. Engineers call this a time-of-check to time-of-use gap.
For agents, the gap appears when a plan is approved at the start of a task and executed step by step later. A plan to pay three invoices may be fine when drafted. By the third payment, the payee may have been flagged. The fix is to check each action as it executes, not the plan as a whole. Approving a plan is useful for a person's understanding; it is not authority for every step within it.
Retries create a related problem. An action allowed once should not be silently allowed again because a timeout made the agent repeat it. The case for designing actions so that retries are safe and idempotent comes from the same principle: the execution layer, not the agent's memory of what it did, decides.
How do the three moments work together?
The three moments are not alternatives. Certification sets the depth an agent may hold. Enforcement at the moment of action applies that depth, and every other bound, to each action. The record captures every verdict so after-the-fact review has something reliable to work from, which is why the record must be append-only.
Corrections close the loop. When a person corrects an agent's work, that correction should feed back into the agent's bounds or certification, a theme explored in what should happen when a person corrects an AI agent's work. Without enforcement in the middle, however, both ends are advisory.
Where Pryme fits
In Pryme, every action meets the minimum chain at the moment it executes: role scope, certificate, sources, the customer's limits and the platform guardrails. The lowest bound wins, the verdict names it, and the verdict is filed. A certification run that clears no depth drops the agent to depth 1 the same day, and the next action reflects it. See the governed agentic operating system, explained.
Questions people ask
Does checking each action make agents too slow?
The check is a rules evaluation against current state, not another model call, so it adds little time. The only real delay is for held actions, and that delay is the person deciding.
Can enforcement live inside the agent's own code?
It should sit outside the agent, in a layer every action passes through. An agent that enforces its own bounds can be wrong about them in the same way it can be wrong about anything else.
What if a bound changes while an action is held?
The action should be rechecked against current bounds when it is released. A release that relies on the bounds as they stood when the hold began reintroduces the gap between check and use.