Dynamic Discovery in Agent Networks: From Hardcoded Routes to Capability Catalogs

May 11, 2026

The simplest way to connect two agent ensembles is a direct reference: ensemble A knows ensemble B’s address and calls it. This works when you have two or three ensembles with stable relationships.

It stops working when you have ten ensembles, or when ensembles come and go, or when the same capability is provided by multiple ensembles and you want the caller to use whichever one is available. At that point, you need discovery — a way for ensembles to find capabilities without knowing in advance who provides them.

The static wiring problem

In a statically wired agent network, every cross-ensemble call requires knowing the provider’s identity and address. This creates coupling. If the provider moves, every caller needs updating. If you add a second provider for capacity, callers need load-balancing logic.

The fundamental issue is that callers should care about what they need, not who provides it or where it runs.

Capability advertisement with tags

AgentEnsemble v3.0.0 introduces capability discovery. Ensembles advertise their shared tasks and tools with optional tags, and other ensembles discover providers at runtime:

Ensemble kitchen = Ensemble.builder()
    .chatLanguageModel(model)
    .task(Task.of("Manage kitchen operations"))
    .shareTool("check-inventory", inventoryTool, "food", "stock")
    .shareTask("prepare-meal", mealTask, "food", "cooking")
    .build();

kitchen.start(7329);

// Another ensemble discovers capabilities dynamically
NetworkTool inventoryCheck = NetworkTool.discover("check-inventory", registry);

Tags classify capabilities for filtered discovery. Query for categories rather than specific names:

List<CapabilityInfo> food = registry.findByTag("food");
List<CapabilityInfo> stockChecks = registry.findByTags("food", "stock");

Dynamic vs. static wiring

The two approaches coexist. Use static wiring for well-known, stable relationships. Use dynamic discovery for capabilities that may be provided by different ensembles depending on deployment, capacity, or availability.

The agent using the task or tool does not know which approach was used to create it.

Tradeoffs

Discovery adds a lookup step. Initial resolution queries the registry; subsequent uses are cached.

Tag semantics are convention-based. No schema enforcement — tag conventions need to be agreed upon across teams.

Multiple providers create ambiguity. The registry needs a selection strategy (least-loaded, round-robin, affinity-based).

Registry availability is a dependency. For critical paths, consider falling back to static wiring when discovery is unavailable.

The design principle

The useful abstraction is separating what from who. An ensemble that needs a capability should express that need without specifying the provider. This separation enables the network to evolve — new providers can come online, existing providers can be replaced, capacity can be redistributed — without callers needing to change.

Capability discovery is part of AgentEnsemble. The discovery guide covers the full API including tag-based filtering.