Verified-capability routing for multi-agent systems

A reference build for capability-based agent routing: maintain a registry of verified agent capabilities (proven by evals, not claims), enforce trust boundaries, and dynamically route tasks to agents whose verified capabilities match requirements.

The problem

Multi-agent systems fail at routing: tasks go to agents based on prompt engineering, vague role descriptions, or hope. An agent claims it can "handle complex reasoning" but fails on multi-step math. Another says it's "great at code" but can't write tests. The routing layer has no ground truth — only marketing copy from the agents themselves.

This compounds with scale. Three agents? You can memorize who's good at what. Thirty agents? Three hundred? The system needs a capability registry with verified claims: what each agent can actually do, proven by evals, with confidence scores and trust boundaries. Routing becomes a capability-matching problem, not a prompt-tuning exercise.

The constraints

This is a reference build, so the constraints mirror production multi-agent deployments: the registry must store capability claims with verification evidence (eval scores, test results, execution traces); trust boundaries must be enforceable (some agents can't access certain data, tools, or actions); routing must be dynamic (agents come and go, capabilities degrade over time); and the system must be auditable (why was this task routed to that agent?).

The decisions

Five of them, each a rejection of a naive default.

Capabilities are verified, not claimed. The build rejects the pattern of "agent says it can do X." Instead, capabilities are verified by evals: an agent that claims "math reasoning" must pass GSM8K or equivalent; one that claims "code generation" must pass HumanEval or task-specific tests. Verification is load-bearing — unverified capabilities are marked as such and excluded from high-stakes routing.

Trust boundaries are explicit and enforced. Agents operate at different trust levels: some can access production data, others only sandboxes; some can call external APIs, others are isolated. Trust boundaries are explicit in the registry and enforced at routing time — a high-capability agent at low trust can't be assigned tasks requiring high trust, regardless of capability scores.

Routing is requirement-driven, not agent-centric. Tasks declare requirements: "needs math reasoning ≥0.8, code generation ≥0.7, trust level: high." The router queries the registry for agents whose verified capabilities meet or exceed requirements, then selects the best fit (highest score, lowest cost, fastest latency). This inverts the naive pattern: instead of "which agent is best?" it asks "which agents meet the bar?"

Capability decay is tracked. Capabilities degrade over time: models drift, tools change, evals become outdated. The registry tracks verification timestamps and decays confidence scores over time. An agent verified 6 months ago gets a lower score than one verified yesterday. This forces continuous re-verification — capability is a lease, not a permanent grant.

Routing decisions are reconstructable. Every routing decision is logged: task requirements, candidate agents, capability scores, trust checks, final selection, and execution outcome. An auditor can reconstruct why a task went to a specific agent and whether the decision was correct. This is the same evidentiary standard as audit trails for agent actions.

The outcome

The build answers the three questions a production multi-agent router must answer and a naive system cannot: what can each agent actually do (verified, not claimed), which agents meet this task's requirements (requirement-driven matching), and why was this agent selected (reconstructable decision trail). Capabilities are verified by evals. Trust boundaries are enforced. Routing is requirement-driven. And decisions are auditable.

The honest caveat: this is a reference build demonstrating the capability-routing pattern, not a production orchestrator with hundreds of agents. There are no benchmarks for routing latency at scale or capability-matching algorithms beyond simple threshold queries, because the point of the build is the architecture — that agent routing is capability-based with verified claims and trust boundaries — not a performance certification. A load test would tell you throughput; the pattern tells you whether routing is grounded in verified capabilities.

Reference implementation

The pattern is instantiated as a runnable Python reference implementation — a capability registry with verified claims, trust boundary enforcement, requirement-driven routing, and decision audit trail. The registry stores agent capabilities with verification evidence (eval scores, timestamps); the router matches task requirements to verified capabilities; trust boundaries are enforced at routing time; and all decisions are logged for audit.

The implementation includes five self-checking scenarios: capability registration with verification, requirement-driven routing, trust boundary enforcement, capability decay over time, and audit trail reconstruction. A demo script drives tasks through the router and prints the capability matches, trust checks, and decision trail.

The full source — capability registry, trust boundary manager, requirement router, audit logger — is public at github.com/Dhristhi/agent-verified-routing, under the Apache-2.0 license.

What you can run

git clone https://github.com/Dhristhi/agent-verified-routing
cd agent-verified-routing
uv sync --extra dev
uv run pytest -q
uv run python scripts/scenario_1_capability_registration.py
uv run python scripts/scenario_2_requirement_routing.py
uv run python scripts/scenario_3_trust_boundaries.py
uv run python scripts/scenario_4_capability_decay.py
uv run python scripts/scenario_5_audit_trail.py