Dashboard

The Dashboard is the admin panel’s home page. Where it sits depends on the build:

• With managed services it is a workspace’s view, at /organizations/{org}/workspaces/{ws}: the first screen after sign-in (the workspace you used last, else the organization’s default) and the first entry of the workspace’s sidebar. It needs analytics:read; a custom role without it is sent on to the agent list instead. The organization’s own address, /organizations/{org}, is the organization’s home, a separate page.
• On the open-source build it is the organization’s view, at /organizations/{org}, and the first sidebar entry. A workspace has no home page of its own there: /organizations/{org}/workspaces/{ws} opens its agent list.

Both carry the First steps card of the first-access guidance while any setup step is still open.

The workspace dashboard exists for a reason worth knowing. The dashboard used to be organization-wide and gated on org:read, the membership floor every role holds: someone who works in one team landed on the tenant’s total, their own team’s numbers were nowhere, and what every workspace spends was readable by anyone inside the tenant.

What it shows

Two questions, in this order: which agents want looking at, and then the volume.

The first half is an exception report - the agents whose checks are not clean, counted and openable. The second is the familiar analytics: messages handled, tool calls executed, median response time, estimated cost, each compared with the previous period, sliced per agent and drawn over time.

On the open-source build the dashboard shows the analytics half, for the whole organization.

The same data scoped to a single agent lives in that agent’s Dashboard section (see Analytics).

One rule across three tiers

The exception report is not three reports that happen to look alike. A platform admin asks which organization needs them, an owner which workspace, a team which agent - one rule, evaluated at whichever tier you are standing on. An agent is the base case: a subject that holds exactly itself, which is why two of the five kinds of exception cannot apply to it.

Counts drill down. An organization counts its workspaces, a workspace counts its agents, and the agent’s Status section lists the same checks one by one - a count is always openable at the rows that produced it.

That is the whole point of the redesign. The first version of these dashboards invented a second vocabulary beside the checks the agent’s own Status page already had, and one of them was an outright duplicate. Two vocabularies mean the tiers can disagree, and a reader who cannot reconcile two numbers stops trusting both. The two facts that were genuinely missing - an agent that never answered, an agent gone dormant - became checks rather than a list of their own, so they carry a destination and can be silenced like everything else.

A dismissal holds at every tier. A check silenced on an agent stops colouring the workspace and the organization rows above it. It is still returned and marked as dismissed rather than dropped: a dismissal nobody can see or undo is a deleted check.

The organization’s home

Managed services.

The organization’s address, /organizations/{org}, is its home: the Dashboard entry of the organization’s sidebar, opened from Organization at the sidebar’s foot. Signing in lands in a workspace rather than here; the home is a place you go to. The former Settings section Overview (/organizations/{org}/settings/organization/overview) forwards here.

Every member of the organization can open it, and the page decides what each reader sees:

• Agents. The organization’s agents in the workspaces you can read (agent:read in that workspace), each with its workspace and status, opening on click. Where you also hold analytics:read in a workspace, its agents show their conversations and cost for the period. Someone with no workspace at all is told so, with a way to contact the organization’s administrators. The list is GET /api/organizations/{org}/agents.
• The organization-wide reading, behind org.analytics:read (Owner and Admin): the organization’s spend cap when one is set, the workspaces whose checks are not clean, the comparison of workspaces, and the trend over time, whose tiles carry the period’s total spend and conversations. The per-workspace breakdown is the disclosure that needed a key of its own: what each team spends is not something every member should read.

One period picker at the top sets the period for all of it. It is shown only to someone who can read some of the figures.

Not the same as the platform Overview

A platform admin also has an Overview at the top of the Admin Console (/platform/analytics). The two differ in the question, not merely in the scope:

• The tenant pages explain one tenancy over time - trends, channels, models. The questions of someone who works there.
• The platform Overview is a ranking plus an exception report - the same “worth a look” list one tier up, then the organizations ordered by spend with each one’s share beside it. The Deployment trend renders last: the organization dashboard’s trend section (KPI tiles, cost and conversation trends, response time, tools, when people write, agent comparison) read across every organization, following the page’s period picker. It comes last because a number spanning every tenant reads as a headline and pushes the actual answers below the fold. It is served by GET /api/platform/analytics/trend, for platform admins only.

A platform admin cannot read thirty copies of a tenant dashboard, and a deployment-wide total answers nothing either - the biggest tenant is always the biggest.