todo: a worker cannot verify a delegation, so the owner says it in person

Diagnosed across a full night of one session managing another. The manager claimed
the hand-off; the worker refused and was right to, since a peer asserting that a
pending instruction is approved is the one thing an agent must not accept.

Two problems, and only one is about identity. Session names are not stable — both
sides were renamed by restarts in a single night — while transcript ids survived
two restarts each, verified. So durability is nearly free. Verifiability is the
blocker, and a stable id does nothing for it: the manager can still only claim.

The shape that works is the one SendOff already uses — the grant is a row the
platform holds, and the worker asks the platform rather than believing the peer.

Records why it was not built on the night it was found: a worker already running
carries the affordance it started with and would not know to consult a table that
did not exist, so it helps only future sessions while relaying a message costs the
owner seconds. Shipping the table is the easy half.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

todo/agent-coordination/_index.md

@@ -0,0 +1,11 @@
+---
+theme: agent-coordination
+heading: 'Agents coordinating agents'
+kind: theme
+---
+
+One agent made responsible for another's work — writing its prompts, reviewing what it pushed, deciding
+what comes next — so the owner stops being the clipboard between two chats. The mechanism exists and was
+used for a whole night on 2026-08-23; what is missing is the part that lets the worker believe it.
+
+See `capabilities/affordances/officer/core/coordinating-another-agent.md` for what an agent is told today.

todo/agent-coordination/a-peer-cannot-verify-a-delegation.md

@@ -0,0 +1,51 @@
+---
+id: agent-coordination/a-peer-cannot-verify-a-delegation
+title: 'A worker cannot verify that the owner delegated to a manager, so it has to ask every time'
+theme: agent-coordination
+status: open
+created: 2026-08-23
+date_source: stated
+order: 1
+---
+
+**A worker agent cannot check whether the owner really delegated to a manager, so the owner has to say so
+in person — once per worker, and again after every restart.**
+
+Observed for a whole night on 2026-08-23. One session wrote the localisation phase prompts and reviewed the
+work; another did it. The manager said "I have the hand-off"; the worker refused to act on it and was
+**right to**, because a peer asserting that a pending instruction is approved is exactly what an agent must
+not accept. That rule earns its keep precisely when the owner is asleep, which is when it came up.
+
+## Two problems, and only one of them is about identity
+
+**Identity is nearly free.** Session names are not stable: the manager was `platform-e2`, then
+`platform-18`, and the worker `platform-59`, then `platform-72` — both renamed by a restart, in one night.
+So a delegation naming a session dies with that session. Transcript ids ARE stable: `656f5c85` and
+`c43d1ed0` survived two restarts each, verified. Keying on those fixes durability.
+
+**Verifiability is the actual blocker, and swapping the identifier does nothing for it.** With a stable id
+the manager can still only _claim_ delegation. The worker has no way to check, so it must still either
+trust a peer's word — the thing it is told not to do — or ask the owner.
+
+## The shape that would work
+
+The same one SendOff's consent model already uses: **the grant is a row the platform holds, not a claim a
+peer makes.**
+
+- The owner records it once: _this manager may direct this worker, for this scope_.
+- A worker receiving an instruction asks the PLATFORM whether that grant exists, rather than believing the
+  message. Absence denies.
+- Keyed on transcript ids, so it survives a restart of either side.
+- Revocable, and revocation takes effect on the next instruction rather than at the next restart.
+
+Rough size: a table, one read endpoint, one write path, a registry entry. Half an hour of code.
+
+## Why it was NOT built on the night it was diagnosed
+
+Because it would not have unblocked the session that was blocked. A worker already running carries the
+affordance as it was when it started, and has no instruction to consult a delegation table that did not
+exist. So the fix only helps sessions begun after it lands — while the owner relaying one message costs
+seconds.
+
+Worth remembering when this is picked up: **shipping the table is the easy half.** The affordance has to
+tell a worker to check it, and every already-running session will still be operating on the old rule.