Admin console

The admin console is where a Mesa deployment is actually operated. Almost everything described elsewhere in these docs as "configure X" happens here rather than in the web app.

It is a separate application from the web app, at your deployment's admin address.

The sections

Fifteen, in the order they appear:

Section	Purpose
Dashboard	Overview and system status
Tenants	Organization management
Bots	Bot configuration and defaults
Channels & Groups	Tenant-scoped channel authorization and grouping — see Authorization and Bot groups
Users	App and platform users
Agent Operations	Agent status, metrics and runtime control
Agent Studio	Configure agents, tools and capabilities — see Authoring agent definitions
Mesa Apps	App instances and templates — see Apps
Tenant Entities	Ownership, publishing, usage — see the definition marketplace
Integration Catalog	Curate which integrations end users can see
Key Management	API keys and usage metering — see API keys
Archival	Message archival and storage
Interactions	Live conversation monitoring
Database	Database management and migrations
System	System settings and monitoring

Identity links, where cross-channel identities are reviewed, is reached from the user administration surfaces rather than being a top-level entry.

Common tasks

Onboarding an organization

The order matters — each step depends on the one before, and skipping the last leaves a bot that is fully configured and completely silent.

1. Tenants — create the tenant. Whoever creates it becomes its first admin and can grant further memberships from Users.
2. Key Management — add a provider key for it, or the bots cannot answer.
3. Bots — create the bots.
4. Bots — add channel integrations (Telegram token, or an email prefix).
5. Channels & Groups — authorize the chats, and assign the bots to them.

Diagnosing a silent bot

Silence is the designed response to an authorization failure, so start there rather than with the model.

1. Channels & Groups — is the chat authorized, and is this bot assigned to it?
2. Bots — is the integration enabled?
3. Key Management — does a key exist for the bot's provider, and does it read active? Remember that status reflects the last check, not a live probe.
4. Interactions — did the message arrive at all?

The full sequence, with what distinguishes each case, is in Troubleshooting.

Watching cost

Key Management carries usage metering as well as the keys. Consumption is tracked per tenant against a monthly allowance and enforced before a model call, so an over-quota tenant is refused rather than silently run up — see Multi-tenant architecture.

A note on scope

The admin console administers the whole deployment. Its surfaces are tenant-scoped where the data is tenant-owned — most pages require you to pick a tenant before they show anything, and that is the tenant selector doing its job rather than a page failing to load.