The capability catalogue

An agent is a name, a level, a written instruction and a set of connected capabilities. The catalogue is where that last part comes from. It holds what the administrator has entered and allowed to roles, and it draws the boundary of what an author can connect without leaving the installation.

Three kinds of entry

MCP servers

An MCP server gives an agent tools. It is entered by an administrator and by nobody else: an author cannot register one at any permission level. Connecting an allowed server to an agent hands the agent its tools, and nothing about the server’s setup passes through the author.

Integrations

An integration is a connection to an external system. Most integrations run under the platform’s own service accounts, and their credentials are never shown to the author — connecting one takes no secret from the person doing it. Some run instead on a personal authorisation, granted by an employee through an OIDC provider; the agent then acts as that named person, in that person’s own rights.

Skills

A skill is a capability the agent knows how to apply. It carries an instruction, not credentials. Skills sit in the catalogue alongside the other two entries, and unlike them they have a second way in.

Who enters, who chooses

The two roles are kept apart. The administrator enters MCP servers and integrations and decides which roles may use each one. The author, creating or editing an agent, is offered only the entries allowed to their role. An entry that is not allowed does not appear in the list, and an attempt to connect one is refused with the reason named rather than dropped in silence.

Channels follow the same shape. The administrator registers the workspace and the app registration; the author binds an agent to a channel that already exists. A channel nobody registered is not among the choices.

The one path that leads outside

Skills can arrive from outside the catalogue. An author holding the RBAC permission for it asks in conversation with the agent, and any skill installable by a command of the form npx skills add <name> is installed. No administrator stands in that loop.

The asymmetry is deliberate. An MCP server reaches into the organisation’s systems, and the cost of a mistake there is other people’s data; a skill widens what an agent can do, and the cost of a mistake stays closer to home. Symmetry in either direction is worse than the split. Forbidding outside skills puts the whole product at the speed of one administrator. Opening MCP the same way hands access to external systems to someone who does not answer for them.

The price of the split is stated rather than discovered: external code enters the installation on an employee’s request, not on an administrator’s decision.

What sharing changes, and what it does not

Opening a personal agent to an organisation group leaves its capability set alone. A skill the author installed from outside keeps working, and from that point it works for everyone in the group.

Personal authorisations behave the other way round, because they are one person’s access rather than code. They never pass to another principal. Sharing an agent that holds at least one is either not carried out, or carried out with those authorisations revoked; an installation declares which of the two it does. When an agent later reaches for an integration whose authorisation is gone, it explains that in the conversation and says what to do about it, instead of returning a technical error. Scheduled automations that needed that integration stop, and the author is notified — rather than inferring it from an empty report a week later.

The behaviour does not depend on why the authorisation ended. Expiry, revocation by the external system and revocation triggered by sharing are handled the same way.