Run the Amp manager

The Amp manager is Revue's preferred cockpit for supervising children, Orbs, and subagents. It can show shared blockers, answer once for several workstreams, inspect lineage, and route decisions back into running Amp threads.

The manager is not the product boundary. Claude Code, Codex, and other MCP harnesses remain first-class askers through the same decision plane.

Install and launch

Install Revue once:

REVUE_START=0 bash -c "$(curl -fsSL https://raw.githubusercontent.com/ethandaya/revue/main/scripts/install.sh)"

The installer downloads the standalone binary to ~/.local/bin/revue and installs the Amp plugin and human-context skill into your user configuration. REVUE_START=0 returns to the shell instead of launching Revue immediately.

Select a local or hosted plane, then launch the resident manager:

revue service start  # omit when hosted is already active
revue serve

revue serve syncs the installed plugin and skill, mints a short-lived delegation scoped to this manager run and Amp thread, and runs amp --no-tui as a stable local runner. Attach from Amp using the printed revue-manager-* runner name. Bare revue remains the terminal-bound interactive alternative. From a Revue checkout, use pnpm run revue serve.

Ask the manager in chat:

launch an orb to investigate CI
launch a local child to write the regression test
show blocked decisions
answer the top decision with option B
show which sessions are at risk of losing an answer

Child completion does not require you to watch each child thread. Revue batches newly terminal children into one progress message on the manager thread so the manager can inspect their durable findings and continue dependent work. The resident manager also reconciles hard-killed native children: an Amp error becomes a failed child, while an idle child with an unfinished turn becomes orphan-risk for recovery. A blocking decision is appended separately with an instruction to present it and end the manager turn, making the waiting state explicit when the manager follows that instruction.

How the plugin disciplines asks

The plugin registers a revue custom mode that keeps Amp's normal coding tools while adding decision memory, structured asks, routed answers, and lineage. Before an Amp agent can make a decision ask, it follows this order:

attention_market
attention_account
decision_lookup
radio_query
if reusable decision applies:
  apply it and continue
else:
  attention_bid

The first four calls are reads and do not create an interruption candidate. attention_bid is non-blocking: a later message beginning Human decision: carries the answer into the owning thread.

Good asks contain one question, mutually exclusive options, a recommendation, risk, reversibility, compact evidence, and the affected concepts and files. Scope metadata improves grouping and future reuse.

Normal Amp sessions receive the ask-side tools:

revue_plugin_status
revue_context_event
revue_subagent_register
attention_market
attention_account
decision_lookup
radio_query
radio_publish
attention_bid

Manager sessions additionally receive:

revue_manager_status
revue_rollup
revue_child_list
revue_child_register
revue_child_launch
revue_lineage
revue_watch_decisions
revue_answer_decision
revue_dismiss_decision
revue_correct_decision

Answer, dismissal, and correction tools require an explicit human instruction plus the manager delegation. Children and subagents cannot call them.

Read How a decision moves for grouping, route proof, and receipt semantics.

Launch children and Orbs

The manager can call revue_child_launch directly. The CLI provides the same backup path:

revue child "Investigate CI and bid only for true human decisions" --where orb --launch
revue child "Write the focused regression test" --where local --effort low --launch

--where orb launches a remote Amp Orb and therefore requires the hosted plane. --where local launches on this machine and can use either active plane. Child authority never includes the manager's human answer delegation.

Under revue serve, local children run in process-isolated revue-child execute sessions. This avoids Amp's no-TUI native-thread fallback to a built-in mode. Headless children use an owner-only copy of your Amp settings with unrelated MCP servers removed, so an expired MCP login cannot strand a routed decision on an invisible prompt. If a child exits while a blocking decision is open, any answer surface creates the same pending route; the resident manager resumes that exact Amp thread, and the fresh child plugin claims the route, applies the answer, and reports completion.

Choose --effort by ambiguity rather than task size. Supported tiers are none, minimal, low, medium, high, xhigh, and max; the default is medium.

Answer and steer

Answer from manager chat when possible so the decision and swarm context stay together. The resident manager also discovers answers recorded by the terminal inbox or CLI and resumes process-isolated local children. The terminal controls are:

revue inbox
revue answer top "Use the focused callback test."
revue dismiss top "Not worth interrupting us for."
revue steer latest "Add the regression test before refactoring."

Wrong or stale memory remains human-correctable:

revue why decision-lot-<lotId>
revue correct decision-lot-<lotId> ask_next_time --note "The surrounding contract changed."

revue why traces the source decision, scope, corrections, and reuse history. revue correct narrows, retires, or expires memory; it does not delete the source record.

Keep the manager resident

The preferred manager workflow is resident. Run:

revue serve

revue serve runs amp --no-tui and keeps the manager attachable through ampcode.com Remote Control. It does not start the decision plane; revue service and revue serve are separate processes. Bare revue is the terminal-bound alternative.

The command prints a stable revue-manager-* runner name. In Amp, create a thread, open New Orb, then select that name under Runners. Amp uses “New Orb” for the location picker, but this choice keeps execution on your machine through amp --no-tui; it does not launch a cloud Orb. Start with show Revue status rather than calling diagnostic plugin tools directly.

When Amp is unavailable, answer from text mode:

revue watch --interactive

revue watch is the foreground terminal fallback. It polls the active decision plane, alerts for one cleared blocking decision at a time, and reuses the interactive inbox answer flow. Keep the command running in a supervised foreground terminal when the Amp manager is unavailable.

revue doctor distinguishes manager-thread append proof from manager presentation. A presented message proves that a completed manager turn consumed the queued notice; neither state proves that a phone or desktop notification was displayed.

Delivery modes and proof

An ask can request queued, steered, or interrupting delivery. Revue records only the deepest route state the integration can prove: claimed, delivered, consumed, applied, resolved, or failed. These states prove transport and observed lifecycle, not code correctness.

The answer, receipt, and any explicit context are intentional persisted content. Ambient lifecycle events omit prompts, assistant text, tool inputs and outputs, shell commands, working directories, and file paths. Read the Data boundary for local and hosted storage.

Manual launch and configuration

revue setup writes the selected plane to ~/.config/revue/local.env. revue amp resolves credentials, prepares manager authority, and starts Amp in Revue mode. For manual plugin development, prepare the same manager environment explicitly:

eval "$(revue manage --print-env)" && amp --mode revue

Set REVUE_AGENT_MODEL to override the mode's model; the default is openai/gpt-5.5. See Configuration for the supported environment.

For plugin development only, install the workspace copy manually:

scripts/install-revue-plugin.sh --workspace

Amp loads the installed plugin without a gate variable. revue normally keeps the plugin, skill, and environment synchronized automatically.