Skip to content

Capabilities

A capability is a self-contained unit that extends an agent. Each capability can contribute three kinds of thing:

  1. Tools — functions the agent can invoke during a turn.
  2. System prompt additions — text prepended to the agent’s prompt that teaches the model when and how to use those tools.
  3. Mount points — files, directories, or session state the tools need to operate.

Agents compose capabilities. Enable as many as you need; leave the rest disabled. The runtime resolves capabilities in topological order (dependencies first) and concatenates their system prompt fragments in the order you configured them on the agent.

A bare tool registration is a function with a JSON schema. Capabilities exist because real tools need more than that. To use virtual_bash effectively, the agent needs both the bash tool and the prompt fragment explaining the sandbox model and the session filesystem (a dependency). Capabilities bundle those concerns into one enable/disable unit.

See Why capabilities are first-class for the full rationale.

SourceID formatExample
Built-insnake_caseweb_fetch, session_file_system
MCP servermcp:{uuid}mcp:550e8400-...
Registry skillskill:{uuid}skill:550e8400-...
Declarativedeclarative:{name}declarative:research_pack

All four kinds participate in the same merge, dependency resolution, and tool-name prefixing. The agent doesn’t care where a tool came from.

Capabilities can be attached at three layers, and the layers stack additively:

  • Harness — defaults for every session that uses this harness.
  • Agent — capabilities for this specific role.
  • Session — extras for this one conversation.

See Why three configuration layers for how the merge works.

The full list of built-in capabilities, organised by category, lives in the reference:

  • Concepts — the entity model in full.