Candidate set
Supported capability path
Resolve first narrows the route to providers mapped to the requested capability. That is the candidate filter; it is not hidden as a generic quality score.
How Rhumb Resolve routes calls: Index ranks services with AN Score. Resolve routes supported calls by first matching the supported capability path, then using AN Score, provider availability / circuit state, estimated cost, credential mode, latency proxy, and explicit policy constraints. Agents can also explicitly pin the supported provider or tool path when direct control is better.
Routing proof surface
Resolve routes for the task, not the leaderboard.
Index ranks the field. Resolve routes the call. AN Score is a major quality prior, but the final route depends on which providers support the requested capability path, which provider routes are available, what the estimated cost is, what credentials are available, and what constraints the operator set.
The agent gets both modes: say what you want done and let Resolve choose, or pin directly when control is better. Agents can also pin the supported provider path explicitly when they want direct control.
Quality prior
AN Score
The public score is the starting signal. It tells Resolve which services are broadly agent-compatible, but it does not force every call to follow the global leaderboard.
Runtime condition
Availability / circuit state
The route explanation exposes availability as the provider circuit state. Today the latency factor is also derived from that circuit state until richer runtime telemetry is used.
Price signal
Estimated cost
Candidate routes carry estimated cost, and a max-cost policy can make an otherwise valid provider ineligible before execution.
Credential boundary
Credential mode
The route reflects whether the supported provider path can run through Rhumb-managed credentials, BYOK, or Agent Vault for the requested call.
Operator control
Explicit policy constraints
Pins, allow lists, deny lists, cost ceilings, and explicit provider choice shape the honest route. If a policy changes the answer, the explanation should say so.
Route explanation
What a route needs to explain
A useful routing explanation should not just name a provider. It should show the selected path, material factors, policy checks, credential boundary, and whether the agent chose the provider explicitly or asked Resolve to choose. The current public explanation shape is the one produced by the v2 RouteExplanation runtime.
Example route-explanation fields
Explainablecapability_id
winner.provider_id
winner.selection_reason
candidates[].factors
candidates[].factors.an_score
candidates[].factors.availability
candidates[].factors.estimated_cost
candidates[].factors.latency
candidates[].factors.credential_mode
candidates[].policy_checks
candidates[].ineligible_reason
policy_active
strategy
Examples
Three ways supported routing changes the answer
Search company context
Best-fit default: Resolve can choose among providers mapped to the web-search capability using AN Score, availability / circuit state, estimated cost, credential mode, and policy constraints — not raw leaderboard order alone.
Explicit control: If your agent needs a specific provider, it can pin that supported path directly instead of asking Resolve to choose.
Extract structured data
Best-fit default: Resolve can route among supported extraction providers only after they are in the capability candidate set, then explain the runtime factors that affected the selected provider.
Explicit control: If your workflow already standardized on a provider, keep that control and use Rhumb for governed execution, cost checks, and receipts.
Use a private workspace
Best-fit default: Resolve should not pretend Rhumb-managed routing is always right when the job touches your own systems, private data, or compliance boundary.
Explicit control: Use BYOK or Agent Vault so the agent can execute with the provider path and credential boundary you choose.
Neutrality rule
No pay-to-rank. No pretending cost is quality.
AN Score must remain independent quality intelligence. If cost, policy, credential mode, or explicit provider choice changes a route, that belongs in the explanation — not hidden inside the score.
Current boundary
Launchable where the route is real.
Current launchable scope: research, extraction, generation, and narrow enrichment — not general business-agent automation. Not every service or capability in the index is executable through Rhumb today. Discovery breadth is wider than current callable coverage.