GET /api/supervision/sessions lists sessions with their owner, so an operator can audit
what ran on the platform rather than guessing from logs. The same entitlement governs the
session trace route.
Each row carries session_id, app_name, agent_name, user_id, create_time,
update_time, a preview of the opening question, and counts: steps, tool_calls,
has_error. The preview is what makes the list scannable — without it, hundreds of runs
of the same agent read identically. Paginate with limit (200 by default) and offset;
total is the unpaginated count.
Who sees what
In this edition, each person sees their own sessions. That is not a limitation to work around — it is the only default the core can honestly hold. Reading someone else’s sessions is a privilege, and the core cannot decide who holds it: the notion of a platform owner lives in a table owned by a commercial brick, and the core must never name one. So it asks, through a registry hook. With no brick registered, the answer is no.Grouping sessions
Group and filter byapp_name, never by agent_name. app_name is derived from the
agent’s id (agent<id>), so it identifies one agent and one owner. agent_name is a
label and is not unique across the platform — the same name can belong to several
accounts — so grouping on it merges unrelated people’s sessions into one row.
