Skip to main content

Documentation Index

Fetch the complete documentation index at: https://agentvolumes.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

The Agent Volumes v0.1 core is intentionally narrow. Its design principles explain why the specification standardizes package identity, manifest shape, conformance artifacts, and registry contracts while leaving runtime execution policy and local operational choices to implementations. This page summarizes spec §12. The prose specification remains the normative source of truth.

​
Runtime neutrality

Agent Volumes does not assume or privilege one agent framework. A volume can target one runtime, several runtimes, or no runtime-specific profile at all. Runtime and protocol declarations are compatibility metadata, not resolver constraints. Clients preserve those expressions and evaluate them only when they understand the relevant version scheme.

​
Component-centric discovery

The ecosystem should let users find capabilities, not only package names. Volumes package components such as skills, tools, commands, hooks, agents, MCP servers, and LSP servers, and each exported component has its own addressable identity. This is why component names are unique within a volume and why component purls use the subpath form, for example: 
pkg:volume/research-agent-pack@1.4.0#tool/arxiv-search

​
Strong identity model

Every volume and component has a globally unique, purl-compatible identifier. Portable payloads use canonical pkg:volume/... serialization, including percent-encoded scopes in purl strings. Release identity has two parts:
  • the logical package identity, such as pkg:volume/%40acme/research-agent-pack@1.4.0
  • the immutable content identity, expressed as a normalized-file-tree sha256:<hex> digest
Trust metadata, release metadata, and conformance vectors all rely on these identities staying consistent.

​
Supply chain integrity

Content integrity, trust attachments, advisories, and verification are first-class parts of the v0.1 core. The baseline requires normalized-file-tree digest verification, release-scoped trust attachment discovery, advisory read/discovery payloads, and deterministic conformance fixtures. It does not define one universal trust-root policy, scanner-result interchange format, or advisory write authority.

​
Cross-runtime interoperability

Agent Volumes is designed for packages that can move across agent runtimes without losing their package-level identity, dependency metadata, or trust evidence. The core standardizes portable boundaries:
  • manifest metadata and component declarations
  • runtime and protocol compatibility declarations
  • package and component purl identity
  • normalized content integrity
  • schema-backed registry and conformance artifacts
Runtime adapters still decide how validated components are launched, sandboxed, approved, and presented to users.

​
Pragmatic simplicity

The v0.1 core favors simple portable contracts over broad general-purpose models. Examples include:
  • TOML authoring with a canonical parsed-data model
  • single-version dependency resolution
  • a constrained SemVer range grammar for Agent Volumes dependencies
  • declaration-only external dependency metadata
  • the mandatory http-put upload profile for portable write flows
  • narrowly scoped JSON Schema, OpenAPI, and fixture artifacts
This keeps the first release implementable while leaving room for future profiles.

​
Incremental adoption

You do not need a complex package to adopt Agent Volumes. A minimal volume.toml plus one component, such as a single SKILL.md, remains a valid baseline volume. Implementers can start with manifest validation, package identity, and content integrity before adding registry writes, trust uploads, or richer runtime adapters.

Manifest reference

See the canonical human-authoring format and parsed-data model boundary.

Conformance fixtures

Use deterministic fixtures to test the portable v0.1 behavior.