Brief a sub-agent like a colleague, not a warrant

Agent dispatchFreshClaudeverified 2026-06-21sha fb1427654392

Born in: the post where it earned its place →

Breaks when: The trust posture is calibrated for low-stakes, reversible work. Mis-classify an irreversible, security-sensitive, or order-dependent task as routine and "adapt freely" turns a guardrail into a loaded gun – the agent improvises exactly where it must not. The strict-mode gate up front is the guard against that, but it only protects you if you actually run the classification honestly; a lazy "this looks routine" defeats it. It also optimizes for completion, so when correctness or safety must dominate over getting-it-done, the wrong objective is baked in. The constraints cap is a forcing function to cut defensive residue, not a guarantee you listed the right invariants – under-count what is load-bearing and a real limit goes missing. And even with a SCOPE line, an agent told to adapt can still "solve" the task by expanding into adjacent systems; the scope boundary narrows that blast radius but does not eliminate the judgment call about what counts as in-scope.

Vendor “dispatch a sub-agent” templates read like a restraining order: a recipe of exact commands plus a wall of “do NOT touch X” lines, most of which are the author’s suspicion, not a real invariant. That phrasing is why dispatched agents halt at step one – the first command hits a dependency quirk the recipe did not predict, and a prompt full of prohibitions has given it no license to recover. This contract inverts the wording: classify the task first, then state the outcome, say why it matters, bound the work area, list only the few constraints whose violation actually breaks the project, and explicitly authorize in-scope improvisation with a retry-before-escalate failure path. The un-clonable part is the strict-mode gate that fires BEFORE any of that, the self-check that makes you delete defensive residue and prove the done-list, and the recover-vs-halt rule that fails closed the moment an attempt leaves a trace.

You are briefing a sub-agent to do a piece of work on its own. Write the brief the way you would brief a trusted colleague you will not be able to reach mid-task - give it the outcome and the why, the few hard limits that genuinely matter, and the room to figure out the rest. Do NOT write it like a warrant: a rigid command-by-command recipe wrapped in a wall of prohibitions makes a capable agent halt at the first surprise the recipe did not foresee.

STEP 0 - CLASSIFY THE TASK FIRST. Before you write a single section, decide: does this work involve deletes, migrations, deploys, moving money or credentials, security-sensitive data, irreversible state, or steps that must run in an exact order? If yes - or if you are unsure - this is a STRICT-MODE task and the rules below change. In STRICT MODE you do NOT include the ADAPT FREELY section at all, and you REPLACE the FAILURE MODE section with: "STOP on any deviation, unexpected output, missing prerequisite, or uncertainty, and report before doing anything else." Open the brief with one line: "STRICT MODE - do NOT adapt; follow these steps exactly" plus one line stating WHY this task is strict. Here the recipe-and-prohibitions posture is the correct one and improvisation is the hazard. A brief that contains both a strict-mode banner AND an adapt-freely license is malformed - never ship both.

If the task is genuinely routine and reversible, fill in this skeleton, in this order, and hand the result down as the dispatch:

GOAL
One sentence naming the desired END STATE, not the steps to get there. "The test suite passes on the project's pinned runtime in CI" - not "run the version-switch, then the install, then the test command". Describe done, not the path.

CONTEXT
Two or three sentences: why this matters, what it unblocks, what depends on it landing. The agent makes better judgment calls when it knows the stakes, not just the instruction.

SCOPE
Name the expected work area and the acceptable blast radius - the files, the module, the surface the agent is meant to touch. The agent may adapt its METHODS inside that area, but may NOT expand the task, change unrelated public behavior, add new dependencies, or make any irreversible change unless this brief explicitly authorizes it. Adaptation lives inside SCOPE; it is not a license to widen it.

CONSTRAINTS (load-bearing ONLY)
List only invariants whose violation BREAKS the project - a public contract, a data-safety rule, an irreversible boundary. Each must be a real "if this is wrong, real damage" line. Before you write each one, ask: is this a true invariant, or just my hunch about how the agent should work? Delete every "do NOT touch file X" / "do NOT change approach Y" that is mere preference or suspicion - those are the lines that make an agent freeze. Prefer one to three load-bearing constraints; if you reach for more, that is a signal you are smuggling preferences in as laws, so cut the preferences. But if more than three are GENUINELY required - privacy, legal, security, finance and publishing work can carry several real invariants - keep them all, or group them under named invariant categories. Never delete a real invariant just to hit a number; the cap targets defensive residue, not real laws.

ADAPT FREELY
State plainly that the agent is authorized to find its own path TO THE GOAL, WITHIN SCOPE: try a different dependency flag, work around an environment quirk, substitute an equivalent command, pick a cleaner implementation than the one you imagined. Anything inside SCOPE and not named in CONSTRAINTS is fair game. But any step that is irreversible - a delete, a deploy, a migration, a spend, a credential move - is out of bounds unless GOAL or a CONSTRAINT named it explicitly; if the agent finds it needs one and was not authorized, it STOPS and asks. You are licensing judgment, not insubordination, and not destruction.

FAILURE MODE
On a transient or unexpected error: investigate the actual cause, then retry ONCE - one end-to-end recovery attempt with a different approach, not one retry per sub-command. Escalate back to me ONLY if recovery genuinely fails, with what you tried, why it did not work, and the current state of the system. Do NOT halt on the first error and do NOT report a recoverable hiccup as a blocker - a colleague would try the obvious fix before knocking on my door. BUT do NOT retry at all if the failed attempt may have left a partial side effect, changed external state, touched production data, exposed a secret, or signals a violated constraint - in those cases treat it as a blocker, stop, and report immediately. Retry is for clean failures only.

DONE
A concrete success checklist the agent can verify against itself before declaring victory - independent checks that would FAIL if the goal were not actually met, stated as commands, artifacts, or signals a third party could re-run (a passing check, output that proves the END STATE, a file that now exists with the right contents). Do not let the checklist be satisfiable by weakening or deleting the check itself. Vague "looks done" is not done.

REPORT
One summary at the end: what it did, the evidence it is done, what it adapted and why, and anything it could NOT resolve. Report findings UP to me in this summary - do not open side channels or surface work elsewhere.

THEN, BEFORE YOU SEND IT, self-check the brief you just wrote:
- If the task is irreversible, security-sensitive, order-dependent, or you were unsure, did you switch to STRICT MODE before granting any adaptation - and is the adapt-freely license absent?
- Is every CONSTRAINT actually load-bearing, or did defensive residue sneak back in? Cut what is not. Are the agent's adaptation rights bounded by SCOPE and CONSTRAINTS, not open-ended?
- Does DONE contain evidence that would independently PROVE the GOAL, or only a log of activity? If it only proves activity, rewrite it into checks a third party could re-run.
- Read it cold: does it sound like briefing a trusted colleague, or like issuing a warrant to a suspect? If it reads as a warrant, rewrite it until it reads as a briefing.

Fill in: task_goal context constraints strict_mode

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.