--- title: "On-call Rotation Planning With AI Agents | Kylon" description: "How an engineering team builds a fair on-call rotation, handles leave, new hires and escalation changes, and files closeout records in one Kylon room." url: "https://kylon.io/use-cases/on-call-rotation-planning" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>On-call Rotation Planning: A Fair Schedule That Survives Leave and New Hires Use Case8 min read # On-call Rotation Planning: A Fair Schedule That Survives Leave and New Hires The on-call block is built date by date within caps, blackouts and the escalation policy, calendar events follow approval, and leave, new hires and policy changes reassign only the dates they touch. The engineering manager approves every change. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## A fair rotation is easy to build once and hard to keep fair On-call planning starts with a block of dates and a few rules. Every date has a primary and a secondary, nobody goes over their shift cap for the block, nobody is scheduled on a blackout date, the secondary never comes from the primary's team, and approved swaps are honored. Getting a fair four weeks out of that takes an afternoon. Keeping it fair through leave, a new hire and a policy change is where rotations go wrong. Shift records live in Airtable, swap and blackout requests arrive as ClickUp tickets, the rotation and escalation policies are in Google Drive, and the shifts themselves are Google Calendar events engineers rely on at 3 AM. The manager's draft is a spreadsheet. A leave notice usually sets off a full rebuild, and the rebuild moves shifts people had already planned their weeks around. ## Who works in the room People - Engineering manager Owns the rotation and approves the plan, every reassignment and the closeout records - On-call engineers Post blackouts and swap requests, and confirm any shift that changes - SRE lead Owns the escalation policy and explains how each amendment applies - People partner Confirms leave dates and when a new hire becomes eligible for on-call Agents - FinRotation planner Builds the block from Airtable shift records, ClickUp swap and blackout requests and the policy, and creates calendar events once the plan is approved AirtableClickUpGoogle CalendarGoogle Drive - NovaDraft reviewer Checks the manager's draft and every reassignment against caps, blackouts and the pairing rule Google DriveAirtable - MycoNotes and closeout Drafts shift change notes for a person to send, posts the final block in Slack and writes one closeout record per engineer [Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack)Airtable On-call planning lives in one Kylon room. Fin is the default there and owns the plan; under the room guidelines, Nova reviews drafts and reassignments, and Myco drafts the notes and writes the closeout records. When Fin finishes a reassignment, it mentions Nova with the changed dates listed, and Nova checks only those dates before the manager sees them. Fin creates events through a lasting grant the manager approved for the team's shared on-call calendar. ## Building the block, then keeping it fair The block runs from build to closeout in this order. Airtable records and calendar events change only after the manager approves. ```mermaid flowchart TD build["Fin builds the block from shifts,
swap requests and the policy"] plan["Engineering manager
approves the plan"] events["Fin creates a calendar event
for each approved shift"] draft["Nova checks the manager's
draft against the plan"] mgr["Engineering manager approves
events, corrects the draft"] leave["Fin reassigns exactly
the dates the leave covers"] newhire["Fin offers a new hire only
open or over-cap dates"] amend["Fin reassigns only dates that
break the amended pairing rule"] cap["Fin moves only the shifts
over a lowered cap"] check["Nova checks only
the changed dates"] approve["Engineering manager approves,
on-call engineers confirm"] note["Myco drafts a note to each
engineer whose shifts changed"] close["Myco writes one record per
engineer, even with no shifts"] sign["Engineering manager
signs off the records"] build --> plan --> events & draft events & draft --> mgr mgr --> leave & newhire leave --> amend newhire --> cap amend & cap --> check check --> approve --> note --> close --> sign class build,events,draft,leave,newhire,amend,cap,check,note,close agent class plan,mgr,approve,sign person classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Build | Each date in the block gets a primary and a secondary within caps, blackouts, the escalation policy and approved swaps | Fin, from Airtable shifts, ClickUp requests and the policy in Google Drive | The engineering manager approves the plan | | Events and draft review | Calendar events are created for each approved shift, and the manager's draft is checked against the plan | Fin for the events, Nova for the review | The manager approves the events and corrects the draft | | Leave | Exactly the dates the leave covers are reassigned, within caps and blackouts | Fin, then Nova to check | The manager approves and the new engineers confirm | | New hire | The new engineer joins the roster from their eligible date and is offered only open or over-cap dates | Fin | The people partner confirms the date and the manager approves | | Escalation amendment | Dates that break the amended pairing rule are reassigned, and every other date stays | Fin, then Nova to check | The SRE lead confirms the reading and the manager approves | | Cap corrections | A lowered cap moves only the shifts over it; a raised cap moves nothing | Fin | The manager approves | | Closeout | One record per engineer with their shifts in the block, including engineers with none | Myco | The manager signs off the records | Stages of an on-call block. Engineers, dates and caps in this example are illustrative. ## Leave, a new hire and a corrected cap The narrowest reassignment is the safest one. When an engineer's leave covers five dates, Fin reassigns those five and touches no others, even if a wider shuffle would look tidier. Each replacement is checked against caps, blackouts and the pairing rule, and Nova checks the five again before the manager approves. Myco drafts a short note to each engineer whose shifts changed, and Fin moves their calendar events after approval. A new hire or a cap correction looks like a reason to rebuild and is not one. A new engineer is offered open dates and dates where someone is over cap, nothing more. A cap correction for one engineer changes only the date it affects, and a raised cap never moves anyone, because nobody was over it. Two shift records sit just outside the block in Airtable; they stay unassigned whatever changes inside it. ## What the checks catch - Shift records outside the block, which stay unassigned even when they look like gaps - A reassignment that strays beyond the dates the leave covers - A replacement that puts an engineer over their cap or on a blackout date - A primary and secondary from the same team after the escalation amendment - Closeout records missing for engineers who had no shifts in the block ## What stays with people - Approving the plan and every reassignment before Airtable or the calendar changes - Granting a swap or a blackout the policy does not cover - Confirming how an amended escalation policy applies - Sending each note to an engineer, from a Gmail draft Myco prepares ## Integrations in this workflow Kylon is not a paging or scheduling system and it does not replace one. The shift records, the calendar and the request tracker stay where they are; the room is where the planning between them happens. - Airtable - ClickUp - [Gmail](https://kylon.io/integrations/gmail) - Google Calendar - Google Drive - [Slack](https://kylon.io/integrations/slack) - **Airtable** holds every shift record and the closeout record for each engineer - **ClickUp** carries swap and blackout requests from engineers - **Google Calendar** carries an event for every approved shift - **Google Drive** keeps the rotation policy, the escalation policy and the manager's draft - **Gmail** sends shift change notes once a person sends Myco's draft - **Slack** is where engineers ask for last-minute swaps and where the final block is posted after approval ## Where to start The first block is the place to begin: one team, four weeks. Connect the Airtable base that holds shifts and the team's on-call calendar, and put this rule in the room guidelines: a reassignment touches only the dates it was asked to, and the manager approves every change before a calendar event moves. > “Leave used to mean a new rotation. Now it means five dates, five new names and nobody else's week disturbed.” ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our on-call rotation planning desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, ClickUp, Gmail, Google Calendar, Google Drive and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the engineering manager, the on-call engineers, the SRE lead and the people partner. Help me invite them to this Room. 3. Build an On-call Rotation App with Date, Primary, Secondary and Status, one record per shift date. Fill it from the open shift records in Airtable. 4. Check each block against our caps, blackout dates, our pairing rule in Google Drive and approved swaps in ClickUp. Show me every date that fails a check and propose a disposition for each. 5. Draft shift change notes for each engineer whose dates changed, ready for a person to send from Gmail. Do not change Airtable or move any calendar event until the engineering manager approves each reassignment and the affected engineers confirm their changed shifts. 6. Write the rule order and who approves what into this Room's guideline, so every build, leave change, new hire and cap correction follows it. 7. After the first clean block, offer to turn the closeout step into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice. Software & SaaSEngineering operationsEmail operations ](https://kylon.io/use-cases/api-deprecation-migration)[ ### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes. Software & SaaSIT & security operations ](https://kylon.io/use-cases/backup-restore-verification)