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.

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.