The one-way concern is valid for a shared singleton registry, if multiple agents can register against the same source NFT, tokenToAgentId has no canonical answer.
The per-collection factory model resolves this by construction. Each registry is bound to exactly one collection via an immutable set at construction, there is no setBinding(). Within that registry, registerWithSource(sourceTokenId) writes to a sourceTokenId → agentId mapping that makes the reverse lookup unambiguous: one source token, one agent, one registry, one collection.
Cross-collection registration is structurally impossible, a second registry cannot claim the same collection address. So tokenToAgentId on our per-collection registry is genuinely 1:1 and bidirectional.
This is exactly the argument we opened in the ERC-8004 factory thread (https://ethereum-magicians.org/t/erc-8004-in-production-per-collection-factory-vs-chain-singleton-which-should-be-the-reference-architecture/ ) the singleton vs. factory debate determines whether bidirectional lookup is even possible at spec level. Worth linking the two discussions.
On ERC-8122 / ERC-6909 - noted, will look at the lighter-weight approach. The ERC-721 choice on our end was driven by wanting the agent NFT itself to be tradeable and ownable, but the binding mechanism is separable from that.