III · Tool Use & EnvironmentEmerging★

Tool/Agent Registry

also known as Capability Catalogue, Agent Marketplace, Tool and Agent Directory

Maintain a single queryable catalogue of both available tools and available agents, with metadata (capability, cost, latency, quality) the agent can use to pick the right one for a task.

This pattern helps complete certain larger patterns —

  • specialisesTool Discovery★— Let the agent discover available tools at runtime rather than hardcoding the tool list at agent build time.
  • used-byVoting-Based Cooperation★— Finalise a decision across multiple agents by collecting and tallying their votes on candidate options, so the joint output reflects collective rather than single-agent judgement.

Context

A team runs a coordinator agent that has to pick between many tools and many specialist agents per task: three speech-to-text services with different prices and accuracies, two summariser agents with different domain strengths, several search tools with overlapping coverage. Tools and specialists evolve independently and some are supplied by third parties, so the coordinator should not be hardcoded to specific implementations.

Problem

If the coordinator's tool palette and the list of available specialist agents are hardcoded into prompts, every new capability requires a redeploy and selection logic gets duplicated everywhere. Keeping tools and agents in separate registries leads to two parallel selection paths with diverging metadata: cost, latency, capability, and quality may be tracked one way for tools and a different way for agents, so the coordinator cannot meaningfully rank candidates across the two.

Forces

  • Discoverability: tools and agents are diverse and hard to enumerate manually.
  • Efficiency: selection must happen within the request's latency budget.
  • Tool appropriateness: the right pick depends on capability, price, context window, and quality.
  • Centralisation: a central registry is a vendor-lock-in and single-point-of-failure risk.

Example

A coordinator agent receives a task: "transcribe a customer call and summarise the action items". It queries the tool/agent registry, which returns three speech-to-text tools (ranked by per-minute cost and latency for English audio) and two summariser agents (ranked by quality on call-centre data). The coordinator picks the cheapest speech-to-text that meets latency and the highest-quality summariser, dispatches both, and assembles the result.

Diagram

Solution

Therefore:

Provide a registry that exposes a queryable catalogue of (1) tools — typed inputs/outputs, cost, latency, allowed contexts — and (2) agents — capability descriptions, supported tasks, model and provider, price. The agent queries the registry per task, ranks candidates by suitability, and dispatches. The registry can be backed by a coordinator agent with a curated knowledge base, a blockchain smart contract, or extended into a marketplace; metadata stays small (descriptions and attributes), not full schemas, to keep the registry lightweight.

What this pattern forbids. The agent cannot use off-registry tools or agents at runtime; selection is bound to the catalogue.

The smaller patterns that complete this one —

  • usesModel Context Protocol★★— Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.
  • generalisesVickrey Auction Allocation★★— Allocate a task to the lowest sealed bidder but pay them the second-lowest bid, making truthful cost reporting a dominant strategy.

And the patterns that stand alongside it, or against it —

  • composes-withInter-Agent Communication★— Define a protocol for agents to exchange tasks, capabilities, and results across process or vendor boundaries.
  • complementsSkill Library★— Let the agent grow its own toolkit by writing reusable skills that subsequent runs can call.
  • complementsMixture of Experts Routing★— Route each request to one or more domain-expert agents, where each expert holds deep capability in a narrow area.
  • complementsMCP Bidirectional Bridge★— Run a framework as both MCP client (consuming external MCP servers as tools) and MCP server (publishing its own agents, tools, and workflows back over MCP) so capabilities flow both directions across the protocol boundary.
  • complementsAgent Adapter★★— An interface layer connecting an agent's tool-calling protocol to heterogeneous external tools, normalizing their schemas into one the agent expects.
  • complementsAgent Capability Manifest★— Let each agent publish a standardized self-description — identity, skills, endpoint, and auth needs — at a well-known location, so others discover it and bind by capability at runtime instead of through hardcoded coupling.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance