Sprint Engine Studio and Symphony: Building the Command Center for Agentic Delivery

OpenAI has released Symphony, an open-source orchestration tool for Codex. It turns an issue tracker into the control plane for background coding agents: issues become work items, each eligible issue gets an isolated workspace, Codex runs through the app-server interface, and the service supervises scheduling, retries, stalls, and cleanup.

This matters because Symphony validates a direction we have been building toward in SE Studio: coding agents need orchestration, not just a chat box. But it also raises the bar. A Kanban board with agents is no longer enough as a product strategy. The useful question is what SE Studio should become in a world where an open-source Codex orchestration layer exists.

What Symphony does

Symphony is best understood as a thin, issue-driven agent runner. Linear is the current source of truth. A Symphony service polls for active work, creates or reuses a workspace for each issue, launches Codex, streams work through the Codex app-server flow, and updates the workflow as issues progress.

The important design choice is that Symphony does not try to be a rich product surface. Its spec keeps the orchestration service focused: tracker integration, workspace lifecycle, concurrency limits, retries, stalled-run handling, and cleanup. The issue tracker remains the state machine. Codex remains the implementation agent.

That is a strong architecture for background execution. It keeps the runner small and gives teams a concrete way to connect real project work to Codex agents without inventing a new project-management system.

Where SE Studio fits

SE Studio has been approaching the same problem from the opposite side. We started with the human-facing command center: local workspaces, agent terminals, swarm boards, task graphs, specialist roles, artifact approvals, worktree isolation, mobile review flows, and evidence capture.

That gives us a different job. SE Studio should not clone Symphony's scheduler. Instead, SE Studio should become the best way to operate Symphony-compatible work: inspect what is running, understand what changed, review artifacts, approve gates, compare agents, and preserve proof of delivery.

Symphony can be the runner. SE Studio should be the command center.

What changes in our positioning

Before Symphony, it was tempting to describe SE Studio as a local multi-agent Kanban board. That description is now too small. The stronger position is that SE Studio is a reviewable command center for agentic software delivery.

In practice, that means SE Studio should support multiple execution modes. Swarm remains our local board mode for scoped work. Symphony compatibility becomes the issue-driven mode for teams that want Codex agents attached to tracker work.

• Swarm: local, bounded task graphs with specialist agents and artifact gates.
• Symphony mode: external issue-tracker work executed by Codex-compatible background agents, supervised and reviewed in SE Studio.

What we plan to integrate

Our first compatibility target is not a hosted Symphony cloud. It is a local integration path that lets SE Studio understand Symphony's workflow contract and display Symphony-style work in the same product surface as our own swarm runs.

• Read and validate repo-level workflow configuration such as WORKFLOW.md.
• Attach SE Studio to a local Symphony runner or Symphony-compatible workspace layout.
• Map external issues into SE Studio task cards and task graph views.
• Represent each issue workspace as an execution context, including local path, branch, agent status, and handoff state.
• Ingest structured Codex app-server events where available instead of relying only on terminal output.
• Turn completed issue work into SE Studio run reports with diffs, tests, artifacts, screenshots, and review notes.

What we should not duplicate

There is no strategic value in rebuilding Symphony's core loop just to own it. Tracker polling, basic eligibility rules, isolated issue workspaces, and Codex app-server dispatch are infrastructure concerns. If Symphony becomes a useful open standard, SE Studio should integrate with it and focus on the user-facing layer where we can add durable value.

The same applies to issue trackers. Linear is the first Symphony target, but SE Studio should not become Linear-only. The product needs to preserve local-first workflows, GitHub issue workflows, and repo-native planning documents. Symphony compatibility should expand the system, not narrow it.

The product gap Symphony leaves open

Background agents create a new review problem. More work can happen at once, but humans still need to know what happened, what changed, what was tested, what failed, what needs approval, and whether the result is safe to merge.

That is the space SE Studio should own. Agentic delivery does not need another activity feed. It needs a reliable review surface. It needs artifact gates. It needs workspace and worktree visibility. It needs final-run summaries. It needs a way to compare Symphony-only execution against SE Studio swarm, single-agent CLI work, and future agent backends.

This also strengthens the role of Multibench. If agent orchestration becomes common infrastructure, the differentiator becomes evidence: which workflow actually delivered the requested software with fewer regressions, clearer review trails, and less human cleanup?

How we think about the architecture

The near-term architecture is an adapter model. SE Studio should normalize multiple execution sources into one delivery model: local swarm state, Symphony issue state, Codex app-server events, terminal sessions, worktrees, artifacts, and benchmark reports.

Issue or local goal
  -> execution backend
  -> agent/session events
  -> task and artifact model
  -> review gates
  -> delivery evidence
  -> benchmarkable run report

That keeps the product flexible. If Symphony's reference implementation changes, SE Studio can still support the workflow shape. If teams use GitHub issues, local markdown plans, or another runner, the same command-center model still applies.

Our commitment

We are going to make SE Studio Symphony-compatible. That means we will treat Symphony as an important open-source orchestration standard for Codex-driven software delivery and build integration paths that let users bring Symphony-style work into SE Studio.

At the same time, we are not abandoning Swarm. Symphony validates the execution layer. SE Studio's product bet remains the command center: local visibility, specialist review, artifact approval, worktree control, mobile companion flows, and evidence-backed delivery.

What success looks like

• A user can open SE Studio and see Symphony-managed issues next to local SE Studio work.
• A user can inspect a running Codex issue workspace without hunting through raw logs.
• A user can see what changed, what tests ran, what failed, and what needs review.
• A user can compare Symphony execution, SE Studio swarm execution, and single-agent execution using the same evidence format.
• A team can keep using its tracker while SE Studio becomes the place where agent work is supervised and trusted.

The category is moving quickly. Symphony makes it clearer that agent orchestration is becoming infrastructure. SE Studio's job is to make that infrastructure usable, reviewable, and measurable for real software teams.

Sources: OpenAI Symphony announcement at openai.com/index/open-source-codex-orchestration-symphony, the openai/symphony repository, and the Codex app-server documentation at developers.openai.com/codex/app-server.