Brief one task

Give Amp one outcome, clear limits, and a way to prove the result.

one task
    ↓
one owner
    ↓
one proof target

Start with the result and repository, not a role-play prompt. Amp can use repository guidance from AGENTS.md; put only task-specific context in the assignment (AGENTS.md, Prompting).

Outcome:
  desired result
Scope:
  files or subsystem
Start:
  code, issue, or failure
Verify:
  commands and observations
Do not:
  forbidden or approval actions
Return:
  evidence and uncertainty

A useful brief is not necessarily long. It names the decision Amp owns, the authority it does not have, and the evidence you need before accepting the work.

Choose a mode and environment

Match reasoning to uncertainty and execution to the state the task needs.

Amp documents modes as capability presets, not promises about a fixed model (The Dial, Models). An orb is a remote machine rebuilt from committed setup and resume hooks; project settings can add pre-clone prerequisites and a pre-setup script outside the repository (Customizing Orbs). Keep stable team setup in the repository, where it is reviewed with the code, and use project-stored scripts only for clone blockers or transitional setup. A registered runner executes on the live machine you choose.

Mode answers task uncertainty; environment supplies machine state. Change either only for a concrete task need. Orb size is a third control: pick it from build, test, and service load, and inspect personal or per-thread usage through Puck or the CLI before changing the default (Sizes & Costs, “Explain Usage”).

Delegate only independent work

Add another worker only when its slice and return path are unambiguous.

Built-in subagents have separate context, cannot take mid-task guidance, and return one final result (Modes & Models). Use one only when an independent investigation, test run, or review can be handed back that way. Ask Oracle only when a specific unresolved question could change an important decision (Tools).

Keep overlapping edits and final integration with one owner. Otherwise, one agent is enough.

Require proof before accepting the change

Ask Amp to return executed checks, observed behavior, and remaining uncertainty.

change
    ↓
checks + running system
    ↓
diff + evidence
    ↓
human acceptance

Name the proof in the initial brief. For a logic change, that may be a focused test plus the broader suite. For a UI change, require the affected route and states to be exercised in a real browser. In an orb, a Portal can expose a running HTTP service through an authenticated URL for inspection (Portals).

Ask Amp to inspect its own diff and return the decisive command output, observed behavior, and any check it could not run. A passing test proves only what it exercises. A Portal transports a running interface; it does not prove the interface is correct. You still decide whether the evidence answers the original task.

Automate only a proven loop

Schedule or trigger work only after the manual task has a reliable verifier and stop condition.

If this task becomes repeatable, a schedule can wake Amp from a saved prompt in the same thread (Automations); a webhook can store an event and wake an orb (Event-Driven Orbs, Plugin API). Webhook URLs are credentials, bodies are untrusted, and delivery is at least once.

Do not enable either until one owner has defined allowed changes, a repeatable verifier, duplicate or partial-delivery safety, and an expiry.

That is the durable Amp workflow: brief clearly, place work deliberately, verify before accepting, and add concurrency or automation only when ownership is clear.

Sources used

• Product behavior was checked on 2026-08-26 against Amp Docs, Orbs, Models, Plugin API, Pricing, and Chronicle. The Docs take precedence; model routing, pricing, plan limits, and interface details are intentionally omitted because they change. All workflow recommendations above are author guidance, not claims that Amp improves productivity or quality.