TENANT REGISTRY · ROUTING SCOPE
Tenant registry: do not route across scope
Two tenants register agents with the same names as each other and as a platform agent. Resolve five requests and see which reach another tenant.
Your experiment
The registry holds a platform translator, an invoice agent for acme, and an invoice agent, a payroll agent and a translator registered by globex. Requests come from acme (invoice, translator, payroll), from initech (invoice, which it does not have) and from globex (translator). The opening router looks agents up by name alone, so the latest registration of each name wins.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional registry. Resolution rules are the ones listed on the page, close to the tenant-first namespaces described in the linked article; a real registry also checks the caller’s entitlements, and a missing agent should look the same to the caller as a forbidden one. No network call is made.
Names are not unique
A registry maps agent names to endpoints, and different tenants will choose the same names. Lookup key resolves a request by the agent name alone or by the caller’s tenant and the name. When the tenant has no such agent decides whether to borrow any tenant’s agent with that name, to use a shared platform agent only, or to fail. Registration of names either lets any tenant register any name or reserves the names of shared platform agents.
The opening run: the latest registration wins
By name alone, every lookup returns the most recent registration. acme’s invoice request goes to globex’s invoice agent, acme’s translator request to the translator globex registered, acme’s payroll request to globex’s payroll agent, and initech, which has no invoice agent, also reaches globex. Four requests cross into another tenant’s agent, carrying their data with them, and globex’s own translator request reaches its look-alike instead of the platform translator.
Scoping the lookup
Set Lookup key to Tenant and agent name: acme’s invoice request stays in acme, but the global fallback still sends three requests to globex. Set When the tenant has no such agent to Use a shared platform agent only: no request crosses tenants, acme gets the platform translator and payroll and initech fail closed. Fail is stricter still and also refuses the shared translator, a wrong failure. One problem remains: globex’s translator request is answered by globex’s own registration, which shadows the platform name.
Failure boundary: reserved names
Set Registration of names to Shared names are reserved for the platform: globex’s translator registration is refused, so every translator request reaches the platform agent. With tenant-scoped lookup and shared-only fallback, all five requests resolve correctly. From the opening, reserving names alone still leaves three cross-tenant routes. Scope the lookup to the caller’s tenant, fall back only to platform agents, and do not let a tenant shadow a platform name.
Reading the run and its limits
Play replays the registry contents, each resolution and the outcome over sixty inspection seconds; the table lists where every request went and where it should have gone. Next event, Restart, Speed and Inspection time control the replay. The fixture omits plan entitlements and caching; a real resolver’s cache key must include the tenant, or it reintroduces the same leak.