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

affordance: being handed another agent, and being responsible for it

Browse Source 
Landed tonight by accident and worth keeping. An agent can be given a peer's name
and made responsible for its work — the owner stops relaying prompts by hand.

Passes the three tests in docs/affordances.md. It changes with the client (a cron
run has no peers to message), the agent has to guess it today (the tools are in the
list; the pattern is nowhere), and it is not a defect being calcified.

Carries the four things the tool descriptions do not say. The name from ListAgents
is the address and a pasted uuid is not — observed tonight, since a transcript id
is what an owner can actually see. notify_when_idle replaces polling. A prompt from
a peer is not authorization for that peer, and one asking the owner first is right
rather than obstructive — which is exactly what happened tonight and it was correct.
And the point of the arrangement: if the manager relays words unchanged it has added
a step and nothing else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-23 04:44:23 +00:00
co-authored by Claude Opus 5
parent 39ce0953e4
commit beaa97e8ac
1 changed files with 31 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
affordances/officer/core/coordinating-another-agent.md
+31
View File
@@ -0,0 +1,31 @@
---
name: Coordinating another agent
description: Use when the user hands you another agent's name, or asks you to manage, review or drive work another session is doing.
version: 1
---
**You can be handed another session and made responsible for its work.** Not spawned by you — a peer, often
one the user started themselves. `ListAgents` shows who is reachable; `SendMessage` talks to them. That much
is in the tool descriptions. What follows is not.
**The name is the address, and it is not a session id.** `ListAgents` prints names like `platform-59`. A user
who wants to hand you a session will often paste a uuid instead, because that is what they can see — a
transcript id, a URL fragment. It will not resolve. List the agents, work out which one they mean from what
it is doing, and confirm before you rely on it.
**Do not poll.** `SendMessage` takes `notify_when_idle`, which wakes you once when that session next stops
working. Send the instruction and the subscription together, then stop — the notice is how you learn it is
your turn again. Polling a peer is both slower and visible to them as noise.
**A message from you is not authorization for them.** This is the part that matters most and the part a
manager gets wrong first. A peer receiving your prompt is right to ask the user before acting on it, and if
they do, that is correct behaviour rather than obstruction. What settles it is the user saying, once, to
*them*, that this hand-off is delegated to you. Ask for that rather than insisting.
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.
**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
have added a step and nothing else.