OpenAI Symphony — reading the open-source multi-agent orchestration specification from a client-work perspective

On April 27, 2026, OpenAI announced An open-source spec for orchestration: Symphony on its official blog and published the specification repository on GitHub. Just as MCP serves as the standard for tool invocations, Symphony attempts to standardize "coordination among multiple agents."

From a custom development perspective, deciding which specification to adopt when uniting multiple agents will be a critical technical decision over the next 1 to 2 years. This article summarizes Symphony's building blocks and criteria for deciding whether to adopt it in client projects.

The problem Symphony aims to solve

Historically, multi-agent systems took "proprietary specifications for each framework" as the norm, causing the following issues to recur across projects:

Symphony aims to achieve cross-framework orchestration by standardizing three elements: jobs, state, and events.

The three pillars of the specification

1. Job Envelope

Wraps jobs passed between agents in a common schema.

{
  "job_id": "j-2026-04-27-abc123",
  "from": "agent.coordinator",
  "to": "agent.code-writer",
  "task": {
    "type": "implement",
    "spec": "POST /users エンドポイントを追加",
    "constraints": ["TypeScript 5.x", "express 5.x"]
  },
  "context_refs": ["ctx://session/01HX..."],
  "deadline": "2026-04-27T15:00:00Z",
  "callback": "agent.coordinator.on_complete"
}

The key point is that context_refs is a URI reference. By passing only references rather than embedding the context body into the job, token consumption is curtailed while enabling multiple agents to observe the same conversation history.

2. State Bus

A pub/sub state bus specification designed for multiple agents to read and write shared state.

Implemented via an adapter pattern abstracting Redis Streams, NATS, Kafka, and others, SDK implementations are currently provided in three languages: TypeScript, Python, and Go. Even if TypeScript is chosen for a custom development project, Python-based agents can be added later without structural friction.

3. Trace Spec

An extension that maintains compatibility with OpenTelemetry while capturing agent-specific attributes such as prompts, thought logs, and tool calls.

span:
  name: agent.code-writer.invoke
  attributes:
    symphony.agent_id: agent.code-writer
    symphony.job_id: j-2026-04-27-abc123
    symphony.tools_used: ['mcp.github.create_pr', 'mcp.fs.write']
    symphony.tokens_in: 4521
    symphony.tokens_out: 1023
    symphony.cost_usd: 0.018

Platforms like Langfuse and Datadog APM have already announced support for the Symphony Trace Spec (as of the official announcement). This makes it easy to swap out observability tools later.

Relationship with existing frameworks

We summarize Symphony's relationship with the Agents SDK covered in our OpenAI Agents SDK v2 article, as well as Anthropic Claude Code, CrewAI, LangGraph, and others.

In other words, Symphony is not a replacement for specific SDKs, but an orchestration layer sitting on top of SDKs. In custom development, decisions such as "we want to continue using LangGraph" or "we want to center our stack on Claude Code" can be preserved.

Decision criteria for adoption in client projects

Before deciding to build with Symphony by default, evaluate along three axes:

Axis 1: Single agent vs. multiple agents

If an agent operates entirely on its own, Symphony is overengineered. ROI emerges only in projects where two or more agents collaborate.

Axis 2: Importance of observability

If an enterprise project strictly requires capturing audit logs and traces, the Symphony Trace Spec becomes a formidable asset. Conversely, in early PoC stages, proprietary implementations are often faster.

Axis 3: Concerns regarding vendor lock-in

Concerns that "it is an OpenAI specification, so it will lock us into OpenAI" are unfounded when examining the license. It is released under Apache 2.0, and specification governance is open to the community. Similar to MCP, we anticipate a strong likelihood of it being transferred to the Linux Foundation in the future.

Standard architecture we implement in PoC engagements

Here is the standard architecture we adopt when implementing Symphony in client multi-agent engagements.

[Coordinator Agent]
   │
   │  Job Envelope (Symphony)
   ↓
┌──────────────┬──────────────┬──────────────┐
│ Code Writer  │ Reviewer     │ Test Runner  │
│ (Claude)     │ (GPT-5.5)    │ (Gemini)     │
└──────────────┴──────────────┴──────────────┘
   │              │              │
   └──── State Bus (Redis Streams)────┘
                  │
              Trace → Langfuse

Even when mixing different model vendors, the shared specifications of Job Envelope and State Bus keep reconfiguration costs minimal, which is a major advantage.

Summary ─ Deciding on the "common language for multi-agent systems" in 2026

Although Symphony is an OpenAI-led initiative, it is fundamentally an effort to run multi-agent systems on an industry-standard format. In custom development environments, even if different SDKs are adopted across projects, standardizing on Symphony for Job Envelope and State Bus significantly reduces the cost of switching to another SDK in the next project.

We provide custom development services covering design, PoC, production builds, and operational support for multi-agent platforms centered on Symphony. If you are considering "integrating multiple agents into operational workflows" or "achieving cross-cutting observability for existing agents," please feel free to reach out via our contact form.

Sources

• OpenAI Blog — An open-source spec for orchestration: Symphony
• GitHub — openai/symphony-spec
• Taking OpenAI Agents SDK v2 into Production