Agent Interoperability & Registry Strategy

Tier: Advanced · Hands-on time: ~30 minutes

Be honest about the epistemics here: this is judgment under churn, and the playbook marks it as such. The signal that a standardization phase has begun is real — MCP's donation to the Linux Foundation's Agentic AI Foundation in December 2025, with AWS, Google, Microsoft, and OpenAI backing, consolidated the tool-integration layer — but agent-to-agent protocols and registry practice remain younger and less settled, and the research behind this track flags registry practice specifically as inference rather than established evidence. The architect's deliverable is therefore a bet log, not a standards decree.

When to use

• Multiple teams are building agents independently and duplication, unknown capabilities, and ad hoc integrations are appearing.
• An enterprise-architecture review asks for the org's agent standards stanceprotocols, discovery, versioning.
• A vendor is pitching an agent platform whose value depends on its ecosystem and you need to price the standards bet inside it.
• Skip AI when the org has one or two agents and one team — write down "revisit at five agents or two teams" and defer; premature registry governance is process without a problem.

Prerequisites

• An inventory of current and planned agentsowner, capabilities, tools consumed, runtime.
• The MCP registry landscape and A2A-class protocol documentation open for verification — this material changes quarterly.
• Your existing service-catalog practice (Backstage-class or equivalent) as the pattern to extend rather than duplicate.
• A chat assistant for option mapping and bet stress-testing.

The workflow

1. 1.

   Separate the three layers being conflated. Tool integration (agent → system): MCP, effectively settled. Agent-to-agent interaction (agent → agent): A2A-class protocols, promising but young. Discovery and governance (humans and agents finding agents): internal registries and catalogs, where practice is still forming. Assign each layer its own stance and confidence level — collapsing them into one "agent standards" decision is how orgs over-commit on the shakiest layer.

2. 2.

   Standardize hard where the ground is firm. For tool integration, the Linux Foundation governance and hyperscaler backing justify a firm internal rule: new tool integrations are MCP servers with owners and versions (pb-37's design). This is the layer where being prescriptive pays.

3. 3.

   Place a hedged bet on agent-to-agent. Options: adopt an A2A-class protocol now (early-mover integration cost, ecosystem upside), wrap agent interactions behind your own thin internal contract that could delegate to a standard later (the classic hedge), or defer and let point-to-point integrations accrue (cheap now, expensive at scale). For most orgs the wrap-and-hedge is the defensible middle; whatever you choose, record it as a bet with a review date, not a conviction.

4. 4.

   Design the registry as an extension of what exists. An agent registry entry: capability description, owner, tier ceiling (from pb-38), tool dependencies, protocol surfaces, version, and lifecycle state. Extend your existing service catalog rather than standing up a parallel system — a registry nobody maintains is worse than none, so the design must name the maintenance forcing function (registration required to get gateway credentials is the effective one).

5. 5.

   Version capabilities, not just code. Agents change behavior without changing APIs — a model upgrade or prompt change can alter what an agent reliably does. Define what constitutes a capability-breaking change (contract change, tier change, quality regression past eval thresholds per pb-33/pb-46) and how consumers of an agent are told.

6. 6.

   Stress-test the strategy against churn scenarios. Vikram, setting the BFSI stance for his ARB:

   Copy

   Stress-test this agent interoperability strategy against standards churn.
   
   Strategy (attached): MCP mandatory for tool integration; agent-to-agent
   wrapped behind an internal contract with A2A adoption deferred to a
   6-month review; registry as Backstage extension, registration enforced
   via gateway credential issuance.
   
   Play out four scenarios over 24 months:
   1. The A2A-class protocol we deferred becomes the clear winner and our
      wrapper diverges from it — what is the convergence cost?
   2. A major platform we use ships a proprietary agent-discovery
      mechanism with real ecosystem pull — do we follow or hold?
   3. MCP itself evolves a breaking spec revision — what in our estate
      is exposed?
   4. Our registry decays because the forcing function is bypassed —
      what breaks first and how would we detect decay early?
   For each: leading indicators to watch, the decision we'd face, and
   what in today's design makes that future decision cheaper.
   

   Fold the leading indicators into the review-date agenda — that list is what makes the quarterly revisit substantive.

7. 7.

   Write the stance memo. One page per layer: the bet, its confidence level, what would change it, and the review date. Label the inferential parts plainly — "registry practice is our synthesis, not settled industry practice" — because a stance memo that admits uncertainty survives contact with the future better than one that fakes confidence.

Verify before you trust it

• Protocol status is checked at the source, this week. Governance claims, spec versions, and backer lists for MCP and any A2A-class protocol come from the foundations' and projects' own pages — this is the fastest-churning claim surface in the track, and AI-recalled status is reliably out of date.
• Ecosystem claims are treated as marketing until counted. "Broad adoption" of any protocol gets verified against something countable — released SDKs, named production users — not vendor keynote assertions or secondary statistics.
• The wrapper hedge is tested for thinness. Review the internal agent-interaction contract against the A2A-class protocol's current shape: could a delegation layer be written in weeks? If the answer is months, the hedge has silently become a fork.
• The registry forcing function actually forces. Attempt to stand up a test agent without registering; if credentials flow anyway, the registry is already decorative.
• Every stance has a review date on a calendar. A bet without a scheduled revisit is a decision pretending to be permanent — confirm the dates exist in the ARB's actual calendar, not just the memo.

Restricted-environment variant

Standards stances are org-internal and client-safe to develop in any approved assistant — no client data is involved in protocol strategy. The client dimension appears in delivery: engagements may impose the client's own registry, protocol stack, or approved-platform list, which your stance memo should treat as a per-engagement overlay rather than a contradiction. For consultancies, maintain the house stance and record client deviations per engagement; where client rules prohibit external tools entirely, the scenario stress-testing runs fine against a local Ollama-served model, since the exercise needs judgment and public documentation, not data.