⚠ A correction to how this phase was described, because it matters: it does not give bridges their own voice. They have had that since the identity work.
There are two paths, and they were never the same. A bridge posting into its own room mints its own token and speaks as itself — already correct. But the tool the worker calls to post into any channel authenticated with a shared login read from one env file that every bridge was launched with. So attribution was impossible rather than merely awkward: eight bridges, one posting identity.
This phase fixes the second path only — which is exactly what makes cross-channel posting attributable.
⭐ No schema was needed. The chain from key to agent to bot user to sender was already built; it simply was not being used on that path.
⚠ And the plan’s shape was wrong in one place, which cost real work. The tool could not simply “use the key”: the send endpoint’s middleware is token-only, so it had no agent arm at all and one had to be built. The password arm was also kept, where the plan said “instead of” — the operator’s own registrations authenticate with it and carry no bridge key, so removing it would have been a flag day. The key wins when both are present.
⭐⭐ And there was a trap sitting in plain sight: the obvious environment variable name was already taken by a different agent’s key. Reusing it would have reported that agent alive instead of the bridge. A distinct name was introduced, with the warning repeated at every touchpoint.