Capabilities and skills

A capability is one concrete thing an agent can do, wired to a real system. It is the difference between an agent that can discuss purchase orders and one that can create them.

What's in a capability

Three parts, delivered together:

• A skill — the executable. Skills run as real subprocesses, so they can read files, call APIs, run code, and drive a browser. They aren't prompts; they're programs the agent invokes.
• Credentials — whatever the skill needs to authenticate against the system it touches. Bound at provisioning, injected into the skill's environment.
• A prompt fragment — when and how to use this capability, written by the operator, merged into what the agent knows about itself.

That third part matters more than it looks. An agent with a capability it doesn't understand when to reach for is an agent that improvises instead.

The skills library

Skills live in the platform's skills library — written, edited and versioned right in the console, with nothing to commit or deploy. Every organization sees the public skills plus its own private ones; platform staff decide which is which and can hand a skill to a different owner.

A skill is a small folder in the open Agent Skills format: a SKILL.md whose name and description (what it does and when to use it) are always in the agent's skill list, and whose body holds the instructions, plus any scripts/, references/ and assets/ it needs.

• Writing. New skill on the Skills page opens the editor: the skill's files, a code editor that saves as you type, and live checks of SKILL.md. Import brings in a folder of skills from your computer. A public skill can be copied into your organization to change it there.
• Publishing. Edits go to the skill's draft, which no agent sees. Publish freezes it into the next version (v1, v2, …) after showing exactly what changes. Owners and admins publish; other members submit for approval.
• Agents write skills too — and a person approves them. An agent can create a skill or improve one through MCP, but publishing from an agent is a proposal: it waits on the Skills page with a side-by-side review of every change until an owner or admin approves it, and the agent hears the decision on its next run.
• History. Every version records who wrote it, who approved it and why it changed. You can see what any version changed and restore an old one into the draft to publish it again.
• Installing. Owners and admins install a skill on one or more agents from the organization's Skills page, a skill's page, or an agent's Skills tab. It reaches the running agent on its next turn — no restart, no redeploy.
• Agents ask; people decide. An agent that needs a skill asks for it with a reason. The request waits on the Skills page (and in the notification bell) for an owner or admin to Approve & install or Decline, and the agent hears back on its next run. Agents never install skills themselves.
• Always current. Installed skills follow the latest version. A new version rolls out to every agent that has the skill on its next turn; pulling a bad version rolls them back to the previous one.
• Credentials gate visibility. A skill that needs credentials installs right away but stays hidden from the agent — marked Needs setup — until the required credentials are bound to that agent.

A capability's skill is installed automatically on the agent the capability routes to, and can only be removed by changing the capability.

Modes

Capabilities carry a mode, and agents are instructed to honor it:

Any capability can additionally be marked as requiring human approval. The agent must then get sign-off through the escalation flow before it runs — its work is parked while it waits, so asking costs nothing. See Escalations.

How credentials are handled

This is the part worth reading twice.

Credentials are delivered to the execution environment of the skill, not to the model. The model decides whether to run a skill; it never sees the secret the skill uses. No platform tool returns a credential value — the tools that describe an agent's own configuration return the credential's id and alias so the agent can log what it has, and nothing more.

The practical consequence: a prompt injection that convinces the model to dump everything it knows cannot leak a credential, because the credential was never in its context.

Delegated credentials

When one agent hands work to another, it can share a specific credential for that turn only — for example, an API key so the receiving agent can query a system on the caller's behalf.

The receiving agent never sees the value. It's told: if a skill needs a credential the caller was expected to share, just run the skill — the value is injected automatically, exactly as if it were configured locally. Agents are explicitly instructed never to ask for, print, echo, or store a delegated value, and the mechanism that performs the injection is not exposed as a tool the model can call.

If the credential wasn't shared, the agent is expected to say so plainly and name what it would need, rather than improvising around a missing secret.

Attaching third-party MCP servers

Beyond capabilities, you can wire an external MCP server to an agent and its tools appear natively. Two per-tool controls apply:

• Descope — drop a tool from this agent entirely, so its schema is never sent to the model. This is a real cost control, not just hygiene: a large third-party catalog can dominate an agent's context on *every single model call* when the agent only ever uses a handful of its tools. Descoping the rest is a direct per-call saving with no behavior change.
• Require escalation — flag a tool so the agent must get human approval before calling it, routed through the same escalation inbox as everything else.

Scoping is per agent, not per server, because two agents in the same organization usually need different subsets of the same system.

Designing capabilities well

• One capability, one job. "Create a draft purchase order" beats "manage purchasing".
• Write the when-and-how. The prompt fragment is where you encode the judgment an operator has and the model doesn't.
• Set the mode honestly. Marking a transactional capability as write-capable removes a guardrail you'll want later.
• Gate the irreversible. Approval on the handful of actions that spend money or leave the building is cheap; recovering from one that didn't have it isn't.
• Descope aggressively. Tools an agent never calls are pure cost.