OpenAI Releases Symphony: An Open Source Agentic Framework for Orchestrating Autonomous AI Agents through Structured, Scalable Implementation Runs

OpenAI has released Symphony, an open-source framework designed to manage autonomous AI coding agents through structured ‘implementation runs.’ The project provides a system for automating software development tasks by connecting issue trackers to LLM-based agents.

System Architecture: Elixir and the BEAM

Symphony is built using Elixir and the Erlang/BEAM runtime. The choice of stack focuses on fault tolerance and concurrency. Since autonomous agents often perform long-running tasks that may fail or require retries, the BEAM’s supervision trees allow Symphony to manage hundreds of isolated implementation runs simultaneously.

The system uses PostgreSQL (via Ecto) for state persistence and is designed to run as a persistent daemon. It operates by polling an issue tracker—currently defaulting to Linear—to identify tasks that are ready for an agent to address.

The Implementation Run Lifecycle

The core unit of work in Symphony is the implementation run. The lifecycle of a run follows a specific sequence:

Polling and Triggering: Symphony monitors a specific state in the issue tracker (e.g., ‘Ready for Agent’).

Sandbox Isolation: For each issue, the framework creates a deterministic, per-issue workspace. This ensures the agent’s actions are confined to a specific directory and do not interfere with other concurrent runs.

Agent Execution: An agent (typically using OpenAI’s models) is initialized to perform the task described in the issue.

Proof of Work: Before a task is considered complete, the agent must provide ‘proof of work.’ This includes generating CI status reports, passing unit tests, providing PR review feedback, and creating a walkthrough of the changes.

Landing: If the proof of work is verified, the agent ‘lands’ the code by submitting or merging a Pull Request (PR) into the repository.

Configuration via WORKFLOW.md

Symphony utilizes an in-repo configuration file named WORKFLOW.md. This file serves as the technical contract between the developer team and the agent. It contains:

The agent’s primary system instructions and prompts.

Runtime settings for the implementation environment.

Specific rules for how the agent should interact with the codebase.

By keeping these instructions in the repository, teams can version-control their agent policies alongside their source code, ensuring that the agent’s behavior remains consistent with the specific version of the codebase it is modifying.

Harness Engineering Requirements

The documentation specifies that Symphony is most effective in environments that practice harness engineering. This refers to a repository structure that is optimized for machine interaction. Key requirements include:

Hermetic Testing: Tests that can run locally and reliably without external dependencies.

Machine-Readable Docs: Documentation and scripts that allow an agent to discover how to build, test, and deploy the project autonomously.

Modular Architecture: Codebases where side effects are minimized, allowing agents to make changes with high confidence.