Extensions

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

Use extensions when a capability 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, provider-specific bridge code, or a daemon-facing Host API service, an extension gives that package a manifest, trust tier, enablement state, and operational lifecycle.

The install page is for operators who need to add, enable, disable, inspect, update, or remove an extension. The develop page is for authors who need the manifest shape, resource layout, subprocess lifecycle, and permission model before packaging an extension for a registry.

Extensions can also publish a MemoryProvider for Memory v2. AGH 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 AGH controller. AGH memory is separate from any provider-native memory or context: provider-side state is owned by the provider, and the AGH controller still records memory_events, memory_decisions, and updates the catalog projection. Provider-supplied tools that collide with reserved names (agh__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