A Plugin, Not a Platform

A thin host, pluggable resolvers

Amplifier Resolve

A thin host that runs coding agents

Amplifier Resolve is a FastAPI host whose Orchestrator creates one isolated worker container per instance. It owns lifecycle, routing, and validation — and deliberately nothing more.

Owning very little is not an accident. The repo says so in its own words.

Lifecycle

One worker container per instance, named resolve-{id}, over 8 platform statuses.
Routing

Mirrors events, routes input-requests and messages between host and resolver.
Validation

Validates every POST /instances input before the instance is created.

Proof — in the repo's own words

“The host is a thin lifecycle/routing/validation layer. Resolvers own all resolution semantics.”

README.md, line 254 — Amplifier Resolve (microsoft/amplifier-resolve)

The split is stated verbatim, not aspired to. So why draw the line exactly there?

The tension

Any one coding approach is just one strategy

A resolver is a strategy plugin: it defines its own approach, phase progression, and documentation. Bind that intelligence into the platform and every new approach forces a rebuild.

The thin host has to defeat that coupling. It does it with one narrow seam.

Couple intelligence to the platform

A new approach means a new platform — untenable as strategies multiply.
Keep the host thin instead

The host owns only lifecycle, routing, and validation; resolvers own the semantics.

Mechanism — the seam

Intelligence lives behind one 12-member contract

The host talks to every resolver through a single Resolver Protocol — 4 properties and 8 methods. That narrow interface is what lets the host stay dumb while resolvers stay smart.

A contract is only as strong as the boundary that enforces it.

4 properties
name
version
description
supports_resume
8 methods
instantiation_schema
workspace_spec
container_setup
message_types
run
on_input_response
on_message
stop

Mechanism — the boundary

Bad input gets a 422, not a broken container

The host validates every POST /instances request against the resolver's A2UI v0.9 instantiation schema before creating the instance. Fail validation and you get a 422 with an errors list — nothing runs.

Enforcing the contract at the edge is how the host earns the right to be thin.

# POST /instances — validated at the boundary
200  input matches the resolver's A2UI v0.9 schema
     → instance created

422  Unprocessable Entity
     → errors list returned, no instance,
       no broken container

The turn

The platform is actively shedding coupling

This is enforced over time, not declared once. The in-process execution path (ResolveCore) was deleted; resolvers now run via JSON-RPC over stdio inside worker containers. And a single completion contract replaced the legacy handlers.

Discipline maintained means extensibility can cost almost nothing.

In-process path deleted

ResolveCore / ResolverResult removed — there is no host-side resolver execution path.
One completion contract

resolver:completed is the sole terminator; the legacy complete/error handler was removed in PR #59 (893fcba).
Magic string retired

The __RESOLVE_WORKER_COMPLETE__ check was removed in PR #51 (376b915).

The payoff — the plugin swap

A new approach is a new plugin, not a new platform

A resolver is a separate package. Register it with one CLI command and it's discovered through the ManifestRegistry catalog (resolvers.json). Adopting a new coding approach means dropping in a plugin — the platform never changes.

That is the whole point of keeping the host thin.

1Package the resolver separately — it defines its own approach, phases, and docs.
2Register it: amplifier-resolve resolver add
3The ManifestRegistry catalog (resolvers.json) is the single source of truth for discovery.

The pattern to keep

Keep the host thin; push intelligence behind a contract

Own only lifecycle, routing, and validation. Put every strategy behind one narrow interface. Then you can adopt new approaches forever — without touching the platform.

Sources

Research Methodology

Feature status: Active

Primary source: microsoft/amplifier-resolve, checked out at ~/dev/ANext/amplifier-resolve (shallow clone, 100 commits visible; earliest 2026-04-29, latest 2026-05-20).

Research performed:

Thin-host claim: grep -rn "thin|host handles|resolvers own" README.md (README.md:254, :7)
Resolver Protocol 12 members: sed -n '58,145p' docs/ARCHITECTURE.md (ARCHITECTURE.md:140)
Schema validation / 422: grep -n "422|A2UI|instantiation_schema|validate" README.md docs/ARCHITECTURE.md
Completion contract cleanup: git log --format="%h %s" | grep -iE "#59|#51" (893fcba #59, 376b915 #51)
Plugin registration & catalog: grep -rn "resolver add|separate packages|ManifestRegistry" docs/ARCHITECTURE.md src/amplifier_resolve/plugins/catalog.py (ARCHITECTURE.md:337)
In-process path removal: cat src/amplifier_resolve/core/resolve_core.py (tombstone); launcher via ResolverProcess (orchestrator.py:857)
Contributors: git shortlog -sn --all

Gaps: The checkout is a shallow clone, so true repo origin date and total commit/contributor counts are not verifiable — only the 100-commit window is visible. The runnable Resolver Protocol lives in the external amplifier-resolver-sdk; the 12-member count is quoted from ARCHITECTURE.md:140. Two stale doc details were corrected: the worker runs a 'sleep infinity' keepalive (not a resolve_worker module) with the resolver launched via ResolverProcess.

Primary contributor (visible history): Brian Krabach, 97 of 100 commits.