## TL;DR
The agent pages whoever the routing table says, so wrong pages mean a wrong table: stale entries for people who left, ambiguous ownership for shared services, or a table nobody updates. Fix the table as a data problem: single owner per service, verified on a schedule, with a fallback when the lookup misses. Don't fix the agent; fix what it reads.

## The query

```text
escalation agent paged the wrong on-call: routing table
```

## Use this when

- Escalations page the wrong person
- Pages go to people who left the company
- You're designing escalation routing


## Not for

- On-call schedule gaps (nobody scheduled)
- Alert fatigue from too many pages
- Paging system outages


## Steps

### 1. Audit the current routing table

Read every entry: service, owner, backup, and how to reach them. Flag entries pointing at departed employees, teams that no longer own the service, and services with no entry at all. You'll find all three.

Expected output: the table with stale, ambiguous, and missing entries flagged.

### 2. Assign one owner per service

Every service gets exactly one owning team and one escalation path. Shared ownership means nobody gets paged; the agent picks whoever the table lists first. Write the ownership down where both humans and the agent read it.

Expected output: a table with no shared or ambiguous ownership.

### 3. Verify on a schedule, not on incident

Check the table monthly against the org chart and the on-call schedules. People leave, teams reorganize, and the table rots silently between incidents. A stale table is a future wrong page.

Expected output: a monthly verification with an owner who does it.

### 4. Define the miss fallback

When the table has no entry for a service, the agent needs a defined fallback: page the platform on-call, open a ticket, or ask a human. 'No entry' must never mean 'guess'.

Expected output: a documented fallback for unmapped services.

## Variant phrasings

### escalation paged wrong person

Steps 1 and 2: audit the table, assign single owners.

### on-call routing table outdated

Step 3's scheduled verification stops the rot.

## Why it happens

Routing tables are written once and trusted forever, but orgs change constantly. The agent is the only reader that never compensates: a human paging would notice 'oh, they left' and pick someone else, but the agent follows the table literally. The wrong page is the table's staleness made visible.

## Edge cases

- On-call schedules live in the paging tool, ownership lives in the table. Keep both current; they rot independently.
- Temporary ownership (incident commander delegating) shouldn't rewrite the table. Keep overrides separate.
- Test the table with a dry-run page quarterly. An untested table is a rumor.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nSrTeQKzlphJ0TKLo9QrIg