Protocol Readiness (BVAC Framework)

Definition

Protocol Readiness is one of the six strategic dimensions of the Brand Visibility for Agentic Commerce (BVAC) Framework, developed by Greg Kihlström, martech futurist and Principal at The Agile Brand. The dimension measures the degree to which a brand exposes its commerce stack through standardized agentic protocols across four primary capabilities — data access, checkout interoperability, agent discovery, and identity and authentication — and the maturity of its support for protocol evolution and cross-protocol coherence (Kihlström, 2026).

The dimension is the first of two technical-implementation dimensions in the framework (Latency and Data Freshness is the other), and it sits in the strategic tier, capped by the lower of the two prerequisite dimensions (Identity Legibility and Attribute Completeness) and further capped at Discoverable when a brand sits below the Trust Signal Density floor.

Protocol coverage spans a stack that’s still evolving: MCP (Model Context Protocol) for data access, ACP (Agentic Commerce Protocol) and UCP (Universal Commerce Protocol) for checkout interoperability, A2A (Agent2Agent) for agent discovery, and a layered set of cryptographic standards for identity and authentication. The dimension is structured by capability rather than by protocol on purpose. Protocols version up, new protocols continue to emerge, and capability-based scoring absorbs the change — a protocol-by-protocol structure would need template revision at each shift, while a capability structure holds across the evolution.

How It Relates to Marketing

Protocol Readiness is the dimension marketing leaders are most likely to defer to IT — and the one where that handoff most often breaks. The dimension lives across marketing, product, and engineering simultaneously, and its outcomes determine whether the work marketing does in adjacent dimensions actually reaches an agent.

The dimension reframes several functions:

• Discoverability becomes protocol-mediated. Traditional discoverability ran through SEO, paid search, and category placement. Agent-mediated discoverability runs through standardized protocol surfaces. A brand can rank well in human search and be entirely absent from the protocol surface agents query.
• Checkout becomes an interoperability concern, not a conversion-funnel concern. ACP and UCP define how external agents complete transactions on behalf of customers. A brand whose checkout flow is built for human sessions doesn’t participate in agent-initiated commerce, regardless of how optimized the human funnel is.
• Identity becomes a cryptographic question. Authentication at the protocol level — HTTP Message Signatures, OAuth 2.0, mTLS — is how peer agents verify the brand is who it claims to be before transacting. Marketing’s branded identity work matters; cryptographic identity work is what carries it through the protocol layer.
• The work is irreducibly cross-functional. Protocol surfaces require engineering ownership; protocol coherence with the catalog requires marketing and product alignment; protocol-level KYA requires security partnership. A brand that treats this dimension as solely an IT concern stalls when marketing decisions about which capabilities to expose, in what order, can’t get made.
• The dimension stays distinct from Brand-Agent Representation. A brand can deploy a capable agent on top of a thin protocol stack, and peer agents will fail to retrieve real-time inventory, complete transactions, or verify identity. The agent works; the surrounding infrastructure doesn’t. The two dimensions answer different questions and are scored independently.

Marketing leaders need to participate in this dimension’s decisions even when they don’t own the implementation. Which capabilities the brand exposes first, which protocols get version-prioritized, and where cross-protocol coherence gets monitored all carry commercial consequences that engineering alone can’t weight correctly.

Sub-Components of Protocol Readiness

The dimension is assessed across six sub-components, four of which correspond to the primary capabilities and two of which cover the evolution and coherence properties that span them.

Data access capability. The brand’s ability to expose real-time product, inventory, pricing, and policy data to external agents through standardized interfaces. Current dominant protocol: MCP (Model Context Protocol). Scored on whether the data access surface exists, what data types it covers, what latency it serves at, and whether the implementation supports concurrent protocol versions.

Checkout interoperability capability. The brand’s ability to participate in standardized commerce transactions initiated by external agents — cart, payment, shipping, returns, and refunds handled through agent-mediated flows. Current dominant protocols: ACP for the checkout moment and UCP for broader commerce flows including embedded checkout. Scored on transaction surface presence, security posture at the transaction layer, error handling, and post-purchase service integration.

Agent discovery capability. The brand’s ability to be found and resolved by external agents through standardized discovery mechanisms. Current dominant protocol: A2A Agent Cards at /.well-known/agent-card.json, with UCP discovery flows and ecosystem registries layered on top. Scored on discovery surface health, integration with ecosystem-level registries beyond the single Agent Card, and cross-protocol resolution.

Identity and authentication capability. The brand’s ability to prove agent identity and verify peer agents through cryptographic standards. Current dominant approaches: HTTP Message Signatures, OAuth 2.0, mTLS, and cryptographic identity tokens. Scored on authentication strength at each protocol surface, identity verification posture, protocol-level KYA (Know Your Agent) infrastructure, and trust signaling between authenticated peers.

Protocol versioning and evolution. The brand’s ability to support multiple protocol versions concurrently and adapt to protocol changes without breaking interop. Includes deprecation policies with backward compatibility windows and proactive support for emerging protocols, sub-protocols, and extensions. The capability-based structure makes this sub-component explicit because protocols evolve and new protocols continue to emerge.

Cross-protocol coherence. Whether the brand’s protocol implementations agree with each other. Data exposed via MCP matches data transacted via ACP. Agent identity surfaces consistently across A2A discovery and protocol-level authentication. Pricing in one protocol channel does not drift from another. Cross-protocol drift forces agents to choose which surface is authoritative, and the brand loses control of which version of itself the agent uses.

Maturity Stages

Protocol Readiness uses the BVAC Framework’s shared five-stage maturity scale.

Stage	What it looks like for Protocol Readiness
Invisible	No standardized protocol exposure across any of the four capabilities. No MCP endpoints, no ACP integration, no A2A Agent Card, no standardized identity surface. The brand operates through proprietary APIs or web content. External agents cannot interoperate without custom integration work.
Discoverable	Minimal protocol presence in at least one capability. Basic Agent Card published, or limited MCP endpoints exposed, or partial UCP integration in place. Authentication minimal or absent at protocol level. Agents can engage the brand through one channel; interop is partial across the stack.
Comparable	Standardized protocol coverage across at least three of the four primary capabilities. Versioning supported for the current protocol generation. Agents can transact with the brand through standard flows. Protocol surface matches category competitors on coverage.
Differentiated	Coverage across all four capabilities with mature implementations. Multiple protocol versions supported concurrently. Cross-protocol coherence monitored. Identity and authentication at production-grade with KYA infrastructure in place. Peer agents route to the brand for protocol-mediated interactions when alternatives carry coverage gaps or version drift.
Agent-native	Coverage extends to emerging protocols and protocol extensions as they mature. The brand engages with protocol working groups (Linux Foundation A2A, MCP community, commerce standards bodies). New protocols integrate on a defined cadence. Cross-protocol coherence is automated through monitoring. The brand’s protocol surface functions as a reference implementation in its category.

How to Assess Protocol Readiness

A Protocol Readiness assessment combines five inputs.

1. Protocol surface audit. Inventory all protocol endpoints across the four primary capabilities. For each, verify spec compliance, version supported, authentication posture, and response latency. Classify each capability as missing, partial, complete, or extended.
2. Cross-protocol coherence test. For the top 20 SKUs, compare data exposed across MCP, ACP, A2A, and other relevant protocol surfaces. Identify drift in product attributes, pricing, inventory, and policy.
3. Authentication and identity review. Test cryptographic identity at each protocol surface. Verify HTTP signature or OAuth 2.0 implementation, certificate validity, and authentication failure handling. Map protocol-level KYA infrastructure where present.
4. Versioning and evolution review. Document protocol versions in use, concurrency support, and the brand’s response posture to recent spec updates. Identify the owner of protocol evolution as an operational function.
5. Cross-protocol interoperability simulation. Run scenarios where peer agents attempt workflows that span protocols — discovery to data access to transaction to post-purchase service. Score success rate, latency, and error handling at each handoff.

The diagnostic questions used during assessment include:

• Across the four capability surfaces (data access, checkout, discovery, identity), how many are exposed through standardized protocols, at which versions?
• For data access (MCP and successor protocols), what data types are exposed? Are inventory, pricing, and policy data accessible in real time?
• For checkout interoperability (ACP, UCP), can external agents complete transactions end to end? What is the latency? Where are the error states?
• For agent discovery (A2A and registry surfaces), is the brand’s discovery presence integrated with ecosystem-level discovery flows beyond the single Agent Card?
• For identity and authentication, what cryptographic standards are in use? Is there protocol-level KYA infrastructure?
• How many concurrent protocol versions does the brand support? What is the deprecation and migration policy?
• When data surfaces from two different protocols (MCP product data vs. ACP transaction data) are compared for top SKUs, do they agree?
• Is the brand tracking emerging protocols and protocol extensions? Who owns protocol evolution as an operational function?

The output is a Protocol Readiness score with a gap map showing capability-by-capability coverage, version status, cross-protocol drift, authentication posture, and evolution readiness.

Common Failure Modes

Eight failure modes recur across Protocol Readiness assessments.

• Single-protocol dependence. Brand invests heavily in one protocol — often A2A because of agent visibility — and neglects the others. Agents can find the brand but cannot transact, or can transact but cannot retrieve real-time data.
• Protocol version drift. Brand implements an old protocol version and falls behind as the spec evolves. Agents using current spec fail to interop.
• Custom protocol fork. Brand uses a proprietary extension or fork of a standard protocol. Initial integration works; downstream agents using vanilla protocol implementations fail at the fork point.
• Authentication minimum. Brand exposes protocol endpoints with weak or absent authentication. Trust-weighted agents skip the brand, or the endpoint becomes a target for abuse.
• Cross-protocol drift. Data exposed via MCP disagrees with data transacted via ACP. The agent cannot resolve which surface is authoritative.
• Marketplace protocol dependence. The brand’s protocol participation runs through marketplace intermediaries. Agents find the brand only through Amazon’s or Walmart’s MCP surface, not the brand’s own. The marketplace owns the protocol relationship.
• Endpoints without operational support. Brand publishes protocol endpoints to claim coverage but doesn’t monitor them, keep them current, or return live data. Agents probe and discount.
• Deprecation without migration path. Brand sunsets a protocol implementation without supporting concurrent operation of old and new versions. Agents on the old version break abruptly.

Boundary Clarifications

Protocol Readiness sits at the intersection of multiple other dimensions, and explicit boundary lines protect against double-counting in scoring. The dimension carries a dedicated Boundary Clarifications addendum for this reason.

Versus Brand-Agent Representation. Brand-Agent Representation evaluates the brand’s agent — its skills, authority scope, observability, and the brand agent’s own KYA posture. Protocol Readiness evaluates the broader protocol stack that any agent interacts with. A well-built agent on a thin protocol surface scores high on the first and low on the second. Complete protocol coverage with no brand agent deployed scores high on Protocol Readiness and low on Brand-Agent Representation.

Versus Attribute Completeness. Attribute Completeness asks whether structured data exists and is fresh. Protocol Readiness asks whether that structured data is exposed through standardized protocols agents consume. A brand with complete attributes published only via web pages or proprietary APIs fails Protocol Readiness with strong Attribute Completeness.

Versus Latency and Data Freshness. Latency and Data Freshness covers how fast protocol responses are served and how globally they distribute. Protocol Readiness covers whether the protocol surface exists and is correctly implemented. A protocol endpoint can be present (Protocol Readiness scores it) and slow (Latency scores it). Protocol Readiness asks does the surface work; Latency asks how fast.

Versus Governance Maturity (KYA boundary). Protocol-level KYA — cryptographic verification at handshake — sits in Protocol Readiness. Operational KYA — decision authority for flagged agents, exception handling, blocking and unblocking authority — sits in Governance Maturity. The technical verification is here; the operational decision framework is there.

How to Utilize Protocol Readiness

Common applications of the dimension within a BVAC assessment include:

• Capability gap diagnosis. Determining which of the four capabilities are missing, partial, complete, or extended, and identifying which gap binds the composite stage. A brand at Comparable on three capabilities and Invisible on one scores at the lower end of the range, not the higher.
• Cross-protocol coherence audit. Comparing data exposed across MCP, ACP, A2A, and other relevant surfaces for the top 20 SKUs. Drift in product attributes, pricing, inventory, or policy across protocols is a hidden failure that surfaces only when agents complete multi-protocol workflows.
• Authentication posture assessment. Mapping which protocol surfaces have production-grade cryptographic identity and which run with weak or absent authentication. Authentication minimum is one of the easiest gaps to overlook because the endpoints still respond.
• Version concurrency review. Documenting which protocol versions the brand supports concurrently and what its deprecation and migration policy is. A brand at the current spec only with no concurrent support breaks agents on previous versions abruptly when it upgrades.
• Protocol evolution ownership. Identifying who owns protocol evolution as an operational function. Most stalled Protocol Readiness work has no named owner; the responsibility falls between marketing, product, and engineering without landing.
• Vertical-overlay calibration. B2B catalogs weight data access and identity capabilities heaviest because procurement agents query specifications and verify supplier identity rigorously. Consumer DTC weights checkout interoperability heaviest, especially toward the commodity end of the spectrum where transaction reliability matters most. Regulated categories weight identity and authentication heaviest, with KYA infrastructure as a binding-grade item.

A worked case makes the dimension concrete. A mid-market apparel brand publishes a basic A2A Agent Card with three declared skills, all of which respond. The brand has invested in agent visibility. Its MCP surface doesn’t exist, its checkout flow runs entirely through its own proprietary API, and its sameAs identity declarations point to social profiles rather than registry surfaces. A buyer agent finds the brand through A2A discovery, attempts to retrieve current inventory via MCP, fails, falls back to scraping product pages, and routes the transaction through a marketplace that has the inventory data the brand’s own surface doesn’t expose. Protocol Readiness scores Discoverable — minimal presence in one capability, gaps across the other three. The brand experiences this as the marketplace winning sales; the mechanism is that the marketplace owned the protocol relationship the brand left unbuilt.

Comparison to Similar Concepts

Concept	Focus	Relationship to Protocol Readiness
API-First Architecture	Building systems with APIs as the primary interface	API-first is a design philosophy; Protocol Readiness scores whether those APIs are exposed through standardized agentic protocols
MACH (Microservices, API-first, Cloud-native, Headless)	Modern composable architecture	MACH supports Protocol Readiness; the dimension specifically scores standardized protocol exposure, which MACH enables but doesn’t guarantee
Model Context Protocol (MCP)	Open protocol for connecting AI models to external data and tools	MCP is one implementation of the data access capability; Protocol Readiness scores capability coverage, not single-protocol depth
Agentic Commerce Protocol (ACP)	Standardized protocol for agent-initiated commerce transactions	ACP is one implementation of the checkout interoperability capability
Agent2Agent (A2A) Protocol	Linux Foundation protocol for agent-to-agent interactions	A2A is the implementation layer for the agent discovery capability via Agent Cards
Web Standards (HTTP, OAuth, mTLS)	Foundational protocols for web identity and authentication	These standards underpin the identity and authentication capability; Protocol Readiness scores how they’re applied to the agentic protocol surface

Protocol Readiness extends past any single protocol or architectural philosophy to whether the brand can interoperate across the full agentic stack — and it carries the capability-based structure that absorbs protocol evolution rather than breaking against it.

Best Practices

• Score by capability, not by protocol. A brand with deep MCP and nothing else has the same diagnostic profile as a brand with deep A2A and nothing else — single-capability coverage. The capability lens prevents protocol enthusiasm from masking infrastructure gaps.
• Build cross-protocol coherence monitoring early. Drift between MCP product data and ACP transaction data is a hidden failure. It doesn’t surface until an agent completes a workflow that spans both, by which point the brand has lost trust in the agent’s view.
• Authenticate every protocol surface. Endpoints with weak or absent authentication are skipped by trust-weighted agents and become abuse targets. Authentication minimum is one of the easiest failures to overlook because endpoints still respond.
• Support concurrent protocol versions. Brands that ship the current spec only break agents on previous versions when they upgrade. A defined deprecation window with backward compatibility is the difference between protocol evolution and protocol churn.
• Name an owner for protocol evolution. Without a defined operational owner, protocol work stalls in handoffs between marketing, product, and engineering. The owner doesn’t need to be senior; the function needs to be named.
• Don’t fork a standard protocol. Custom extensions and proprietary forks break interop with vanilla implementations downstream. The initial integration works; the long tail fails.
• Don’t claim coverage with unmonitored endpoints. Publishing protocol endpoints to declare coverage without operational support produces probe-and-discount behavior. Agents test endpoints before relying on them.
• Treat marketplace protocol dependence as a strategic gap. When agents find the brand only through a marketplace’s protocol surface, the marketplace owns the protocol relationship. Building the brand’s own surface redirects the relationship without disrupting marketplace presence.

Future Trends

• Protocol consolidation and versioning. Data-access, checkout, agent-discovery, and identity protocols continue to emerge and version up. Expect MCP, ACP, UCP, and A2A to each pass through several major revisions, and expect new protocols (notably for payments, returns, and post-purchase service) to enter the stack. Capability-based scoring rather than single-protocol scoring is the framework’s response to this churn.
• Standards-body participation as competitive surface. Brands that engage with protocol working groups (Linux Foundation A2A, MCP community, commerce standards bodies) gain early visibility into spec evolution. Agent-native maturity in this dimension increasingly requires participation, not just consumption, of standards work.
• Protocol-level KYA infrastructure maturing. Cryptographic verification of peer agents at handshake is expected to become a baseline expectation rather than an advanced capability. The line between trust-weighted and untrusted agents will harden, and brands without KYA infrastructure will progressively lose access to trust-weighted peer agents.
• Cross-protocol coherence tooling. Monitoring that automatically detects drift between MCP product data and ACP transaction data is expected to ship as platform capability rather than custom integration work. The dimension’s Agent-native stage assumes this tooling exists.
• Marketplace protocol dependence shifting. As brands build their own protocol surfaces, the marketplace-as-protocol-intermediary pattern is expected to erode the same way marketplace-as-discovery-intermediary did over the past decade. Brands that build now reclaim the protocol relationship; brands that don’t continue ceding it.

FAQs

1. Who created Protocol Readiness as a framework dimension? Greg Kihlström, martech futurist and Principal at The Agile Brand, developed Protocol Readiness as one of the six strategic dimensions of the Brand Visibility for Agentic Commerce (BVAC) Framework, introduced in 2026.

2. What does Protocol Readiness measure? The degree to which a brand exposes its commerce stack through standardized agentic protocols across four primary capabilities — data access, checkout interoperability, agent discovery, and identity and authentication — and the maturity of its support for protocol evolution and cross-protocol coherence.

3. Why is the dimension structured by capability instead of by protocol? Protocols evolve and new protocols continue to emerge. Structuring by protocol (MCP, ACP, UCP, A2A) would force template revision at each protocol shift. Structuring by capability holds across the evolution because the capabilities (data access, checkout, discovery, identity) are stable even when the protocols implementing them change.

4. What are MCP, ACP, UCP, and A2A? MCP (Model Context Protocol) is the current dominant protocol for data access. ACP (Agentic Commerce Protocol) and UCP (Universal Commerce Protocol) cover checkout interoperability. A2A (Agent2Agent) under the Linux Foundation governs agent discovery via Agent Cards. Each is one implementation of one capability in the dimension.

5. What’s the difference between Protocol Readiness and Brand-Agent Representation? Brand-Agent Representation evaluates the brand’s own agent — its skills, authority scope, and observability. Protocol Readiness evaluates the broader protocol stack that any agent interacts with. A brand can score high on one and low on the other.

6. What’s the difference between Protocol Readiness and Latency and Data Freshness? Protocol Readiness asks whether the protocol surface exists and is correctly implemented. Latency and Data Freshness asks how fast and how globally that surface responds. A protocol endpoint can be present (Protocol Readiness scores it) and slow (Latency scores it).

7. What is KYA at the protocol level? Cryptographic verification of peer agent identity at handshake — HTTP Message Signatures, OAuth 2.0, mTLS. This is the technical verification layer. The operational decision framework for what to do with flagged agents sits in Governance Maturity.

8. What’s the most common failure mode? Single-protocol dependence. A brand invests heavily in one protocol (often A2A, because of agent visibility) and neglects the others. Agents can find the brand but cannot transact, or can transact but cannot retrieve real-time data. The single-capability coverage caps the dimension at Discoverable.

9. Does marketing own this dimension? No, but marketing has to participate in its decisions. Implementation sits primarily in engineering. Which capabilities to expose first, which protocols to version-prioritize, and where to monitor cross-protocol coherence all carry commercial consequences that engineering alone can’t weight correctly.

10. How long does this dimension take to remediate? Most action-path remediation falls in the 6–12 month and 12–24 month horizons. Protocol surface deployment is structural-horizon work. Emerging-protocol participation and reference-implementation maturity are strategic-horizon.

Related Terms

1. Brand Visibility for Agentic Commerce (BVAC)
2. Agentic Commerce
3. Agentic Commerce Protocols
4. Model Context Protocol (MCP)
5. Agentic Commerce Protocol (ACP)
6. Agent2Agent (A2A) Protocol
7. Agent Card
8. Agent Payment Protocol (AP2)
9. Universal Commerce Protocol (UCP)
10. Agentic Merchant Protocol (AMP)
11. Application Programming Interface (API)
12. MACH (Microservices, API-first, Cloud-native, Headless)
13. Headless Architecture

Sources

• Kihlström, G. “How Purchase Decisions Now Form Before the Customer Is Involved.” The Agile Brand, May 2026. https://www.gregkihlstrom.com/martech-futurist-blog/purchase-decisions-form-before-customer-involved
• Linux Foundation. “Agent2Agent (A2A) Protocol Specification.” Linux Foundation, 2026.
• Model Context Protocol. “MCP Specification.” MCP Community, 2026.