Extensions

An extension is one installable unit that ships runtime behavior and resources behind a single manifest. The operator installs, enables, and removes the bundle as a whole; Compozy wires the contained resources into the runtime registry only while the extension is enabled.

Use extensions when runtime behavior or resources should travel between machines or teams with one install command. If the work is only a local instruction set, a skill may be enough. If it includes multiple resources, provide surfaces, or a daemon-facing Host API service, an extension gives that package a manifest, trust tier, enablement state, and operational lifecycle.

Authors start at Build your first extension: three commands from an empty directory to a tool you can invoke. Authoring is code-first — you write code and compozy extension build generates the manifest.

Operators start at the install page for adding, enabling, disabling, inspecting, updating, or removing an extension.

Extensions can also publish a MemoryProvider for Memory v2. Compozy ships the bundled local provider as the reference implementation; only one external MemoryProvider may be active per workspace. The provider implements the 10-method ABC (Initialize, SystemPromptBlock, Recall, Prefetch, SyncTurn, OnPreCompress, OnSessionEnd, OnSessionSwitch, OnMemoryWrite, Shutdown), respects _system/ injection rules, and routes every write through the Compozy controller. Compozy memory is separate from any provider-native memory or context: provider-side state is owned by the provider, and the Compozy controller still records memory_events, memory_decisions, and updates the catalog projection. Provider-supplied tools that collide with reserved names (compozy__memory_*) are rejected at registration with memory.provider.collision. The circuit breaker ([memory.provider] keys: timeout, failure_threshold, cooldown) falls back to the bundled local provider when the active provider is unhealthy.

In this section