The wake map

The wake map answers one question for every table in your tenant: what happens on this table because an agent is involved. For each table it lists every agent that wakes automatically and the event and condition that wakes it, which agent answers when someone types @agent in a comment, any chain where one agent’s finished plan wakes another, and whether the table’s Record Session is switched on and what makes it wake. The listing itself is a read-only picture of wiring that lives elsewhere, so you can see the whole table’s automation at a glance instead of opening each agent one at a time; a trigger row now also opens straight into that agent’s own Designer page, to view and change it there.

When you’d use it

Before you add a new agent to a table, to see what already wakes on it and avoid two agents fighting over the same event.
When a record was changed by an agent and you want to know why, to check which trigger and condition would have fired.
When @agent in a comment reached the wrong agent, or nobody, to see which agent is declared the table’s default and why a mention might resolve to nobody when more than one agent claims that role.
When setting up a new application, from the Setup Assistant stage, to see the same map filtered to just the tables that application owns.

What you manage

The listing itself is not edited on this page. What you see:

Admin AI → Agents (/admin/agents/wake-map), gated on platform.agents.read. One block per table, with a heading naming the table.
Each block lists the table’s triggers as one line per agent: the agent’s name, the event it wakes on, and the condition in plain language (never raw configuration). A chip marks the agent that is this table’s declared default for @agent, and a second chip names the package an agent installed with, for example “from Incident Management”, when it came from one.
A trigger line opens that agent’s own Designer page (/admin/agents/{id}) when you hold platform.agents.write, the same capability the designer’s own save already requires; without it, the line reads as plain text, the same posture the designer itself takes for a viewer without that capability. There is still no way to create a new agent from here, or from the designer it opens: customers do not build agents.
A chain line appears when one agent’s executed plan is itself what wakes another agent on the table, for example a closure reviewer’s plan waking the agent that proposed the original change.
An “@agent answers” line names the one agent a bare @agent mention resolves to on that table, following the same order the mention itself uses: the table’s declared default, then the one agent set up to handle new records, then the tenant’s general-purpose session. When nothing resolves it, the line says why.
A Record Session line states whether the table’s session is on, and if so, whether it wakes on every new record, wakes only when a condition matches, or stays silent because a specialist agent already owns the table.
The same map appears, filtered to one application’s own tables, on that application’s Setup → Assistant stage, for whoever can see that stage.

Good to know

The wake map is a read view over the same trigger rows an agent’s Designer page edits. It stores nothing of its own, so it is always exactly as current as the triggers themselves; there is no separate place for this information to go stale.
A condition is rendered as a sentence (“state changes to resolved”), not as the underlying configuration. An operator the platform does not evaluate is still shown, named, rather than silently dropped, because a condition that will never actually fire is not the same as no condition at all.
A plan-executed chain is shown for every other agent active on the table, because the underlying trigger does not filter by which agent’s plan woke it. On a table with exactly two such agents, this reads as one clean chain; on a table with several, it lists every agent whose plan could be the cause, which is the honest answer rather than a guess at the one that usually is.
Seeing an agent here requires platform.agents.read. A viewer without it on the Setup Assistant stage sees nothing from this section and gets no error, the same as the stage’s other admin-only reads.

How it connects

The wake map’s own listing does not create, edit, or delete a trigger, a chain, or a session setting; it only shows what already exists. To change what wakes an agent, open that agent’s row (or go directly to its Designer page) and edit its triggers there. To change a table’s Record Session, use that table’s Session tab. To change who answers an @agent mention from inside a comment on one record, see Record sessions; for the full agent lifecycle this map is drawn from, see The agentic loop and Triggers and events.