Capabilities and marketplace

A capability is an installable add-on for your sphere — the same idea as an app you install on your phone, except this one lives inside your AI-run company and does real work: a skill an agent can use, a tool, a whole rule-pack your sphere agrees to follow. Every capability is optional, and every one carries its own version number, so a sphere always has a clear, traceable list of exactly what it can do and at which version — instead of an unaccounted pile of add-ons spread across five different places. The rule is pull, not push: the catalog offers, and you choose whether and when to take it.

The manifest

Every capability carries a manifest — a declaration file, capability.yaml, that spells out what the add-on is and whether it's actually safe to install:

A capability whose manifest doesn't check out simply isn't compatible, no matter what it claims about itself.

Seven kinds of add-on

Installing one, step by step

Installing a capability always happens in the same order, and no step gets skipped:

1. Choose it from the catalog.

2. Check the manifest — every required field, a valid type, everything checked at once rather than failing on the first issue found.

3. Check it's compatible with the sphere's own pinned version of the standard. An incompatible version blocks the install outright.

4. Scan for danger. Every piece of executable code gets scanned before any of it is copied in. The scan blocks the dangerous stuff:

   • commands that delete without asking
   • code that pipes straight from the internet into your shell and runs it
   • anything built to spin out of control and multiply on its own

   Code that hasn't been scanned is treated as an unacceptable risk, full stop.

5. Copy it in and record it. The sphere's own list of what it actually carries gets updated as part of the same step, so two installs happening at once can't lose track of each other.

6. Confirm it landed clean. The health check runs, confirming the install actually worked.

Uninstalling a capability never means deletion. It's an archive with a marker: the add-on moves to an archived location, a pointer is left where it used to live, and its row in the registry moves from active to archived rather than disappearing.

Two lists, one rule

The same discipline that governs the standard as a whole applies here: the catalog offers, the sphere decides when to pull. Upgrading a capability happens on the sphere's own schedule, not the catalog's.

What's coming: finer control, without reinstalling

A more precise way of describing what a capability promises to do is designed and on the roadmap. Once it ships, it will let you:

• pin down exactly what a capability does and doesn't cover, in more detail than today
• switch a capability off in one sphere without uninstalling it everywhere
• have capabilities that depend on each other enforce that automatically, instead of trusting whoever installs them to get the order right

A further piece is designed but not yet switched on: capabilities published from their own separate project, pinned to one exact version, instead of living inside the standard's own catalog. It's waiting on real outside capability authors before it's worth activating.

The catalog today

Beyond the six canonical skills that ship with every sphere, thirteen optional capabilities are available to pull in:

What's ahead

The capability layer is where the next phase of the standard's economics plays out. See Business model and roadmap for how the currently-open catalog relates to a paid, third-party marketplace on the roadmap.