The platform admin console is the operator-only surface at /admin. It's where you manage plans, watch usage across every workspace, retry failed jobs, and impersonate customers for support. Only users with role = super_admin can see it — everyone else gets a 404 (not 403) so the panel doesn't even reveal it exists.

Becoming a super admin

The flag is the users.role column, cast to the PlatformRole enum which has two cases: customer (the default for every signup) and super_admin. There's no UI to grant it — it's set by hand via tinker or a one-shot migration on a new deployment:

php artisan tinker --execute 'User::where("email", "you@company.com")->update(["role" => "super_admin"]);'

Demoting works the same way (role = "customer"). There's no notification — the next page load will show or hide the admin nav.

Layout

The admin sidebar lists ten sections:

• Dashboard — KPIs across all workspaces, system health summary.
• Workspaces — every workspace, their plan, owner, member count, conversation usage.
• Users — every user across the platform, their workspaces, last seen.
• Agents — every agent on the platform, with workspace + publish state. Inline rename, publish toggle, and Delete — destroy bypasses WorkspaceScope so super_admin can clean up phantom agents whose workspace_id points at a workspace the original customer no longer has as their current context (those agents 404 from the customer-side editor).
• Conversations — every conversation. Useful for support.
• Leads — every lead.
• Plans — Stripe-synced plan CRUD. See Plans & Stripe sync.
• Subscriptions — every active subscription. Reverse-lookup workspaces by Stripe subscription ID.
• Usage — month-over-month conversation count by workspace.
• Queue Failures — failed jobs with retry / forget controls.

Header actions

The admin header (top bar of every admin page) has:

• Site Health pill — green / amber / red. Hover for the breakdown — failed jobs, Stripe config, LLM provider, vector store, mail driver, Reverb keys, cache. See Site health & failed jobs.
• Notifications dropdown — unread alerts from two streams:
  • Health failures (critical / warning severity) — failed jobs, missing Stripe key, missing LLM provider, mail not configured, etc. These paint the bell red and increment the site_health.issues_count.
  • Business events (info severity, last 24 hours) — new users signed up, new workspaces created, new paid subscriptions, new leads captured platform-wide. Info severity only; the bell stays neutral but you see what just happened.
  Cached 60 seconds. Both streams merge into one dropdown — health failures appear first, biz events below.
• Global search — searches workspaces, users, agents, conversations, leads with one keystroke.

Daily admin digest

Opt-in via Settings → System → Mail → Daily admin digest (checkbox). When enabled, every super_admin receives an email at 09:00 UTC summarising the previous 24 hours:

• New users signed up
• New workspaces created
• New paid subscriptions
• New leads captured
• Conversations active right now

The scheduled command is php artisan admin:send-daily-digest; it short-circuits with an "info" log line when the setting is off, so you can leave the schedule wired without spamming installs that opted out. --force bypasses the flag for one-off previews; --dry-run computes the digest and prints it without sending mail.

Impersonation

From the Workspaces or Users page, click Impersonate. A few things happen:

1. Your admin session is preserved.
2. You become the target user inside their workspace.
3. A persistent You're impersonating X banner appears at the top of every page until you stop.
4. A row is logged in audit_logs so the action is traceable.

Click Stop impersonating in the banner to drop back to your admin session. The banner is intentionally hard to miss — there's no shortcut to dismiss it without ending the impersonation.

Search

Press / from anywhere in the admin panel. The global search dropdown opens with sections:

• Workspaces (by name).
• Users (by email).
• Agents (by name + workspace).
• Conversations (by message text).
• Leads (by name + email).

Each result links straight to the resource. The customer surface has the same search but scoped to the current workspace.

Audit log

Every admin action — plan create/update/delete, impersonation start/stop, workspace changes — writes to the audit_logs table for forensic traceability. There's no UI page for browsing audit logs in v1; query the table directly when you need to investigate.