From beaa97e8ac6ff0ca92943150bc11c776976e3f26 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sun, 23 Aug 2026 04:44:23 +0000 Subject: [PATCH] affordance: being handed another agent, and being responsible for it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .../core/coordinating-another-agent.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 affordances/officer/core/coordinating-another-agent.md diff --git a/affordances/officer/core/coordinating-another-agent.md b/affordances/officer/core/coordinating-another-agent.md new file mode 100644 index 0000000..de8c880 --- /dev/null +++ b/affordances/officer/core/coordinating-another-agent.md @@ -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.