pastilhasandClaude Opus 5
c7b767aa04
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>
2.7 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| agent-coordination/a-peer-cannot-verify-a-delegation | A worker cannot verify that the owner delegated to a manager, so it has to ask every time | agent-coordination | open | 2026-08-23 | stated | 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.