Managing from chat

Manage your AI Assistant tenant in the visual Console or ask the signed-in assistant to do the same work conversationally. Both surfaces use the same standalone AI Assistant management boundary at https://busymate.ai/mcp; neither borrows tools or credentials from a separate developer-tools product.

Use the Console

Every control this section describes lives in the visual Console scoped to your tenant:

• Branding — your name, logo, colors, and welcome copy.
• Governance — model policy (user-choice vs single default), your model allowlist, and limits. See Governance & model policy.
• Connectors — the tools your assistant can use. See Connecting your tools.
• Usage — how much your assistant is used, per provider and over time. See Usage & analytics.
• Handoff — turn human support on and manage the operator inbox. See Human support & handoff.

Each panel is point-and-click, changes are reviewed before they publish, and everything you can touch is your tenant's — never anyone else's.

Scoped by who you are

Management is always role-scoped, whether by console or by chat:

• A tenant admin (you) manages your own tenant — your branding, your policy, your usage. A cross-tenant change is structurally impossible for you.
• A platform operator (our team) manages tenants across the platform — creating one, verifying a domain.
• A guest gets no management at all — just help understanding what the assistant does.

Your tier is resolved from your verified sign-in, never from anything typed in a chat, so the boundary holds no matter what's asked.

Manage by chatting

Conversational management is shipped. Ask things such as "Show this tenant's integration status," "List the knowledge, skills, and plugins I can publish," "Add this MCP connector," or "Audit the last 30 days of conversations." The assistant selects the same tenant-scoped management tools used by the Console.

Inside AI Assistant, a verified tenant admin or platform operator receives the first-party platform-management connector automatically. There is no second MCP setup step in the Console and no shared application token: every call rides the signed-in person's own grant to the canonical MCP endpoint above.

The contract is deliberately simple:

• Reads run immediately. For example, get_tenant_integration, list_tenant_resources, list_tenant_conversations, and list_tenant_insights return current tenant-scoped state.
• Writes show their payload and wait for approval. For example, upsert_tenant_connector and publish_tenant_runtime do nothing until the signed-in operator confirms the exact action.
• Tenant admins are clamped to their active tenant. A model-provided tenant ID cannot cross that boundary, and membership is checked again when the tool runs.
• Platform operators use their verified operator role. Guests receive guidance only and are never given management tools.

Existing integrations may still call support-era names such as upsert_tenant_support_connector and list_support_insights. They remain callable as deprecated compatibility names, but new clients discover and should use the product-neutral aliases.

Connect from another MCP client

External MCP clients connect directly to https://busymate.ai/mcp using the product's OAuth 2.1 flow. The granted identity determines which tenants and operations are available; putting a tenant ID in a prompt or tool argument never grants access. Keep confirmation enabled for writes.

Next

• Governance & model policy — inspect or change the same policy from Console or chat.
• Usage & analytics — inspect tenant usage in Console or ask for it.
• Getting started — stand up your tenant first.