officerdev/capabilities
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

affordance: spawning the worker, not only being handed one

Browse Source 
The Agent tool takes a model, so the grind can go to a cheaper one while the
manager plans and reviews. Three differences decide which arrangement fits: a
spawned agent reports to the manager and is invisible to the user, it dies with its
task where a peer accumulates context, and only a spawned one can have its own git
worktree — which is what allows parallel work over the same files.

And the constraint that goes with it: spawn only when asked. A fleet of workers is
the owner's cost to authorise.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-23 04:46:17 +00:00
co-authored by Claude Opus 5
parent beaa97e8ac
commit 4e8dea2964
1 changed files with 14 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
affordances/officer/core/coordinating-another-agent.md
+14
View File
@@ -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 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. 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 **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 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 worth anything is that the user stops being a clipboard — so if you are relaying their words unchanged, you