Developer Preview · In Development

Protocol Router

Agentic commerce protocols are fragmented. The Protocol Router is a route planning model Autheo is developing so that a developer can describe an intent and receive a recommended protocol path, instead of stitching MCP, A2A, ACP, UCP, AP2, x402, card networks, and blockchain settlement together by hand.

Why a router

A developer building an agent application today must decide which protocol to use for each step of a transaction, stitch checkout, mandate, and settlement protocols together by hand, and re-implement that logic for every merchant. The Protocol Router abstracts that work behind a route planner that takes an intent, identity, merchant, and policy and produces a recommended route.

Protocol taxonomy

The router begins from a taxonomy of what each standard actually does. None of these are equivalent; each addresses a specific job in the seven layer stack.

Route plan inputs

A RoutePlanRequest carries the intent, KYA credential references, merchant target, controller policy, preferences, declared protocol capabilities, and optional context for telemetry.

• intent— the structured intent. Examples: buyProduct, buyApiAccess, subscribe, payForResource, transferValue, negotiate.
• agentCredentialRef, controllerCredentialRef, mandateCredentialRef — KYA credential identifiers the router resolves.
• merchantTarget— a merchant identifier, manifest URL, or selection hint.
• policyConstraints— structured constraints from the controller's policy (limits, allowed routes, jurisdiction, time windows).
• preferences— preferred settlement rail, latency tolerance, cost ceiling, privacy posture.
• protocolCapabilities — optional declaration of which protocols the calling environment can speak.

Route plan outputs

A RoutePlanResponse returns a recommended route, ranked alternatives, ruled out surfaces with reasons, required credentials and proofs, the policy checks that were performed, optional warnings, an expiry, and a stable plan id for telemetry.

Each Route identifies an interface protocol (for example acp.checkoutSession or ucp.universalCart), a payment protocol (for example ap2.mandate), and a settlement rail (for example chain.stablecoin or card.network), along with adapter references, estimated cost and latency, known failure modes, and merchant support confidence.

Decision model

1. Validate inputs. Reject malformed requests.
2. Resolve credentials. Verify signatures, expiry, and revocation status. Return a structured failure on invalid or revoked credentials.
3. Resolve merchant. Fetch the merchant manifest and merchant credential, then compute the set of routes the merchant declares support for.
4. Filter by capability. Intersect merchant supported routes, agent protocol capabilities, and intent specifics.
5. Filter by policy. Apply controller policy constraints and mandate allowlists, blocklists, and limits. Drop routes that violate any constraint.
6. Filter by preferences. Apply soft preferences for ranking only.
7. Rank by policy fit, preference fit, latency, cost, and merchant support confidence.
8. Build the response. Every excluded route appears in unsupportedSurfaces with a reason. The decision model is deliberately explainable.

Adapter interface

Each protocol maps to one or more adapters. The v0.1 adapter interface is read only and exposes four methods:

describeCapabilities() -> AdapterCapabilities
planRouteSegment(intent, agentCreds, controllerCreds, mandateCreds, merchantManifest)
  -> RouteSegmentPlan | NotSupported
listRequiredCredentials(intent, merchantManifest) -> CredentialRequirements
listRequiredProofs(intent, merchantManifest) -> ProofRequirements

Adapter identifiers follow a naming convention such as mcp.toolBridge, a2a.agentCard, acp.checkoutSession, ucp.universalCart, ap2.mandate, x402.http, and chain.stablecoin. Execution methods such as startSession, authorizePayment, and confirmSettlement are reserved for a future version.

Related documents