diff --git a/affordances/officer/core/coordinating-another-agent.md b/affordances/officer/core/coordinating-another-agent.md
index de8c880..b0a3726 100644
--- a/affordances/officer/core/coordinating-another-agent.md
+++ b/affordances/officer/core/coordinating-another-agent.md
@@ -25,6 +25,20 @@ they do, that is correct behaviour rather than obstruction. What settles it is t
 The same rule binds you in the other direction: **never ask a peer to do something you were refused.** Route
 it back to the user.
 
+**You can also spawn the worker rather than being handed one.** The `Agent` tool takes a model, so a
+cheaper model can do the grind while you plan and review; backgrounded, it wakes you when it finishes. Three
+differences decide which arrangement fits:
+
+- **A spawned agent reports to you, not to the user.** Its output is not shown to them at all — you relay
+  it — and they cannot interject. A peer session is the opposite: visible, and they can step in.
+- **It dies with its task.** A peer accumulates context across a night; a spawned one starts fresh unless
+  you keep messaging the same one by name.
+- **`isolation: 'worktree'` gives it its own git worktree**, which a peer cannot have. That is what lets
+  several run in parallel over the same files without fighting.
+
+So: spawn for grind you supervise, and reach for a peer when the user wants to watch or take over. And spawn
+only when they have asked for it — a fleet of workers is their cost to authorise, not yours to assume.
+
 **What you actually owe, as the manager:** read what they produced rather than taking the summary, write the
 next instruction yourself, and carry the standing context they do not have. The reason this arrangement is
 worth anything is that the user stops being a clipboard — so if you are relaying their words unchanged, you