ACP, UCP, AP2, MPP, x402, MCP and A2A: Protocol Landscape for Travel

Agentic-commerce protocols should not be treated as one winner-takes-all category. For travel architecture they sit at different layers: tooling, agent coordination, commerce interaction, payment authorization and payment rails.

Layer summary

ACP

ACP defines purchase interaction and checkout interfaces between buyers, agents and businesses. In travel it is not a replacement for NDC or hotel booking APIs; it is better viewed as a commerce/checkout boundary around travel domain flows.

UCP

UCP targets interoperable commerce capabilities. Travel implementations should preserve reprice, availability and booking/ticketing semantics rather than forcing retail-cart assumptions directly onto travel offers.

AP2

AP2 focuses on agent payment authorization and evidence. Travel use cases include delegated limits, human-not-present transactions, verifiable intent and mandate evidence. It is not a booking protocol.

MPP

MPP addresses machine-to-machine payments. Travel examples can include paid supplier APIs, premium data services or machine-billed ancillary capabilities. It does not by itself solve consumer booking lifecycle.

x402

x402 brings programmatic payment to HTTP using 402 semantics. It fits paid APIs, premium resources and machine-commerce scenarios more naturally than core booking state.

MCP

MCP is a useful travel tool abstraction for search, reprice, create/retrieve/cancel and refund operations. It does not define authorization or booking semantics.

A2A

A2A standardizes collaboration among agents. A travel planner, loyalty agent, payment agent and servicing agent can coordinate through it while keeping their own domain responsibilities.

Protocol composition

Agentic travel protocol composition

Mermaid source (.mmd)

Selection criteria

Do not ask only which protocol to choose. Ask which problem layer exists: tool access, agent collaboration, checkout interoperability, delegated authorization or machine-native payment. A production system can use several protocols together.

Travel-specific constraints

Regardless of protocol, preserve offer freshness, reprice, UNKNOWN booking state, idempotency, payment/booking separation, passenger PII boundaries and servicing/reconciliation.

Failure modes

Treating a commerce protocol as the travel booking model, treating MCP invocation as authorization, equating payment success with booking success, version mismatch and losing travel-specific state under generic checkout abstractions.

Observability

Track capability-negotiation failures, version mismatches, protocol-specific error rates, authorization rejection, fallback-path usage and any travel-domain reconciliation triggered by protocol-layer ambiguity.

Production checklist

Maintain protocol-boundary maps, version pinning, capability negotiation, canonical travel models, authorization evidence, idempotent side effects, PII redaction and protocol-specific observability.