What Amplifier Is

Amplifier is a modular platform for AI-assisted development. The CLI you run is a reference application built on top of a small kernel (amplifier-core) plus swappable runtime modules (providers, tools, hooks, and orchestrators).

The mental picture

flowchart TB app["Your app (CLI, web app, IDE plugin, service)"] --> cfg["Load config + select bundle"] cfg --> mount["Mount plan: orchestrator + provider + tools + hooks"] mount --> loop["Orchestrator loop runs turns"] core["amplifier-core (kernel contracts)"] --> mount foundation["amplifier-foundation (bundle system)"] --> cfg modules["Runtime modules (plugins)"] --> mount subgraph Modules providers["Providers"] tools["Tools"] hooks["Hooks"] orchestrators["Orchestrators (loops)"] contexts["Context managers"] end modules --> providers modules --> tools modules --> hooks modules --> orchestrators modules --> contexts

Why it feels like "Claude Code"

The CLI can feel similar because it includes the same genre of parts: a streaming terminal UI, a tool-calling loop, local filesystem and shell tools, session persistence, etc. The key difference is that Amplifier is designed so those behaviors are assembled from modules and bundles rather than being one fixed monolith.

Useful rule of thumb
If something "mysteriously appears" (an agent, a tool, a different streaming behavior), it's almost always because your active bundle mounted a different set of modules.

Configuration: Bundles are the new standard

Amplifier uses bundles as the primary way to configure and compose capabilities. A bundle is a markdown file with YAML frontmatter that specifies:

This replaces the older profile/collection system, providing better composability and reproducibility. See the Bundles page for details.

Entry point vs. ecosystem

Why that matters
If you want a different UX (web UI, background service, multi-task runner), you build a different application that hosts the same core contracts and mounts the same kinds of modules.