OpenAI's Symphony announcement reports a 500% increase in landed pull requests on some teams; the service specification defines the scheduler, workspace, retry, and workflow boundaries.

What OpenAI Symphony changes

OpenAI describes Symphony as an agent orchestrator that turns a project-management board such as Linear into a control plane for coding agents. The motivation was practical. Engineers could comfortably manage roughly three to five interactive sessions before context switching erased the benefit.

The Symphony specification makes the model concrete. A conforming service:

  • reads eligible work from an issue tracker;
  • creates deterministic per-issue workspaces;
  • dispatches agents with bounded concurrency;
  • owns retries and reconciliation;
  • loads workflow behavior from a repository-owned WORKFLOW.md; and
  • exposes operator-visible state for concurrent runs.

OpenAI presents Symphony as a minimal orchestration layer and reference implementation, not a standalone product it plans to maintain indefinitely. That boundary is useful. It keeps the system focused on scheduling and running work.

It also shows exactly where architectural governance is still needed.

Work context is not architectural context

An issue can retain what a team wants done. It may contain requirements, acceptance criteria, comments, review feedback, and links to prior work.

Those are valuable forms of context. They are not the same as the architectural decisions governing the repository.

Consider a ticket that says:

Add persistence for customer preferences.

The issue can describe the feature perfectly and still leave consequential constraints implicit:

  • Which database is approved?
  • May this service access the database directly?
  • Which module owns persistence?
  • Are new infrastructure dependencies prohibited?
  • Does an accepted ADR require an existing abstraction?
  • Has the team already rejected an otherwise reasonable implementation?

A capable agent can produce a technically valid solution while contradicting any of those decisions.

The problem is not necessarily poor ticket writing. Work intent and architectural intent are different artifacts.

The issue tracker should remain authoritative for what the organization wants changed. A project decision corpus should remain authoritative for the engineering decisions that govern that change.

Symphony's boundary is explicit

The specification describes Symphony as principally a scheduler, runner, and tracker reader. It does not prescribe one universal sandbox, approval, or operator-confirmation policy. Implementations are expected to document their own trust posture.

That is a sensible boundary for an orchestrator.

It also prevents a common category error. Orchestration answers:

  • Which agent runs?
  • What task does it receive?
  • Where does it run?
  • What happens when it stalls or fails?

Software engineering governance answers:

  • Which architectural decisions apply?
  • Which constraints must survive retries and agent replacement?
  • What proposed changes require a warning, exception, or hard failure?
  • What evidence proves the decision was evaluated?

The existing Mneme article on agent orchestration and governance defines that category boundary. Symphony provides a named, concrete instance of why it matters.

Disposable sessions increase the cost of drift

With one engineer supervising one agent, architectural mistakes can often be corrected conversationally. The developer notices the wrong dependency or service boundary and redirects the session.

That does not scale cleanly when an orchestrator runs many isolated issues.

One agent reads the current ADR. Another finds an outdated example first. A third retrieves the right decision but treats it as optional guidance. A fourth never encounters it because the issue appears unrelated based on filenames or semantic similarity.

Each run may compile and pass its local tests. The repository can still accumulate architectural drift.

The scaling question is therefore not only how many agents can execute concurrently. It is whether the same architectural constraints propagate reliably across those executions.

Retrieval helps; enforcement is different

Symphony works best with agent-friendly repositories, explicit workflows, strong tests, and clear instructions. Its version-controlled WORKFLOW.md is an important engineering practice.

But a retrieved instruction and an enforced constraint have different failure semantics.

An ADR might say:

Application services must use PostgreSQL through the persistence adapter.

An agent can retrieve that sentence and still bypass the adapter. It may decide direct SQL is simpler, or it may modify a component without recognizing that the rule applies.

A stronger model separates the layers:

  1. Maintain a durable decision corpus.
  2. Resolve which decisions apply to the proposed work.
  3. Propagate those constraints into the agent workflow.
  4. Evaluate the plan and resulting change against a verification contract.
  5. Deterministically enforce the rules that can be expressed safely.
  6. Preserve human review for ambiguity and legitimate exceptions.

The objective is not to replace agent reasoning. It is to prevent architectural authority from depending entirely on one temporary session.

Isolated workspaces make propagation visible

Symphony's deterministic per-issue workspaces are operationally valuable. They separate tasks, retain issue state across retries, and give the orchestrator an authoritative lifecycle surface.

Isolation also creates a clear governance boundary.

If a decision applies in the main repository but never reaches an isolated run, the workspace does not preserve architectural intent. The same issue appears when teams use more than one coding agent:

  • Codex through Symphony;
  • Claude Code in an interactive or hosted environment;
  • another agent triggered from CI;
  • human developers changing the same repository.

The execution paths differ. The architecture should not.

That is governance propagation: carrying authoritative decisions to every surface where they apply without turning copied prompts into competing sources of truth.

What engineering leaders should separate

Teams evaluating Symphony-style workflows should design four distinct control surfaces:

  1. Work persistence. The issue tracker records the requested outcome and its state.
  2. Agent orchestration. Symphony or an equivalent system dispatches work, manages workspaces, and handles retries.
  3. Architectural authority. A versioned decision corpus records what the software must continue to preserve.
  4. Compliance evidence. A verification contract defines which properties are checked and what happens when they fail.

Collapsing those concerns into one prompt works only while the workflow is small enough for a human to reconstruct the missing boundaries.

Disposable agents need durable architectural authority

Symphony makes an important architectural principle visible: the agent does not have to be the durable object.

The work can outlive the session. The workspace can be recreated. The orchestrator can retry execution. A different model can eventually perform the task.

Architectural intent therefore needs to live somewhere more durable than any of them.

Mneme's role is complementary to Symphony. The orchestrator determines what an agent should work on now. Mneme is building the architectural governance layer that determines which project decisions apply and which explicit constraints can be enforced before incompatible changes become drift.

OpenAI Symphony advances the orchestration layer. The next enterprise question is whether architectural authority can propagate across autonomous runs with the same reliability.