Two people, not one. A process on-call from the team that owns the agent, with authority to lower its depth at once, and a platform on-call for technical faults. Both are named on a rota that covers every hour the agent can act. If you cannot staff an hour, the agent should not hold its full depth during it.
Why is an IT on-call rota not enough?
Because most agent incidents are not outages. The agent is running, fast and available, and it is doing the wrong thing: sending letters with the wrong figure, approving claims an updated policy now excludes, routing urgent cases to the wrong team. A technical on-call engineer can see that the system is healthy. They usually cannot tell that the decisions are wrong, and they may not have the authority to stop a business process.
The person who can recognise a wrong decision is someone who knows the process. That person must be reachable and must hold the authority to act.
What does each on-call role do?
| Process on-call | Platform on-call | |
|---|---|---|
| Comes from | The operations team that owns the agent | The platform or IT team |
| Responds to | Wrong decisions, complaints, signal thresholds, held queue backlogs | Outages, connection failures, access problems |
| May do without approval | Lower any capability's depth; route work to people | Stop the agent; restore a previous version on the owner's instruction |
| May not do | Widen depth; change the brief | Change bounds or depth on their own judgement |
| Escalates to | Process owner, then risk duty officer | Platform lead, then provider support |
The key permission is asymmetric. Lowering depth makes the agent safer, so it needs no second signature. Widening it, or changing what the agent does, never happens on call.
How is on-call assigned and recorded?
- Process owner: names the process on-call rota for each agent, with deputies. Evidence: a filed rota.
- Platform lead: names the platform on-call rota. Evidence: a filed rota.
- Process owner: matches the agent's depth to cover. If nobody is on call overnight, capabilities at depth 3 or above drop to depth 2 or pause outside covered hours. Evidence: a depth schedule.
- Platform: records every on-call action as a verdict naming the person, the time and the reason. Evidence: the filed record.
- Team lead: reviews on-call actions weekly, including false alarms. Evidence: review notes.
How does the on-call person find out what happened?
From the record. Each action an agent takes, including each call to a connected system, is a decision with a filed verdict naming the bound that decided it. That is the idea behind every tool call being a decision: when something goes wrong at night, the person on call can see exactly what the agent did and why it was allowed, without waking the people who built it.
What does on-call look like in practice?
Say an online lender's collections agent sends payment reminders and agrees short payment-date moves at depth 3, from seven in the morning to nine at night. The collections team runs a process on-call rota across those hours, with one team lead each shift. The platform team covers its usual hours with an out-of-hours engineer.
One evening, a customer complaint reaches the duty team lead: the agent has moved a payment date for a customer who has already been passed to an external recovery process. The team lead drops the payment-date capability to depth 2, so further moves wait for a person, and reminders keep going. They check the record, which shows the agent read a status field that had not yet been updated for recent referrals. The platform engineer is not needed. The next morning the process owner opens a fix to the source.
At nine at night the agent stops acting. Nothing waits for an on-call person overnight, because there is no on-call person overnight.
Which controls keep on-call meaningful?
- Authority written down, so the person on call does not hesitate to lower depth.
- Depth tied to cover, so the agent never acts unsupervised for hours nobody covers.
- No releases outside covered hours. Changes go live when the people who can spot their effects are on duty, a point covered in updating an AI agent without breaking it.
- Runbook access from wherever on-call staff work.
The wider sequence is in our guide to deploying an AI agent.
Where Pryme fits
In Pryme, lowering a capability's depth is a single change that takes effect at the moment of the next action and is filed with the person and the reason. Widening is not available on call: depth is earned through Attest evidence on your cases, up to the role's ceiling, whichever is lower.
Questions people ask
Can the agent's vendor be on call for us?
For platform faults, a vendor can be part of the escalation route. For decisions about your process and customers, the process on-call must be your own staff.
Should the process owner always be on call?
No. The owner should be the last escalation point, not the first. Team leads with clear authority make better first responders and spread the load.
What if the on-call person lowers depth unnecessarily?
That is an acceptable cost. Review false alarms to refine thresholds, but never discourage people from lowering depth when unsure.