When should an AI agent's depth be reduced?

At once, and without debate, after a failed certification run, a lapsed certificate, an incident that reached a customer, or any change to the model, sources or brief that has not been retested. Promptly, after review, when warning signals cross thresholds you set in advance. Reducing depth should be fast and easy; widening it should be slow and evidenced.

Why should reducing be easier than widening?

Because the costs are lopsided. Reducing depth wrongly costs some reviewer time for a few days. Failing to reduce it when you should costs customers, money or a regulator's trust. A process that requires the same weight of evidence to narrow an agent as to widen it will always narrow too late.

So the rule is asymmetric. Anyone on the agent's on-call rota can lower depth without anyone else's approval. Restoring depth goes through the same route as any widening: production evidence, fresh certification and the owner's decision.

What should trigger a reduction?

Notice that most rows target one capability, not the whole agent. An agent whose payment-date changes go wrong does not need to stop drafting replies. Our entry on what depth means explains why each action needs its own depth.

How is a reduction carried out?

1. On-call owner or the platform: sets the capability to the lower depth. Evidence: a filed verdict naming the trigger and the person.
2. Team lead: adjusts review work. At lower depth more work comes back to people, so the rota changes. Evidence: the updated rota.
3. Analyst: checks recent actions taken at the higher depth since the suspected start of the problem. Evidence: a list and decisions per case.
4. Process owner: records the cause once known, and what must change before depth is restored. Evidence: a short note.
5. Process owner: restores depth only through fresh certification and production evidence, as described in when an agent's depth should be widened. Evidence: the new certificate.

What does a reduction look like?

Say an insurer's agent approves small travel claims at depth 4 within the customer's limits. One Monday, the weekly review shows the share of claims held for approval has fallen sharply over a week. That looks like good news until the analyst notices that a policy wording change has removed an exclusion the agent used to check.

The owner drops claim approval to depth 2 that afternoon. Handlers start approving every claim themselves. A review of the week's approvals finds a handful of claims paid that the new wording would have declined for other reasons, and each gets a decision from a handler. The brief is updated for the new wording, certification runs on recent claims, and depth 4 returns only after the run clears and two further weeks of drafts show handlers agreeing with the agent.

The trigger was a signal moving the right way for the wrong reason. Thresholds should watch for sudden improvements as well as declines.

Which controls make reduction reliable?

• Pre-written triggers and thresholds, so nobody has to argue during an incident.
• One-step reduction that anyone on call can apply, filed automatically.
• Capability-level control, so one problem does not stop all of the agent's work.
• Staffing plans for lower depth, since reduction moves work back to people.
• The same route back up as any widening; see widening an agent's depth one capability at a time and our view that widening depth is an evidence decision, not a confidence decision.

The wider sequence is in our guide to deploying an AI agent.

Where Pryme fits

In Pryme, two reductions need no person at all: a failed Attest run drops the agent to depth 1 the same day, and so does a certificate that lapses after 90 days. Any other reduction is a setting the owner or on-call person can change at once, and each change is filed with the reason. Restoring depth always needs fresh evidence.