Admin Panel - Overview

This page is your map of the admin panel. Every screen mentioned here gets its own dedicated page in this section - this is the directory.

Layout

The admin panel uses a fixed two-column layout:

• Sidebar (left) - navigation. Collapses to icon-only mode (the state is remembered in a browser cookie).
• Header (top) - the tenancy breadcrumb on the left, then global controls: the activity ticker, the Help menu, language toggle, theme toggle, and the sidebar collapse handle.
• Main area - the page content.

There is only ever one column of navigation. The panel has no second rail beside the sidebar: entering a configuration area replaces the sidebar’s contents with that area’s index plus a way back out. See Destinations below.

Addresses are tenant-scoped

Every screen carries the tenant it acts in in its URL, so a page can never claim a narrower or wider scope than the API enforces. There are four address roots:

The organization and the workspace are read from the path, never from hidden state, and the panel sends them on every API call as the X-Org-Slug and X-Workspace-Slug headers. The engine treats the workspace segment as authoritative: a workspace slug the caller cannot reach is refused rather than silently falling back to another one.

Sidebar navigation - the daily work

Nine entries, under two headings that say which tenant level each answers to. An entry appears only when the operator holds the permission its own page needs, so nothing on the list leads to a 403.

Organization

Workspace

Switching workspace changes the data behind all seven.

Scheduled tasks do not have a sidebar entry - they live inside an agent, on the Automation row of its Behaviour group.

Destinations

Three areas take over the sidebar instead of appearing as an entry in it. Each one replaces the nine daily entries with its own index and a link back.

The footer entry for Settings and for the Admin Console links to the first section the operator can actually open, and that same test decides whether the entry is shown at all. Because every organization section is permission-gated, Settings is withheld below Admin rather than linking to an empty list.

Settings itself has two tiers: sections that configure the organization, and sections that configure the workspace you are currently acting in.

Settings (workspace tier)

Both edit which skills and plugins the workspace may draw on. Neither requires a licence entitlement - the permission alone decides, and it is held by Admin and above.

Settings (organization tier)

The organization’s two-factor mandate is a section of General, not an entry of its own - see Authentication.

Admin Console (installation tier)

Every section here is platform-admin-only, with one deliberate exception: Organizations is permission-gated instead, so an Owner holding the multi-organization licence reaches the organization list without being a platform admin.

A missing permission hides a section outright. A missing licence entitlement shows it with a plan badge instead - the engine refuses the route either way, so the difference is presentation, not authorization.

An agent

An agent’s sections are rows in the sidebar, under five headings. There is no tab row above the page: the whole vocabulary is visible, and each section is one click away. The three automation sections share one Automation row in the Behaviour group, whose page holds three tabs: Webhooks, Scheduled and Room.

Dev mode is shown only where dev mode has been granted, and Spend cap is available with managed services.

Two things to know when looking for something that moved:

• A section is a place you go; a lone switch is a row on a page. Several one-toggle sections were merged into the page they belong to. The six per-channel sections became one Channels with the channel picked inside it. Logs holds the tool traces, the task and webhook runs, the governance events and the retention runs, one tab each (Tool Traces, Webhooks, Scheduled, Governance, Retention), because all of them are a record of what happened rather than configuration. There is no Credentials or Parameters section: a provider key is set in the Model section, in the block of the task that uses it (with managed services, a provider connection is bound in the Providers section), a tool’s keys and parameters in that tool’s panel, and a hook’s on the Hooks page.
• The address is still ?tab=<section>, and there is no alias table. A ?tab= value that no longer names a section lands on Status, like any other unknown value. The merged-away addresses - mcp and retention aside, which came back - are exactly that: runs, governanceEvents, traces, channelWeb … channelAgent, triggers.

The Activity group is the newer idea: an agent’s conversations, memories, tool traces and runs read inside the agent, rather than only in the workspace-wide lists. The sidebar entries for those still exist and still span the workspace; these are the same data narrowed to one agent.

The tenant switcher and the breadcrumb

The tenant switcher sits with the daily navigation, not inside a destination - inside one it would silently re-point the page being configured. Switching organization or workspace keeps the page you are on rather than sending you back to Agents; a detail page (one agent) truncates to its list, since an agent slug means nothing in another tenant.

The breadcrumb in the header states the tenancy only - organization › workspace › agent - because the section you are on is already the sidebar’s active row. The agent crumb shows its slug, which is the product’s external contract.

Command palette

⌘K / Ctrl-K opens a palette indexing every sidebar entry and every configuration section, grouped by tier. It is built from the same registries the navigation renders from, so it can never offer something that does not exist.

Header controls

• Activity ticker - the live feed of what agents are doing right now.
• Help - reopens the first-access guidance and links to the documentation, the marketplace and the Polyant site, each in a new tab.
• Language toggle - switches the entire UI between English (EN) and Italian (IT). Live, no reload. Persisted to local storage.
• Theme toggle - light or dark.
• Sidebar trigger - collapses the sidebar to icons only.

First-access guidance

A new account is guided through the panel the first time it opens it. What it is offered depends on what it may do:

• Guided setup. A full-screen wizard for someone who can create agents: a short welcome, then a model provider and its key, the model, the agent (name and instructions), a test chat, the agent’s channels and key, and optional knowledge. The test chat uses the panel session like the Playground, so it works before any channel is on. When it ends, the interface tour follows: a few steps over the dashboard, the menu, agents, conversations, the Playground and Settings.
• Interface tour only, for someone whose role cannot create agents. On the open-source build every new account is offered the guided setup; the split by role applies with managed services.
• Agent tour. The first time a person opens an existing agent’s page, a small prompt offers a tour of its sections (Status, General, Model, Providers where present, Prompts, Tools, Channels, Knowledge, Advanced).

Every step can be skipped, and each part can be dismissed for good (Don’t show again). Skipped setup steps stay on the Dashboard in a First steps card, with a Resume button. The Help menu in the header, top right, reopens all three at any time: Guided setup, Interface tour, and Tour of this page while an agent is open.

The state belongs to the person, not to the browser: the engine stores it per user, so it follows them across devices. GET /api/me returns it as onboarding, and PATCH /api/me/onboarding writes it. Accounts that existed when the deployment was upgraded to 1.2.0 start with everything dismissed, so nobody who already uses the panel is interrupted; the Help menu still reopens it. With managed services, the guidance is not offered while a platform admin is impersonating someone.

Persistent UI state

1. Sidebar collapse state (cookie).
2. Language preference (local storage).
3. Theme preference (local storage).
4. The last workspace you worked in - stored server-side per organization, so a returning operator resumes there. There is no active-workspace cookie: the URL is the only answer to “which workspace am I in”.

Authentication state is in the authjs.session-token cookie; see Authentication.

Conventions used by every page

The admin panel follows a few consistent patterns. Knowing them makes new screens easy to predict.

• Search inputs are debounced. The list refreshes about 250 ms after you stop typing.
• Dangerous actions confirm first. Delete buttons always open an alert dialog with an explicit confirmation.
• Tables use pagination. Conversations show 20 per page; audit logs show 30 per page.
• Long-running actions show a spinner. Channel start/stop and bulk imports surface progress in the toast bar at the bottom right.
• Forms save explicitly. No edit auto-saves: there is always a Save button, and a “You have unsaved changes” warning if you navigate away.