Find a realm by its name, not its address

An app publishes a namespace — task, mem, cnv, parts. An agent in a different app wants to use it. The two were built separately, deployed separately, and neither knows where the other runs. The thing that connects them is the named-services discovery service: a small registry where a consumer asks "who owns task?" and gets back an answer — without anyone hardcoding an address.

That one move — resolve by namespace, not by location — is what makes the ecosystem composable. (For the full realm-connection picture, see the Deep blog "Your app as a service provider in the agentic network"; this Short is only about the find.)

The registry: a directory of who-owns-what

The discovery service is a small directory of who owns which namespace, scoped to one tenant and project. Its core is an index keyed by namespace: each namespace name points to the set of providers that publish it. That is the anchor — a join table by name, where the key is a namespace and the value is "who can answer for it."

discovery table  (per tenant / project)
  namespace:parts   →  { inventory.parts }
  namespace:task    →  { task.issue }
  namespace:mem     →  { memory.record }

Nothing here is an address. The index maps a name to who — the where is carried separately, in each provider's record, and only handed to a caller once discovery has resolved the name.

How providers register: publish on load

When an app loads, its provider writes one record into the table. The record says what it owns — its namespaces and provider_id — and how to reach it — the endpoint: the transport, the app package it lives in, the provider handle.

provider record
  namespaces:   parts
  provider_id:  inventory.parts
  endpoint:     transport · app package · provider

The key move: that one write files the provider under every namespace it owns, adding it to each namespace:{ns} set. One registration, indexed by name — so a consumer can later find it by namespace without the provider ever announcing a URL.

How consumers discover: resolve by namespace

A consumer app does not name a provider. In config it declares that it consumes namespace parts. At call time it asks discovery to resolve that name; discovery reads the namespace:parts set and returns the endpoint of whoever published it — even though that provider lives in a different app package.

consumer: "I consume namespace `parts`"
        │
        ▼
discovery.resolve(namespace="parts")
        │   read namespace:parts → inventory.parts → its record
        ▼
endpoint  →  transport · the publishing app package · provider
        │
        ▼
the agent calls parts.search / parts.get / ... on a realm
it never had to locate

The consumer never learned an address, a host, or which app package owns parts. It learned a name, and discovery did the rest. Move the provider to a different app, re-deploy it, let it re-register — the consumer config doesn't change, because it was never pointing at a place.

Why this is the composable seam

Hardcoding a provider's location couples two apps forever: you cannot move, split, or replace the provider without editing every consumer. Discovery breaks that coupling. An app publishes once; any consumer that declares the same namespace finds it anywhere — same tenant and project, any app package.

That is also why the published namespaces (mem, cnv, a task realm, your own) are reachable across the network at all: the realm is the what, discovery is the how-to-find. Publish a realm by name; the registry is what lets the rest of the world ask for it by that name.

Documentation on GitHub

The live docs behind this entry:

• Named-service discovery
• Named services — overview
• Connecting a namespace