Protocol & Interoperability

• MCP servers and clients for tools, resources and prompts
• A2A agent cards, task lifecycle and artifacts for agent-to-agent work
• OpenAPI and AsyncAPI contracts for conventional services and events
• Registries: which agents, tools and skills exist, at which version, owned by whom
• Version and deprecation policy across protocol revisions
• Supply-chain scanning of third-party servers and skills

Accountable owner

Enterprise Architecture, with Platform Engineering

• Chief or enterprise architect — accountable owner
• Integration architect — boundary contracts and versioning
• API product manager — registry, lifecycle, deprecation
• Security architect — supply chain and protocol threat model

Ownership and phase are architectural recommendations, not assessed results.

Adopt MCP in the pilot to avoid rewriting integrations later. A2A federation and a shared agent registry are the phase 3 workstream, once more than one team runs agents that must delegate to each other.

Signals to watch

• Share of integrations on standard contracts rather than bespoke glue
• Schema-break incidents per quarter
• Registry coverage against deployed reality
• Scan findings on third-party servers and skills, and time to remediate

Adapters and schemas may evolve with compatibility tests. Preserve identities, exact payload meaning and target-bound authorization.

Failure modes

1. Tool poisoning, rug-pulls and tool shadowing from third-party servers
2. Version skew as the MCP stateless core lands and deprecated features are removed
3. Registry sprawl: nobody knows how many agents exist
4. Insecure inter-agent communication (OWASP ASI07) once A2A is in play

Existing tool and standards snapshot · approximately mid-2026. Examples, not required dependencies; verify current versions before adoption.

Frameworks turn over every few quarters; protocols outlive them. Being protocol-centric rather than framework-centric is the single decision that most reduces future rework.