The Kernel That Does Less

How amplifier-core stays small on purpose

amplifier-core

A kernel everything plugs into — that wins by doing LESS

amplifier-core is the ultra-thin coordination layer for modular AI agents. It's where every provider, tool, and orchestrator plugs in — and its whole design bet is to hold no opinions.

Small enough to prove in three numbers.

The whole kernel is 18 files and a ~2,600-line documented center

You run it through one lifecycle: initialize()execute()cleanup() — a three-method public API on AmplifierSession.

Tiny on purpose — but staying tiny fights an instinct.

18
top-level source files in amplifier_core
~2,600
documented lines in the stable center
5
runtime dependencies
3
public session methods
The instinct to resist

Kernels grow by accretion — and every baked-in opinion is harder to trust

The usual pull is to add: bake one more behavior into the core, then another. amplifier-core's design philosophy inverts it — "Favor deletion over accretion in kernel," and "Small, Stable, Boring Kernel — Kernel changes rarely."

So how does a kernel stay useful while refusing to grow?

The Coordinator ships primitives modules attach to — it never decides behavior

Instead of opinions, the kernel's ModuleCoordinator exposes stable mechanisms. Modules mount, register capabilities, and contribute — the kernel just wires them.

Those primitives are only useful if their shape never shifts.

Modules snap onto stable contracts — a small surface that never bends

Providers, tools, and hooks build against 6 typing.Protocol contracts and a canonical event surface of 47 stable event names — documented as the "stable surface for hooks and observability."

Small, fixed, and shared — which raises one question about what belongs here.

6
Protocol contracts: Orchestrator, Provider, Tool, ContextManager, HookHandler, ApprovalProvider
47
canonical event-name constants for hooks & observability
The one rule

One litmus test decides everything that belongs in the kernel

“Could two teams want different behavior? → If yes, it's policy → Module, not kernel.”

That single test is what keeps opinions out — and the center still.

Why less wins

Holding no opinions keeps the center small, stable, and boring

By favoring deletion over accretion, the kernel changes rarely. That's not a limitation — it's the point. A center that doesn't move is the still point every swappable module can safely build on.

And a boring kernel isn't theory — it's shipped.

A boring kernel is a released one — version 1.0.0, upstreamed to microsoft/amplifier-core

Extracted from a monorepo in October 2025, amplifier-core is now versioned 1.0.0 with stability guarantees — a discipline others can adopt, not a prototype.

Do less in the core, and the whole system gets easier to trust.

1.0.0
released version (__init__.py)
134
total commits
5
contributors across the kernel
Sources

Research Methodology

Subject: amplifier-core (origin git@github.com:ramparte/amplifier-core.git; upstream git@github.com:microsoft/amplifier-core.git)

Feature status: Released / stable — version 1.0.0

Data as of latest commit: 2026-02-17 (HEAD 5249084)

Research performed:

Gaps / notes: "~2,600 lines" is a documented characterization (README.md line 7, bundle.md line 18); measured = 2,304 code lines in core mechanism files, 4,752 raw lines across all 18 top-level files. "18 files" counts flat top-level amplifier_core/*.py only; including subpackages the total is 40.

Contributors: Brian Krabach (130 commits), plus Diego Colombo, Marc Goodner, Sam Schillace, and Samuel Lee (1 each).

More Amplifier Stories