Amplifier · Mode System

Mode Transition
Control

Structural enforcement of pipeline sequencing across
multi-stage agentic workflows

● Active — Merged March 2026
amplifier-bundle-modes PR #6  ·  amplifier-bundle-superpowers PR #22
The Problem

Agents ignored
pipeline boundaries

🚪

Silent Exits

Any agent could call mode(clear) at any time — zero gate policy, no friction, no log entry. Dropping all tool restrictions was a one-liner.

⏭️

Arbitrary Jumps

Nothing prevented an agent in brainstorm from jumping directly to finish. Stage order was advisory at best — effectively ignored in practice.

🔓

Unrestricted Execution

Execution agents had bash access with no prohibition against git push or merge operations — even in stages where code should only be written, not shipped.

Net result: The mode system enforced tool-level restrictions (blocking write_file, gating bash) but had zero enforcement on mode transitions or mode exits. The pipeline existed in documentation only.
The Gaps

Six specific failure modes

Where Gap Found
mode(clear) Zero gate policy — instant, silent, no friction
mode(set) No transition sequencing — any mode reachable from any mode
All 5 non-finish modes No "DO NOT push/merge/PR" instruction in any mode
3 execution agents Bash access with no prohibition against push/merge
execute-plan.md Internal contradiction: said /mode off but should have said /verify
brainstorm.md mode(clear) listed as a valid escape hatch
🔍

Root Cause

The modes infrastructure was built to control what agents can do inside a mode, but not how they move between modes.

Mode exits were never treated as a transition requiring a gate. They bypassed all policy checks entirely — the same hooks that block unsafe tool calls simply weren't wired to mode(clear).

The Solution

Two layers of
enforcement

⚙️

Layer 1 — Infrastructure

amplifier-bundle-modes PR #6

  • allowed_transitions field — restricts reachable modes
  • allow_clear field — locks or permits mode exit
  • Gate policy on mode(clear) — same warn/confirm/auto flow as mode(set)
  • Structured denial messages list what the agent can do
  • Fully backward-compatible — absent fields = permissive
🗺️

Layer 2 — Pipeline Policy

amplifier-bundle-superpowers PR #22

  • All 6 Superpowers modes wired with explicit transition maps
  • "DO NOT push/merge/PR" added to all 5 non-finish modes
  • Scope Boundary section in 3 execution agents
  • Foundation context + philosophy added to all 5 agents
  • Fixed the /mode off contradiction in execute-plan
Design principle: Mechanism, not policy. The infrastructure provides enforcement hooks — the policy (which transitions are valid) lives entirely in the mode .md files. Any bundle can define its own pipeline rules.
Infrastructure · Layer 1

Two new optional fields
in mode frontmatter

# my-mode.md frontmatter mode: name: my-mode # Only these modes are reachable allowed_transitions: [next-step, fallback] # Agent cannot exit modes entirely allow_clear: false
Absent = permissive. Existing modes with neither field set are completely unaffected. Zero migration required.

allowed_transitions

When set, _handle_set checks the target mode against the list before applying gate policy. Denied transitions return a structured error showing the valid options.

When absent, any mode transition is permitted (legacy behavior).

allow_clear

When false, _handle_clear returns a denial. The agent stays in-mode. Only the designated exit mode can actually clear.

Gate policy on mode(clear) now mirrors mode(set) — same warn/confirm/auto flow that was already proven for set operations.

Pipeline Policy · Layer 2

Superpowers: all 6 modes
explicitly wired

Mode Can transition to allow_clear
brainstorm write-plan  debug false
write-plan execute-plan  brainstorm  debug false
execute-plan verify  debug  brainstorm  write-plan false
debug verify  brainstorm  execute-plan false
verify finish  debug  execute-plan  brainstorm  write-plan false
finish execute-plan  brainstorm true ← only exit
🧭

Lateral Escape Hatches

debug is reachable from every stage — it's the universal lateral escape when something breaks. But agents cannot jump from debug straight to finish.

🔒

Single Exit Point

Only finish has allow_clear: true. Every other mode denies mode(clear). Agents must traverse the pipeline to exit it.

Pipeline Architecture

The enforced flow

Main pipeline
brainstorm
write-plan
execute-plan
verify
finish
→ clear()
Lateral escape (available from every stage)
debug
verify
or
execute-plan
or
brainstorm
From finish ("what's next?")
finish
execute-plan
staged plan or
brainstorm
new feature or
truly done
Standard mode (allow_clear: false)
Finish — only exit point (allow_clear: true)
Debug — lateral escape from any stage
All blocked from arbitrary forward jumps
Impact

Before vs. After

Scenario Before After
Agent calls mode(clear) from brainstorm Instantly exits all mode restrictions Denied — brainstorm has allow_clear: false. Structured error lists valid options.
Agent jumps brainstorm → finish Allowed — no transition enforcement Denied — finish not in brainstorm's allowed_transitions list
Execute-plan agent runs git push No instruction preventing it Mode doc now says DO NOT push/merge/PR; scope boundary in agent context
Agent hits bug, needs to rethink Could silently exit to brainstorm or clear Must route through debug → brainstorm (explicit lateral path)
Mode author creates a new pipeline Pipeline was purely documentary — no enforcement Two-field declaration gives structural guarantee the pipeline will be followed
Existing mode without new fields Zero change — backward-compatible defaults. No migration required.
For Mode Authors

What you can build
with this

🏗️

Staged Workflows

Define multi-stage pipelines where agents must follow your intended sequence. Agents stay in the pipeline until they reach the designated exit point.

🔀

Lateral Escapes

Create escape-hatch modes (like debug) that are reachable from anywhere, while preventing arbitrary forward jumps that skip critical stages.

🧩

Mix Freely

Restricted and unrestricted modes coexist freely in the same bundle. Only modes with the fields set are constrained — others remain fully open.

🗣️

Helpful Denials

Structured denial messages tell the agent what it can do, not just what it can't. The agent is never left stuck — it always has a valid path forward.

📋

Pure Declaration

No infrastructure code to write. Two optional YAML fields in your mode frontmatter, and the enforcement infrastructure handles the rest automatically.

Design Principle

Mechanism,
not policy.

The modes infrastructure provides the enforcement mechanism. The policy lives entirely in the mode .md files.

Infrastructure owns

  • allowed_transitions check
  • allow_clear enforcement
  • Gate policy on clear
  • Denial message format

Bundle owns

  • Which transitions are valid
  • Which mode is the exit
  • Whether debug exists
  • Pipeline semantics

Neither side leaks into

  • Hardcoded mode names in infra
  • Custom enforcement code in bundles
  • Policy assumptions at the core
Development Velocity

By the numbers

9
Total commits
5 modes + 4 superpowers
2
Repos touched
bundle-modes · bundle-superpowers
2
PRs merged
#6 and #22
160
Tests passing
across both repos
12
New infra tests
enforcement in modes
14
New pipeline tests
adherence in superpowers
Test breakdown: 29 hooks-mode · 37 tool-mode · 94 superpowers
Sources

Research Methodology

Data Provenance

Data as of: March 4, 2026

Feature status: Active — both PRs merged

Data source: All metrics provided directly by the developer in the feature brief. No independent git research was performed for this deck.

Repositories:

  • amplifier-bundle-modes (PR #6)
  • amplifier-bundle-superpowers (PR #22)

Metrics Sourcing

  • 9 commits — stated as "9 commits across 2 repos" in brief
  • 5 + 4 commit split — stated explicitly (5 modes, 4 superpowers)
  • 160 tests passing — stated with breakdown: 29 + 37 + 94
  • 12 + 14 new tests — stated explicitly in brief
  • 6 modes configured — named explicitly: brainstorm, write-plan, execute-plan, debug, verify, finish

Gaps: Primary author attribution, exact PR merge dates, and lines of code changed were not provided in the brief and are not stated in this deck.

Get Started

Add pipeline enforcement
to your bundle

Two optional fields. Zero migration. Any bundle can define its own enforced workflow.

📖

Read the PR

Infrastructure changes in amplifier-bundle-modes PR #6. Field definitions, gate policy wiring, and test coverage.

🗺️

See it in action

Superpowers pipeline reference implementation in amplifier-bundle-superpowers PR #22. All 6 modes fully annotated.

🔧

Try it yourself

Add allowed_transitions to any mode and watch the enforcement kick in — no other code changes needed.

The modes system now enforces the pipeline, not just the tools. Agents in multi-stage workflows stay in the sequence you define — from first brainstorm commit to final ship.
More Amplifier Stories