Exceptions are how a sensible rule survives an awkward case. Left open, they become the rule. Any exception that lets an AI agent act beyond its normal bounds should carry an end date, a named person who granted it, and a stated reason, so that it either lapses or is consciously renewed on evidence rather than drifting into permanent policy.
How do exceptions turn into the real policy?
The pattern is familiar from any control environment. A limit is set. A good customer, an urgent month-end or a system outage makes the limit inconvenient. Someone senior approves a one-off exception. The work gets done. Nobody removes the exception, because nothing forces them to and removing it might cause the same problem again.
Six months later, the written limit says one thing and the agent does another. Auditors find a bound that reads 1,000 on paper and 5,000 in practice, approved once by someone who has since moved role. The exception has become the policy, without anyone deciding that it should.
Agents make this worse in one specific way. A person who was granted an exception remembers it was meant to be temporary and may hesitate to rely on it. An agent does not hesitate. Once an exception widens its bounds, it will use the wider bound on every case that fits, at full volume, until someone narrows it again.
What counts as an exception to an agent's bounds?
Any change that lets an agent act where its standing bounds would refuse or hold the action. In practice they come in a few shapes:
- A raised limit for one customer, segment or period, such as a higher refund ceiling during a product recall.
- A widened scope, letting the agent handle a case type normally outside its role.
- A relaxed source requirement, accepting a weaker provenance than usual because the strong source is unavailable.
- A suspended hold, letting the agent execute work that would normally wait for a named approver.
- A per-customer variation, where one client's limits differ from the default.
The last one is the hardest to see as an exception, because it is often a legitimate business choice. Our article on whether an agent's limits should be the same for every customer argues they often should not. Variation is fine. Undated variation, with no owner and no reason, is the problem.
What should every exception record?
An exception is a decision, and decisions belong in the record. Each one should carry the same small set of fields:
| Field | Why it matters |
|---|---|
| The bound being varied | So the record shows exactly what changed |
| The new value or scope | So anyone can see how far it went |
| Who granted it | A named person, not a team |
| The reason | So a later reviewer can judge whether it still applies |
| Start and end date | So it lapses unless renewed |
| The evidence for renewal | What would need to be true to extend it |
The end date does most of the work. It turns a permanent drift into a recurring question. When the exception expires, the agent returns to its standing bounds, and anything that now needs the wider bound is held or refused. That creates a visible signal: someone either renews the exception with a reason, or accepts that the standing bound was right.
How long should an exception last?
As short as the reason behind it. An exception granted for a product recall should end when the recall ends. One granted because a source system is down should end when it is restored. One granted for a particular customer's peak season should end with that season.
Where there is no natural end, choose a short default and make renewal easy but deliberate. Thirty days is a reasonable starting point for most operational exceptions. The aim is not to make exceptions painful. It is to make sure someone looks at each one again, with fresh information, before it becomes part of how the agent works.
Exceptions should never outlive the agent's certificate. If an agent's authority itself lapses and must be renewed on evidence, an exception layered on top of that authority must lapse at the same time or sooner. The same reasoning applies to approvals more generally, as covered in whether AI agent approvals should expire, and to the agent's standing grants, in why an AI agent's permissions should expire.
What happens to work when an exception expires?
It returns to the normal path. Actions the exception allowed will now be held for a named person or refused, depending on which bound applies. That will show up as a rise in held or refused items in the days after expiry, and it should be expected rather than treated as a fault.
Plan for it. Before an exception lapses, check how much work has relied on it and make sure the team that handles the exception queue has capacity to absorb what comes back. If the volume is large and the reason still holds, renew it properly. If the volume is large and the reason has gone, you have found work that was being done outside its intended bounds and should not have been.
Why can't a written rule about exceptions do the same job?
Many organisations already have a policy that says exceptions must be temporary. The policy rarely works for agents, because nothing in it acts on the agent. A document that says "exceptions expire after thirty days" relies on someone remembering to remove each one. The agent will keep using the widened bound until that happens.
Expiry has to be enforced where the bound is checked. When the end date passes, the check should stop honouring the exception automatically. This is the broader point of written AI policies not binding agents: only a limit applied at the moment of action changes what an agent does.
What is the cost of making every exception expire?
More renewals, more decisions and occasional friction when a legitimate exception lapses before anyone has renewed it. Some teams will feel this as bureaucracy, especially for long-standing customer variations that everyone agrees with.
The cost is worth paying because it is visible and small, while the cost of permanent exceptions is invisible and grows. The fix for friction is to make renewal simple for the person who owns the exception, not to remove the end date. If you do one thing after reading this, list every live exception to your agents' bounds, find the ones with no end date and no named owner, and give each one both. The wider framework is set out in our guide to agent governance as a bound, not a model.
Where Pryme fits
In Pryme, a customer's own limits are one of the five bounds every action meets. Variations to those limits are recorded with the person who granted them, the reason and an end date, and the check stops honouring them when they lapse. Because certificates themselves lapse after 90 days, no exception can outlast the evidence behind the agent's authority.
Questions people ask
Can an agent request an exception to its own bounds?
It can flag that a case needs a bound it does not have, which should create a held item for a named person. It should never be able to grant or extend an exception itself.
Who should be allowed to grant exceptions?
The person who owns the bound being varied, or someone senior to them with that power written down. Granting rights should be narrow and recorded, and the person granting should not be the person who benefits from the exception.
Should expired exceptions be deleted from the record?
No. The record of an exception, including when it started, who granted it and when it lapsed, is part of the evidence for every action the agent took under it. Keep it in an append-only record so later reviewers can reconstruct what the agent was allowed to do on any given day.