On-Call Rotation for AI Agents: Who Gets Paged, and When

An AI agent that runs outside business hours needs the same operating discipline as any production system: one named person accountable for each decision, a written escalation path for when that person does not answer, and a response window that matches how much damage a failure could do before someone looks at it. Assign those three things before the first unattended run, and keep them where the business owner and the on-call person can both read them. The sections below show how to set each one up, with a decision guide for what pages whom and a checklist for the first rotation.

Key takeaways

• Name one accountable owner and one named backup for every agent, not a shared team inbox.
• Route events by type: permission and data events, output quality problems and availability failures go to different people.
• Set response windows by severity, and write down what the agent does while a page is open.
• Give one person the authority to pause outbound actions, and test that pause before the first off-hours run.
• Review pages, missed pages and changes every quarter from the logs, not from memory.

Why an agent needs a rotation, not just a dashboard

A dashboard tells you that something happened. A rotation decides who has to act when it happens. For conventional software the gap is often small, because a failed job usually stops and waits. An agent behaves differently. It reads incoming messages, calls tools, writes to records and sends replies on its own schedule, so a fault at night can keep producing output until someone intervenes.

The observability vocabulary helps here. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) describes how traces, metrics and logs let teams reconstruct what a system did and why. Those signals are only useful when a named person is responsible for reading them and deciding what to do. Telemetry without an owner becomes a record of the incident instead of a way to stop it.

Before you write any schedule, separate three ideas. An alert is a signal. A page is a request for a human to act now. A ticket is work that can wait until business hours. Most early rotations fail because every alert becomes a page. That trains the on-call person to ignore pages, and then the one that matters gets lost.

Name the owners before you name the schedule

Each agent needs four roles filled by people, not by functions or mailboxes. Write a name and a backup for each role, and check that both people still hold the role every quarter.

• Business owner: decides what the agent is for, accepts its operating risk and signs off on scope changes. This is usually the leader whose process the agent supports.
• Operator: receives pages, runs the runbook and decides whether to pause the agent. This person needs read access to logs and the authority to change configuration.
• Permission approver: approves any new tool, data source or write action. Depending on what the agent touches, this role often sits with security, finance or legal.
• Escalation contact: the senior person reached when customers, money, personal data or a commitment to a regulator may be affected. In many companies this is the executive sponsor.

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) places governance and accountability at the center of managing AI risk, which is why these roles belong in writing before the first incident, not in a discussion during one. Access rules follow the same logic. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is built on checking every action against an explicit rule. Apply that to people as well: the operator should be able to pause the agent, but should not be able to grant it new permissions on a night shift.

Decide what pages whom: a decision guide

Sort every possible event with four questions. Is the action reversible? Does it reach an outside person or system? Does it touch money, personal data or a commitment the company has already made? Is the agent still inside its approved boundary? The answers place each event in one of three routes.

• Page now: the agent sent or is about to send an external message it should not have, took a write action outside its permission set, may have exposed a credential or personal data, or is repeating a failing tool call that creates duplicate records or unauthorized changes.
• Handle by the next business morning: output quality drifts on low-risk internal summaries, a non-critical integration returns warnings, or response times slow without any loss of accuracy.
• Ticket only: cost trends that need review, wording suggestions for prompts or tool descriptions, and user requests for new capabilities.

One category deserves special attention. Content that enters the agent from outside, such as a customer message or a retrieved document, can contain instructions meant to change what the agent does. The [OWASP prompt injection prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes this class of risk. When that content tries to alter tools, permissions or outbound behavior, treat it as a page-now event, and make sure the operator can see the input that triggered it.

Set response windows and the safe state

A response window is the time between a page and a human action. Set it from the cost of waiting, not from what feels comfortable. For a page-now event, the window is the time in which harm could grow. For each severity, write two limits: how long until a person acknowledges the page, and how long until the agent is in a known, stable state.

Use this sequence to set them:

1. List every action the agent can take and mark each one reversible or not. Drafting, reading and internal notes are usually reversible. External emails, payments and deleted records are not. 2. For each irreversible action, define the safe state. In most cases this means the agent keeps reading, queues its outbound actions and stops calling write tools. 3. Set the acknowledgment window for page-now events. Keep it short enough that a person can respond from a phone, and long enough that a sleeping person is not woken by noise that a ticket would handle. 4. Set the resolution window: the time by which the operator either restores normal operation or keeps the agent paused and informs the business owner. 5. Name who can trigger the safe state, and confirm they can do it without a deployment or a change request. Test the pause once, with the operator present. 6. Store the windows in the operating record next to the permission list. Changing them should follow the same approval path as changing permissions, as described in operating hours and limits for AI agents.

Illustrative scenario: a company runs an agent that drafts replies to supplier questions overnight, and staff approve each reply before it is sent. A configuration change at 11 p.m. removes the approval step, so the agent begins sending replies directly. The page-now rule fires because outbound actions have no approval record. The operator on the first rotation pauses outbound sending from a phone within the acknowledgment window, and the queued drafts wait for the morning. The business owner receives a short note listing what was sent before the pause.

Build the escalation path and the runbook

An escalation path is a sequence with time limits. If the operator does not acknowledge within the window, the page goes to the backup. If the backup does not acknowledge, it goes to the business owner. The escalation contact is reached only when customers, money, personal data or a legal commitment may be affected. Write the sequence with its time limits, so nobody has to decide the order at 2 a.m.

The runbook is the document the on-call person uses while the page is open. It should be short enough to read on a phone and specific enough that someone who has never operated the agent can follow it. Include:

• What each alert means in plain language, and which route it belongs to.
• The agent's identity, its tools, the scope each tool holds and the data sources it can read.
• The safe-state steps, written as numbered actions with the exact control to use.
• The last known good configuration and where it is stored.
• Who to inform, in what order, with a short message template for the business owner.
• What to record: timestamps, actions taken, decisions made and whether the page was a true or false alarm.

If the operator and the backup work in different time zones or languages, state the hours each person covers and what happens at handover. A handover is safe only when the outgoing person writes down every open event. For teams working in English and Portuguese, keep the safe-state steps in one language so nobody misreads them under pressure, and translate the rest.

How Be Human runs the rotation with your team

Be Human designs and operates personalized AI agents, and the rotation is set up as part of the first engagement rather than added after the first incident. The scope defines the role, the memory and tools the agent needs, its approval boundaries and the success criterion that the rotation protects. In managed operations, Be Human can run monitoring, recurring evaluations, permission review and incident response, and it keeps the runbook and escalation path current as the agent changes. Changes to windows, routes or permissions go through the same request and approval steps as other changes, so the client's business owner and operator keep the decisions that matter.

Review the rotation on a fixed schedule, not only when something breaks. Each quarter, count the pages by type, the pages that turned out to be noise, the pages acknowledged late and the events that should have paged but did not. Compare the list of named owners with the people who still hold those roles. Confirm that the safe-state step still works after recent configuration changes. Use the permission review steps to check that each tool scope still matches the work. The first months are when the rotation needs the most adjustment, as outlined in what the first months with a managed AI agent look like.

If you are unsure which task should go to an agent first, and therefore which owner and response window it will need, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Who should be the on-call owner for an AI agent? The operator should be a named person with read access to the agent's logs and the authority to pause its outbound actions, usually someone from the team that runs the process the agent supports or from the group that maintains it. Name a backup as well, and make sure both people have read the runbook. A shared inbox is not an owner, because nobody is accountable for answering it.

How long should the response window be? There is no universal number, so set the window for each severity from the cost of waiting. Page-now events should have the shortest acknowledgment window, because the agent may be causing harm while the page is open. Internal drafts and low-risk quality issues can usually wait until the next business morning.

Does every agent need an overnight rotation? Not every agent needs someone awake at night. If the agent only drafts internal material or performs reversible tasks, a ticket queue and a next-morning review may be enough. Agents that send messages, change records or touch money or personal data outside business hours need a tested page route and a safe state.

What happens if nobody answers the page? The escalation path moves to the backup, then to the business owner, and then to the escalation contact if customers, money, personal data or commitments may be affected. The agent should already be in its safe state by then, with outbound actions paused and queued, so the cost of silence is delay rather than further harm.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.