Architecture & Philosophy · Amplifier Platform

Amplifier Resolve

How Amplifier builds software.
Turn intent into working code through pluggable resolver backends.

Active · A2UI v0.9 Protocol
May 2026 · microsoft/amplifier-resolve
The Vision

Code that
writes code

📝

Describe Intent

A user writes a spec — what the software should do, defined as observable HTTP behavior. No implementation details.

⚙️

Resolve Autonomously

A resolver instance explores the codebase, plans changes, implements them, tests in a live environment, and iterates until done.

🚀

Deliver a Pull Request

The platform promotes results back to GitHub or Gitea as a PR. Working code, tested and ready for review.

The host handles lifecycle, routing, and validation. Resolvers own the semantics. The platform is a thin orchestration layer — not a monolithic AI.

Architecture

Four layers, clear boundaries

A modular monolith: single Python process on a single host, with per-instance services running under Incus containers.

1

App Shell

React SPA — A2UI rendering surface with optional viewport extensions for custom resolver visualization

2

Headless Core

FastAPI service — instance lifecycle, broker, resolver registry, auth, observability. ~24,000 lines of source.

3

Resolvers

One child process per phase, speaking JSONL over stdio via amplifier-resolver-sdk. Pluggable — discovered via entry points.

4

Per-Instance Services

Sidecar containers: Gitea, GH-router, DTU spawn, Reality-Check spawn. New capabilities via CapabilityHandlerProtocol.

Protocol

A2UI v0.9

The instance-centric protocol that makes resolver plugins interchangeable.

Schema-Driven Input

Resolvers declare their input schemas via instantiation_schema. The host validates every POST /instances request before creation. Dynamic refinement supported via GET /resolvers/{name}/schema?params={...}.

Runtime Input Requests

Resolvers can request additional user input mid-run by writing structured request files with A2UI form schemas. The host exposes, validates, and routes responses back — a general, schema-driven mechanism.

12-Member Protocol

Properties: name, version, description, supports_resume. Methods: instantiation_schema, workspace_spec, container_setup, message_types, run, on_input_response, on_message, stop.

Typed Messages

Send typed messages to a running instance. Message types are validated against the resolver's message_types() for the current state. Unknown types return 422.

SSE Events

Per-instance event streams via GET /instances/{id}/events. Events logged to events.jsonl, state snapshots to state.json. Real-time observability.

Lifecycle

Eight states, one happy path

Every instance follows a state machine from creation to completion — with pausing, input requests, and cancellation built in.

1

created → starting

Instance record persisted. Container launches, worker initializes. Cache image cuts this from ~5 minutes to ~15 seconds.

2

running

Resolver actively working inside a container. May transition to awaiting_input or paused and back.

3

completed | failed | cancelled

Terminal states. Success delivers a PR. Failure logs diagnostics. Cancellation is available from any non-terminal state.

The typical happy path: created → starting → running → completed. Each transition emits events to both the SSE stream and the Amplifier hook system.

Resolver Ecosystem

Pluggable
backends

Each resolver is a strategy plugin. The host provides infrastructure — resolvers own the intelligence.

🧲

Attractor

Multi-stage AI pipeline — plan, implement, test, review. Ships as a submodule at amplifier-bundle-attractor.

💻

Dev Machine

Interactive resolver that pairs with a human developer in the loop for guided implementation.

📊

Dot Graph

Specialized resolver for architecture diagram generation and codebase visualization.

Register & Scaffold

amplifier-resolve resolver add <spec> validates installation in an ephemeral worker container. amplifier-resolve init-resolver my-resolver scaffolds a new one.

Shared Infrastructure

Every resolver gets: workspace provisioning, Gitea sidecars, DTU environments, reality-check sessions, promotion to upstream repos, and container lifecycle management — for free.

Platform Services

What the host provides

Workspace & Promotion

GitSidecarManager provisions repos, clones, and sets up branches. PromotionService pushes results to upstream repos as PRs. Pure HTTP — no git binary needed.

Broker & DTU

The broker provisions per-instance sidecar services: ephemeral Gitea instances, Digital Twin Universe environments, and Reality-Check sessions — all running under Incus.

Reality Check

Validates resolver output against live services. Observable HTTP behavior — not source inspection. The platform tests what the code does, not how it's written.

Container Providers

Abstracted via ContainerProvider: Incus (primary) and Docker (fallback). Worker cache images cut startup from ~5 min to ~15 sec. Rebuild weekly.

Two-Domain Auth

User domain (/api/*): session cookies or bearer tokens via PAM/env/file cascade. Worker domain (/worker/*): instance-scoped tokens with container identity verification.

API Surface

REST-first, JSON everywhere

The full instance lifecycle as HTTP endpoints — designed for programmatic consumption by agents, scripts, and UIs.

# Discover available resolvers curl http://localhost:10120/resolvers # Create an instance curl -X POST http://localhost:10120/instances \ -H "Content-Type: application/json" \ -d '{"resolver": "attractor", "input": {"spec": "Add GET /api/version", "repo": "org/repo"}}' # Watch events in real-time curl -N http://localhost:10120/instances/{id}/events # Check instance status curl http://localhost:10120/instances/{id}

20+ Endpoints

Instance CRUD, input-requests, messages, events, state, workspace ops, broker services, sub-container management.

Structured Errors

All 4xx/5xx responses use {code, detail, next_action} envelope. Idempotency-Key header with 24h dedup window.

Self-Managing

amplifier-resolve doctor diagnoses issues. amplifier-resolve upgrade self-updates. install-service for systemd/launchd.

Development Velocity

22 days of focused engineering

100
Commits
24K
Lines of source
67K
Lines of tests
3,400
Test cases

First commit April 29, latest May 20 — 100 commits in 22 days. 77 source files, 184 test files. A ~2.8:1 test-to-source ratio by line count. Built to be tested, not just to run.

The Bigger Picture

The factory
for factories

Amplifier Resolve is the orchestration layer that turns every other Amplifier component into a code-generation pipeline.

Composable by Design

amplifier-bundle-gitea provides ephemeral git. amplifier-foundation provides the core runtime. amplifier-bundle-attractor provides the AI pipeline. Resolve composes them into a working factory.

Resolver as Strategy

New coding approaches are new resolvers — not new platforms. Register with one command, validate in an ephemeral container, deploy immediately. The platform stays thin.

The host is a thin lifecycle/routing/validation layer. Resolvers own all resolution semantics. New capabilities are added as new broker handlers conforming to CapabilityHandlerProtocol.

— design/ARCHITECTURE.md
Get Started

Run it today

One command to install. One command to start the server. One API call to generate code.

# Install uv tool install 'git+https://github.com/microsoft/amplifier-resolve@main' # Start the server amplifier-resolve --port 10120 # Build the worker cache (cuts startup 5 min → 15 sec) ./docker/build-cache-image.sh
github.com/microsoft/amplifier-resolve
Python 3.11+ · FastAPI · Incus/Docker · A2UI v0.9
Sources & Methodology

How this deck was built

Repository: microsoft/amplifier-resolve — cloned and analyzed May 20, 2026.

Sources consulted:

Commands used: git log --oneline | wc -l, git shortlog -sn --all, find . -name "*.py" | xargs wc -l, wc -l on key modules.

No metrics were fabricated. All numbers come from git history and file system analysis at the commit referenced above.

More Amplifier Stories