Modules

A module is a dynamically loaded plugin that implements a stable amplifier-core contract. The CLI (or any other app) loads modules based on your active profile and module sources.

Module types

• Providers: connect to model backends (OpenAI/Anthropic/Azure/Ollama/etc.)
• Tools: callable capabilities (filesystem, bash, web, search, tasking, etc.)
• Orchestrators (“loops”): run the agent execution loop and manage tool calling
• Hooks: cross-cutting lifecycle behaviors (logging, redaction, approvals, UI)
• Context managers: how chat/session context is stored

How modules are sourced

Modules can be loaded from different places (git URLs, local paths, installed packages), with a resolution order that favors explicit overrides. This is what enables “develop one module locally while everything else stays pinned to git”.

Existing modules (scanned)

This list is rendered from data/catalog.json (generated by scanning the ecosystem repos).

How to think about modules

• A profile is a declaration of which modules to mount; it isn’t a module itself.
• The kernel stays stable; modules can evolve rapidly as long as they keep honoring the contracts.
• “Modular” isn’t just packaging: it’s a discipline to keep policies and product choices out of the kernel.