Skip to main content
The Studio administration console is where you set up the support operation: the people and channels responsible for cases, agents and their connections, shared knowledge, available models and tools, and the controls on customer and internal systems. Open the organization menu and choose the administration action. The console is organization-scoped; verify the organization name before making a change. For a first support workflow, enable workers as the owner, prepare its channel and responders, connect the required service accounts, and configure the agent’s stages, limits, and approvals. Activate it for a controlled case and verify the external ticket and system result before enabling unattended triggers. Use Run the full support loop for the design and AI support agents for setup.

Administration areas

Administrative access does not reveal every personal credential. Policy controls availability; credentials remain in their configured personal or shared scope.

Members and roles

The Members page lists active members and pending invitations. Owners and admins can invite by email, change roles, revoke invitations, open a member record, and remove access. Pending invitations do not have member context or preloaded-tool settings until the invite is accepted.

Member context

Member context describes a person’s role, scope, responsibilities, and working preferences to organization-scoped AI. An admin can set one of two policies:
  • Self-edit — the member can update their context from Settings → Profile.
  • Admin-managed — the member can see the context but only an admin can change it.
Use member context for durable operating information, not performance notes or secrets. For example:
Senior network engineer responsible for EMEA production. Prefer read-only evidence before a change plan. Escalate firewall policy decisions to the security team.

Preloaded tools

Preloading makes selected built-in domains, connectors, or MCP tools discoverable at the start of a member’s new conversations. It does not bypass organization or channel restrictions and does not provide a credential. Preload tools that a member uses routinely. Leave one-off or high-risk tools discoverable on demand so the initial context stays focused.

Effective access

The member detail view includes a read-only effective-policy preview. Use it to answer:
  • Which built-in domains and tools can this member use?
  • Which organization connectors and MCP tools remain available after member policy?
  • Which credentials are ready, missing, personal, or shared?
  • Which tools are merely preloaded versus actually permitted?
The active channel can narrow this result further. Test a real conversation in the intended channel before declaring a rollout complete.

Organization context

Organization context is shared grounding applied to organization AI work. The current editor supports up to 32,000 characters. Include stable rules and definitions:
  • Trust boundaries, environment names, and customer terminology.
  • Required approval and change-management practices.
  • Default escalation contacts or team names.
  • Evidence and reporting conventions.
  • Organization-wide exclusions, such as systems Copilot must never mutate.
Keep volatile incident state in a channel, conversation, artifact, or memory instead. Never place credentials in context.

Teams and channels

Teams group members for organizational and sharing purposes. Channels are the active operating boundary for conversations, context, tool policy, and workers. Use teams to represent stable groups such as NOC, field engineering, or security. Use channels for a workstream such as a customer, service, incident queue, or project. See Channels and the chat board for channel roles and settings.

Integrations

The Plugins page is the organization catalog for connectors and MCP servers. An admin can create or edit definitions, inspect a published MCP tool catalog, set organization availability, and choose how credentials are supplied.

Definition and credential scope

Separate the shared definition from the credential used to call it: Use personal credentials when the external system must attribute actions to an individual. Use a shared credential for a service identity whose access and audit ownership are intentionally organization-wide. OAuth authorization-code credentials are stored as private per-member entries unless an explicitly supported shared-service flow is configured. Studio surfaces missing-account markers without exposing the token to an admin.

Tool availability

For MCP servers, Studio can publish the server’s tool catalog to the administration console. An admin can disable the entire integration or individual tools. Runtime enforcement uses the integration ID and tool name, so a hidden or disabled MCP tool is rejected even if an old conversation still references it. For connectors, define the allowed endpoints and decide which writes an agent may perform. Writes require review by default. An organization admin can grant Workers run this without approval for selected endpoints in the channel’s tool settings. Review internal notes, public replies, ticket closure, and infrastructure changes separately. Granting an exception does not bypass organization restrictions, agent step grants, or credential scope. See Channel connector approvals.

Agent connections

The shared plugin definition describes an external service; the agent still needs its own connection. Open the agent’s Setup → Connections to provision a service credential or supported OAuth account. These changes apply immediately, and saved secrets cannot be viewed. An agent does not borrow a member’s personal Key Chain entry or desktop login. For customer work, bind the intended customer and account when dispatching the task. Ticket text and model instructions do not authorize the agent to switch to another customer’s credential. Test a controlled case with the same channel, account, endpoint grants, and approval policy that production work will use.

Enable Org Brain and workers

These are separate owner-controlled features. Turning Workers on does not activate Org Brain; enabling Org Brain does not give every source organization-wide visibility. For Org Brain, use Organization to review eligibility, request activation, and refresh until the state is Active. The organization needs at least two members and eligible manual/Enterprise billing. An activation request is not confirmation that indexing and search are ready. Answer synthesis has its own consent disclosure after activation. Use Customize → Org Brain for ongoing knowledge administration:
  • Review proposed facts against their evidence. Eligible organization-wide facts at or above 85% model confidence can publish automatically, but channel facts and facts supported only by chat summaries require human review. Inspect and retract incorrect facts.
  • Inspect consolidation proposals before retiring redundant or contradictory shared memories. Keep both rejects the proposal.
  • Browse active and retracted facts, including automatically published facts.
  • Inspect dream run history and configure the dream schedule and processing modes.
  • Inspect the Registry for organization-visible indexed documents. It is not a search view over private or channel-only sources.
Disabling Org Brain stops indexing and retrieval but does not erase indexed data. See Org Brain for activation, consent, sources, and cleanup semantics. For agents, prepare a shared channel, enable Workers as the owner when eligible, then create an agent in that channel. Review its model, tools, credentials, triggers, budget, and human decisions before activation. The workflow can combine Agent, Procedure, and Human steps. Procedure steps need active organization-shared procedures and cloud-supported tools. After activation, use the agent’s Tasks view to supervise runs, Activity to inspect recorded events, and Outcomes to assess results and proposed improvements. The run panel’s Activity and Review views bring the work and its assessment together. Activate the agent for a controlled test and verify the ticket and service outcome before enabling unattended triggers. See AI support agents.

Audit and managed endpoints

Use More → Desktop audit for signed-in desktop action streams and Activity for worker events. Verify the recorded chain and export the relevant evidence when investigating an action. Neither view replaces target-system logs. Use Remote Desktop for managed endpoint administration where the preview is available. Enrollment, folder policy, View access, Control, and revocation are separate operations. The managed Remote Desktop guide explains current platform and rollout limits; the existing RDP protocol remains a separate feature.

The connect-your-accounts checklist

Members see account tasks in Settings → Profile when an allowed integration requires a personal credential. The checklist can deep-link to the correct OAuth or Key Chain flow. Completion means the required private entry is present; it does not expose the secret to the organization admin. Use the member credential-status markers to identify readiness gaps, then ask the member to complete their own account connection.

Offboard a member

Before removal:
  1. Transfer ownership of channels, procedures, dashboards, and work that must continue.
  2. Review personal-credential dependencies and provision a replacement owner or service credential.
  3. Reassign open conversations, agent ownership, and human tasks; review triggered work and notification recipients.
  4. Remove the organization membership.
  5. Confirm the member profile and organization access are cleared, revoke managed sessions and mobile pairings as applicable, and review retained private/shared source data.
  6. Rotate any external shared credentials the person could access outside Studio.
Removing a member is not a substitute for rotating a shared secret in the external system.

Policy rollout checklist

  • Test with a non-admin member, not only an owner account.
  • Test inside the actual target channel.
  • Verify both tool discovery and runtime dispatch.
  • Confirm personal-account tasks appear for members who need them.
  • Confirm agent connections work in a real run without relying on a member’s desktop or personal credential.
  • Check the channel’s exceptions for writes that run without approval, including customer replies and ticket closure.
  • Confirm shared credentials work without revealing them in chat or admin views.
  • Record the intended owner and review date for every shared integration.

Connectors and MCP

Define endpoints, transports, authentication, and safe descriptions.

Teams and organizations

Model trust boundaries, roles, visibility, teams, and channels.