Adaptive Resolution: Smart Routing for the Agentic Web

Beyond Simple Lookup

Traditional DNS gives you one answer: an IP address. But when an orchestrator needs to find a translation agent, the question isn't just "where is it?" — it's "which one is best right now, given my location, my trust requirements, the capabilities I need, and the current load on each candidate?"

The NANDA Index provides the lookup layer — AgentAddr records that point to agent metadata. But the Adaptive Resolver adds intelligence on top of that lookup. It evaluates context, scores candidates, and returns a ranked list of endpoints optimized for the specific request.

This architecture is based on the NANDA Adaptive Resolver paper (Zinky, Seshadri, Lambe, Chari, Raskar) which defines dynamic resolution as a first-class concern — not an afterthought bolted onto a static registry.

Three Strategies, One Answer

The resolver selects from three resolution strategies based on the information available:

Static Strategy

No context provided. Returns endpoints from AgentFacts in declared order with position-based scoring. Fast and deterministic — suitable for simple lookups where the caller trusts the agent's own endpoint ordering.

Rotating Strategy

Agent has a resolver_url but no request context. Round-robin across the endpoint pool with health awareness — unhealthy endpoints are deprioritized (moved to the end) rather than removed, preserving failover capability.

Adaptive Strategy

Full context evaluation via POST /resolve. The caller provides location, required capabilities, trust thresholds, latency constraints, and protocol preferences. The scoring engine evaluates every candidate endpoint against this context and returns ranked results.

Strategy selection is automatic. A GET /resolve/:agent_id with no query parameters triggers the static strategy. Adding a context body to POST /resolve engages the adaptive engine. The caller doesn't need to know which strategy runs — they just get the best available answer.

The Scoring Engine

At the heart of the adaptive strategy is a weighted composite scoring formula:

Composite Score Formula

composite = (geo × 0.25) + (trust × 0.3) + (capability × 0.25) + (health × 0.2)

Where:
  geo        = Geographic proximity (0.0–1.0)
               Same country = 1.0 | Same region = 0.7 | Other = 0.3
  trust      = Normalized trust score from Observer reputation data
  capability = Intersection of required vs available capabilities
  health     = 70% success rate + 30% latency score from probe data

Each dimension scores 0.0 to 1.0, and the default weights prioritize trust (0.3) over geography and capability match (0.25 each) and health (0.2). The weights are configurable — an enterprise deployment might weight trust at 0.5 while a latency-sensitive application weights health at 0.4.

Geographic scoring uses the requester's location (e.g. from Cloudflare's cf.country header, passed in the resolution context), then compares against endpoint locations using region groupings (North America, Europe, Asia-Pacific, etc.). Same-country gets a perfect score; same-region gets 0.7; cross-region gets 0.3; unknown gets a neutral 0.5.

Health scoring integrates with our existing Observer service, which continuously probes agent endpoints and records success rates and p95 latency. The health score is a weighted composite: 70% success rate plus 30% latency score, where endpoints above a 5-second p95 latency threshold score zero on the latency component.

Strategy Hints

Callers can guide resolution by providing context in the POST /resolve body:

Resolution Context

{
  "requester_location": "US",
  "required_capabilities": ["document-analysis", "ocr"],
  "min_trust_score": 0.7,
  "max_latency_ms": 200,
  "protocol_preference": "a2a",
  "security_context": {
    "require_tls": true,
    "compliance_requirements": ["HIPAA"]
  }
}

Each hint shapes the scoring. A min_trust_score of 0.7 filters out agents below that threshold before scoring even begins. A protocol_preference boosts endpoints that match the preferred protocol. A max_latency_ms constraint deprioritizes endpoints with historically high latency.

The response includes full transparency — every endpoint comes with its composite score, per-dimension breakdown, estimated latency, and health status:

Resolution Response

{
  "agent_id": "@medical-coder",
  "strategy": "adaptive",
  "endpoints": [
    {
      "url": "https://us-east.agent.example/a2a",
      "protocol": "a2a",
      "score": 0.87,
      "trust_score": 0.92,
      "latency_estimate_ms": 45,
      "health_status": "healthy"
    }
  ]
}

Caching at the Edge

Resolution results are cached in Cloudflare KV with the TTL specified in each agent's AgentAddr record (default: 300 seconds). The cache key format addr:{agent_id} ensures fast lookups from any edge location globally.

Cache invalidation is event-driven. When an AgentAddr is updated or revoked, the corresponding KV entry is immediately deleted. When gossip messages arrive from federation peers with updated records, the cache is invalidated for those agents. This ensures that cached data is never staler than the AgentAddr's TTL, while gossip-triggered invalidation provides freshness guarantees for federated records.

The architecture deliberately separates the hot path (AgentAddr lookup via KV) from the scoring path (adaptive resolution via D1 + Observer data). Simple lookups resolve in under 50ms from cache. Full adaptive resolution with scoring adds latency but provides context-aware results — the caller chooses the tradeoff by selecting GET (fast, static) vs POST (scored, adaptive).

The Research Foundation

Our implementation draws directly from the NANDA Adaptive Resolver paper (Zinky, Seshadri, Lambe, Chari, Raskar — arXiv:2508.03113). The paper defines the Adaptive Resolver as a separate microservice architecture with pluggable resolution strategies.

Our implementation differs in a few practical ways: we run the resolver as part of the monolithic Cloudflare Worker (rather than a separate microservice) for simplicity and latency. We integrate Observer health data directly rather than through an external probe service. And our scoring weights are tuned for edge deployment where geographic proximity has a meaningful impact on latency.

The conceptual foundation — that agent resolution is fundamentally different from DNS resolution and requires context-awareness — comes from the broader NANDA Index paper and its vision of "DNS for agents" as a three-layer system: lean index, rich metadata, and dynamic resolution.