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>
52 lines
2.7 KiB
Markdown
52 lines
2.7 KiB
Markdown
---
|
|
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.
|