Phase 9 — Attached machines: made visible where humans work
31 AUG AT 11:14 AM

Phase 9 — Attached machines: made visible where humans work

0 LOVES 2 VIEWS
A reader in a channel with a bridge had no way to know a machine was there. The fix required admitting there are two kinds of agent, and that one case honestly gets no header at all.

Not derived, and that is the point

By this point the fleet was fully manageable from the admin tier — and completely invisible from the place people actually read: the conversation itself. A reader in a channel with a bridge in it had no way to know a machine was there.

The expensive way to answer that was measured before it was written. The obvious implementation asks “does this channel contain agent messages?” per page view. The query plan for that is a full table scan — against nearly twenty thousand agent messages on the busiest production channel, to render one line of text. The available indexes do not help.

⚠ And deriving it from the loaded window would have been worse than expensive — it would have been wrong. The thread paginates. Agent messages five hundred back set no header, so the reader scrolls up, meets the glyphs anyway, and lands in exactly the unexplained state the header existed to prevent. The hole moves rather than closing, which is the failure mode that looks like a fix.

So the answer is stored rather than derived, and the surface carries a rule of its own: put no operator-controlled free text on a reader’s page. The header is a constant string, the glyph is an icon, the note is a constant string.

Two kinds of agent, and a header that refuses to claim

Everything drafted for this phase modelled one kind of agent. An earlier phase had already settled that there are two, and this doc had forgotten it — recorded here rather than quietly repaired, because the correction is the interesting part.

  • A responder joins a channel, watches it, and replies. There is exactly one, enforced by a unique edge.
  • A participant posts into a channel without joining it. There can be any number — and they need no bridge at all.

⭐ So the header and the icon answer different questions, and are allowed to disagree. The case that matters most had no row in the original design: a channel with no responder but with agent messages in it. That gets glyphs on the messages and no header at all.

That is the honest answer rather than a gap. The header answers “is anyone assigned to answer here?” — a question only a responder can answer. A header about an assignment that does not exist is a claim the product cannot make, so it does not make one. The glyphs carry that case alone, and the action sheet is how they explain themselves.

The header also never names the machine. The message bubbles already render the sender’s address, so a header saying a bot’s name would put two labels for one machine on one screen with nothing connecting them.

⭐ And that choice deleted an attack surface rather than guarding one. An earlier draft named the agent, which meant it needed a truncating, escaping name span to survive a hostile display name — a forging payload for exactly that is still sitting in the dev database. Choosing the constant string retires the span and its guard together.

⚠ Stated plainly: two of the four cases are covered by widget tests and were never observed live on either surface, because dev has no running bridge.

Pushing Tin — managing a bridge fleet from inside the product
Pushing Tin — managing a bridge fleet from inside the product
Aug 29, 2026 Pushing Tin
← Back to Pushing Tin