AI Agent Discovery Is a Bigger Bottleneck Than Reasoning

A model can choose only among the capabilities its host exposes. Better reasoning does not help when the right tool is absent, incompatible, stale, untrusted, or forbidden by policy.

That makes discovery a systems problem, not a search prompt. A production discovery layer must answer five different questions: what exists, what matches the intent, what can interoperate, what is trustworthy enough, and what should be selected now.

Tool calling, service discovery, and capability discovery

Mechanism	Question answered	What it does not prove
Tool calling	Which already-connected function should the model invoke?	That the host connected the best or safest function
Service discovery	Where is a named technical endpoint and is it healthy?	That its capability fits the user's intent
Capability discovery	Which qualified provider can satisfy this typed intent under current constraints?	That execution will succeed; verification is still required

MCP tool definitions expose names, descriptions, and input/output schemas within a connected server. A2A Agent Cards advertise a remote agent's identity, endpoint, authentication, and skills. Those are important protocol primitives. An ecosystem still needs registry, qualification, policy, and selection around them.

The five-stage discovery pipeline

Typed intent + constraints
          │
          ▼
1. Registry retrieval ──▶ fresh candidate descriptors
          │
          ▼
2. Semantic matching ──▶ plausible capability set
          │
          ▼
3. Compatibility ──────▶ callable candidates
          │
          ▼
4. Trust qualification ▶ policy-eligible candidates
          │
          ▼
5. Runtime selection ──▶ route + fallback + evidence plan

Each stage reduces the set for a different reason. Combining them into one embedding search makes rejection hard to explain and unsafe candidates easy to rank.

Stage 1: registry and freshness

A registry is an inventory, not a trust oracle. Each entry needs a stable identity, publisher, versions, status, discovery source, last verification time, and expiry. Dynamic endpoints require health and freshness separate from capability metadata.

Registries may be local configuration, an enterprise catalog, a marketplace, DNS-style discovery, or a federated index. The important controls are:

• immutable version identifiers rather than “latest”;
• signed or otherwise authenticated publisher updates;
• tombstones for revoked versions;
• bounded cache age and an explicit offline policy;
• provenance showing how the entry entered the registry.

Stage 2: semantic capability matching

Names are poor discovery keys. A user asking to “remove customer identifiers before analysis” may need data classification, PII detection, redaction, structured-file parsing, and an auditable output—not a tool literally named remove_identifiers.

Match against a typed intent:

{
  "objective": "redact direct identifiers from a CSV",
  "input": {"mediaType": "text/csv", "classification": "confidential"},
  "output": {"mediaType": "text/csv", "requiredEvidence": ["redaction_report"]},
  "constraints": {"localOnly": true, "maxLatencyMs": 30000}
}

Semantic retrieval should maximize recall, not make the final choice. Candidate descriptions are publisher claims and may be vague, adversarial, or simply wrong.

Stage 3: compatibility filtering

Compatibility is mostly deterministic. Reject candidates that fail any hard requirement:

• protocol and revision;
• input and output schema;
• authentication method and principal delegation;
• data residency and network boundary;
• synchronous versus durable task behavior;
• maximum payload, timeout, and streaming support;
• effect type, idempotency, and cancellation semantics.

A semantically perfect service that cannot accept confidential data under the current policy is not a lower-ranked candidate. It is incompatible and must be removed.

Stage 4: trust qualification

Trust is contextual. A tool may be acceptable for public web research and unacceptable for payroll data. Qualification should combine independently verifiable evidence:

Evidence	Question	Limitation
Publisher identity	Who is accountable for this descriptor?	Identity does not prove behavior
Artifact digest/signature	Is this the reviewed version?	A signed malicious artifact is still malicious
Verification record	Which checks ran against which digest?	Coverage and freshness matter
Execution attestation	What actually ran and changed?	Requires trusted collection and verification
Operational history	How often did comparable calls succeed?	Past performance is workload-specific

My SkillLedger architecture explores this entitlement and verification layer. The unverified-skill threat model explains why metadata alone is insufficient.

Stage 5: policy-aware runtime selection

After hard filters, rank eligible candidates for this request. A simple selector can use:

score =
  0.35 × task-quality evidence
+ 0.25 × reliability for this workload
+ 0.15 × trust-evidence freshness
+ 0.10 × latency fit
+ 0.10 × cost fit
+ 0.05 × locality preference

The weights are policy, not universal truth. Record them with the decision. Also record the next eligible fallback and the condition under which failover is permitted. Never silently fall back across a stronger data boundary or weaker approval requirement.

Worked example: selecting a redaction capability

Candidate	Semantic fit	Compatibility	Trust	Decision
Cloud text redactor	High	Fails local-only constraint	Not evaluated	Reject
Local regex utility	Medium	Compatible	Reviewed digest	Fallback for defined identifier types
Local structured PII service	High	Compatible	Fresh evaluation and audit report	Select
Unknown marketplace skill	High claim	Compatible	No publisher or verification	Quarantine

The selected service still needs output verification: schema validation, a seeded-fixture test, and a redaction report reconciled with the input. Discovery chooses a qualified route; it does not certify the result.

Descriptor versus live evidence

Keep relatively static claims in the capability descriptor and volatile measurements in separate evidence records. Otherwise every latency observation forces a signed manifest update, or stale operational claims linger indefinitely.

• Descriptor: identity, version, protocols, schemas, effects, constraints, publisher claims.
• Evidence: verification result, benchmark population, success rate, incident history, measured latency, expiry.
• Policy: which combinations of descriptor and evidence are eligible for a specific principal and data class.

Failure modes to design explicitly

• Registry poisoning: authenticate updates and separate untrusted catalogs.
• Description gaming: do not rank publisher prose as proof of quality.
• Version drift: resolve to immutable artifacts and invalidate changed digests.
• Stale trust: attach expiry to checks and operational evidence.
• Confused deputy: bind calls to the requesting principal and scoped authority.
• Unsafe fallback: preserve policy constraints across every alternate route.
• Discovery loops: bound federation depth, candidate count, time, and cost.

Download the descriptor schema

I published a vendor-neutral JSON Schema for the stable half of the model: identity, capabilities, interfaces, constraints, effects, and trust-evidence references.

Download the capability descriptor schema

Try it against your stack: can the selector explain why every rejected candidate failed, and can an operator reproduce why the winner was eligible? If not, the system has search—not qualified discovery.