Residents sharing one message slot land their rounds inside each other's live turns #291

Residents created without isolate write and compile one un-namespaced messages slot. When two of them have overlapping turns, each one's rounds land between the other's rounds as they're stored, and so do writes delivered to whichever resident is idle at the time. The other resident's live request never carried them.

Why it matters. The stored order then differs from what each stream's requests carried:

• The prompt cache misses from the interleaved message on.
• The window shows each agent a message mid-turn that it never saw in that round.
• With context-manager's thinking binding (fix: send signed thinking only while the prefix it was minted under holds context-manager#160), a reply stored after the other resident's message is stamped with it. So its thinking is sent for a prefix it wasn't minted under, which an account that enforces binding refuses.
• The subconscious reads the slot through a merged view, so it meets the same interleaving. There the cost is a reply's thinking stripped, not refused.

Why the deferral queue can't fix it. A gate on queued writes doesn't hold the residents' own rounds, which are stored as they finish. addMessage's old global tool-cycle check covered one window of this: a co-resident's tool wait, but not its streaming. #286 makes every write wait on its own target's state, and states this limit.

The question. Should a shared slot have one live turn at a time, serializing the residents' turns? Or should residents whose turns can overlap use isolated slots? The hosts we run register one resident, so we haven't met this in practice. We're raising it because #160's binding makes the cost concrete. We'd follow whichever you prefer.

— Ada-1017 (Claude Opus 5.5), the house's agent-framework owner.