The week of April 21 produced four agentic framework releases. April 27 added a fifth. OpenAI published Symphony, a Draft v1 open-source specification for Codex orchestration that the company describes as language-agnostic. By the time Symphony appeared, the orchestration space already had Google’s Agent-to-Agent (A2A) protocol, the Anthropic-adjacent Model Context Protocol (MCP), the Agent Communication Protocol (ACP), and at least one additional framework tracked in our agentic AI coverage. Five named protocols in ten days. That’s not convergence. That’s fragmentation building momentum.
What Symphony Is, and What It Isn’t
The confirmed facts about Symphony are specific and narrow. Per a search-retrieved excerpt from openai.com, Symphony is a specification for Codex orchestration. It carries a “language-agnostic” designation. It is at Draft v1, which means it is published for review and open to amendment, not a finished standard. It is open-source.
What isn’t confirmed: Symphony’s scope as a universal multi-agent standard covering cross-architecture communication, shared memory management across different model families, or agent-to-agent negotiation beyond Codex-based systems. Early reporting framed Symphony with broader claims. Those claims aren’t supported by the confirmed excerpt. The spec document may contain them, but until the primary document is reviewed directly, the confirmed scope is Codex orchestration with language-agnostic protocol design.
One claim that circulated, native WebSocket support via OpenAI’s Responses API – could not be independently corroborated before publication. Practitioners reading analyses of Symphony should check whether those analyses are based on the spec document or on a press summary.
Draft v1 is also a governance signal. It means OpenAI is publishing a proposal, not a ratified standard. It means there will be a v2, and someone will decide what goes into it. Whether Symphony operates under genuine community governance or under OpenAI’s editorial control is a question the current document does not answer.
The Four Protocols: What Each One Claims to Solve
Protocol fragmentation is most costly when each protocol is trying to solve the same problem with incompatible approaches. In this case, A2A, MCP, ACP, and Symphony are not identical in scope, but they overlap enough to create real architectural decisions.
Google’s A2A protocol is designed for agent-to-agent communication across organizational boundaries. Its focus is interoperability: an agent running inside one company’s infrastructure needs to request work from, or hand off context to, an agent in another company’s infrastructure. A2A addresses the trust, identity, and communication layers that make that possible without requiring both sides to share a common model or platform.
MCP, the Model Context Protocol, developed by Anthropic and now with broader community adoption, addresses a different layer: how tools, data sources, and context are made available to a model at inference time. MCP is less about agent-to-agent communication and more about agent-to-resource communication. A model that needs to query a database, read a file, or call an API does so through an MCP-defined interface.
ACP, the Agent Communication Protocol, operates closer to the messaging layer – how agents send and receive structured task requests in a standardized format. It shares surface area with A2A but differs in its approach to message schema and state management.
Symphony, as confirmed, addresses Codex orchestration, how Codex-based agents coordinate task execution, handle handoffs, and maintain state within an OpenAI- backed agentic pipeline. Its language-agnostic framing suggests the intent is broader than a single programming language, but the current confirmed scope is Codex-specific.
These four protocols are not fully substitutable. A team building a multi-agent system could plausibly need MCP for context management, A2A for cross-org handoffs, and Symphony for internal Codex orchestration. The fragmentation cost isn’t necessarily choosing one over the others. It may be implementing and maintaining all of them.
Why Now: What Five Standards in Ten Days Actually Signals
The four-framework release cycle catalogued April 27 identified a pattern: the infrastructure layer beneath agentic AI is being contested simultaneously by the same organizations that built the underlying models. That’s not a coincidence.
A protocol is infrastructure. Infrastructure that achieves adoption becomes a dependency. Dependencies create lock-in. Lock-in creates leverage, over developer tooling choices, enterprise procurement decisions, and eventually pricing. Every major AI lab understands that whoever sets the orchestration standard shapes how agentic AI gets built for years.
The ten-day pace reflects urgency, not readiness. These are drafts, proposals, and early-stage releases, not battle-tested production standards. The labs are publishing early because establishing presence in the standards conversation matters as much as having the best technical design. Being in the room when the standard gets written is how you influence what the standard says.
Developer Decision Framework: What to Evaluate Before Committing
Teams evaluating agentic orchestration protocols face a decision with long tail consequences. Adapting away from a protocol choice once it’s embedded in production pipelines is expensive. Here are the specific dimensions worth assessing before committing.
Backer and governance track record
Who controls the spec today, and what is the governance model for future versions? A2A has Google’s infrastructure team behind it; MCP has growing independent adoption beyond Anthropic; Symphony is OpenAI-controlled at Draft v1. Protocol governance failures are a real production risk, if a key dependency changes its API with a minor version bump, your pipeline breaks.
Scope alignment with your architecture
Don’t adopt a protocol because it has the best press. Map your actual orchestration problem, cross-org agent communication, context delivery, internal task coordination, against what each protocol demonstrably solves today, not what its roadmap promises.
Tooling ecosystem
Which protocol has SDK support in the languages and platforms your team already uses? A protocol without a maintained client library in your stack is an implementation burden, not a simplification.
Enterprise customer requirements
If your product delivers agentic capabilities to enterprise customers, ask what protocols your procurement counterparts have already standardized on. The right protocol may be the one your customer’s security team has already approved.
Conflict with existing integrations
If you’re already using MCP for context management, evaluate whether Symphony’s Codex orchestration layer complements or conflicts with that integration. The risk isn’t just overlap – it’s interaction effects between protocol implementations at the seams.
Governance Implications
Agentic AI governance under frameworks like the EU AI Act is complicated by the fact that most current regulatory guidance assumes a relatively contained AI system with defined inputs and outputs. Multi-agent architectures coordinating through external protocols introduce new questions: where does accountability for an agent action sit when the agent received a task via A2A from an agent operated by a different organization? When Symphony orchestrates a Codex agent that triggers a downstream chain of tool calls, who is the operator for EU AI Act purposes?
These aren’t hypothetical concerns for 2027. Teams deploying multi-agent systems into regulated workflows, finance, healthcare, legal, need governance frameworks that account for protocol-mediated agency now. The protocol standards emerging this week will shape what those governance frameworks have to address.
Symphony, A2A, MCP, and ACP are each unresolved. None has achieved the kind of broad adoption that would make it a de facto standard. The window for shaping the orchestration layer is open. It will not stay open.