Skip to main content
A component is a functional unit that an agent runtime loads and executes from a volume. Agent Volumes defines seven component types, each with distinct semantics, entrypoint formats, and execution models. When you publish a volume, you declare which components it exports in volume.toml, and any compatible runtime can discover and load them.

​
Component type summary

​
Component types

Agent

An autonomous runtime actor that receives a goal and independently decides how to accomplish it using tools, skills, and other agents.

Skill

Reusable instructional knowledge loaded into agent context. The runtime interprets and applies it — skills are not executed as code.

Command

A user-invokable action triggered by a slash command pattern such as /review or /summarize.

Tool

A function or API endpoint that an agent calls programmatically during task execution. Has typed inputs and outputs.

Hook

A lifecycle event handler that fires automatically at defined points in the agent runtime — session start, tool use, compaction, and more.

MCP Server

A Model Context Protocol service packaged as a distributable volume component. Runs as a long-running process.

LSP Server

A Language Server Protocol service that provides code intelligence and editor integration when loaded by a compatible runtime.

​
Export model

A volume exports components by declaring them in volume.toml and placing their entrypoint files at the declared paths. Three rules govern every exported component:
  1. Every exported component must be listed in volume.toml under [[components]].
  2. Every declared component must have a valid entrypoint file at the specified path.
  3. Component names must be unique within a volume across all component types.
Each [[components]] entry requires three fields: Two optional fields are supported for all component types:
The spec recommends organizing your volume with a dedicated directory per component type. This layout is a convention, not a requirement — the entrypoint path in volume.toml is authoritative.

​
Entrypoint resolution

When a runtime or validator loads a component, it follows a three-level precedence chain: The minimum a portable validator checks before passing a component to a runtime adapter is type-specific. For Markdown-based types, the entrypoint must exist and have a supported extension. For JSON-based types (mcp-server, lsp-server), the file must exist, be valid JSON, and parse to an object. For command, the frontmatter must include a valid trigger. For hook, the descriptor must declare a canonical lifecycle event and a valid hook type.
Entrypoint paths must be relative to the volume root. Absolute paths, paths containing .. segments, and paths that resolve outside the volume root are all validation failures.