symphony: The Elixir Engine Managing OpenAI's Autonomous Workforce

The End of Babysitting

The era of the interactive coding assistant is reaching its logical conclusion. Tools like GitHub Copilot revolutionized development by acting as a highly capable, always-on pair programmer. But they still require a human in the driver's seat, prompting, reviewing, and nudging the AI toward a solution. The next frontier isn't a better autocomplete; it's a capable employee. It's the transition from supervising a tool to managing a worker.

Enter Symphony, an open-source framework released by OpenAI. Symphony acts as a bridge between an issue tracker (like Linear) and AI coding agents (like OpenAI's Codex). When a ticket is moved to a 'Ready' state, Symphony wakes up, spawns an isolated workspace, and directs an agent to complete the task asynchronously. There is no chat window. There is no prompt engineering field.

The BEAM in the Machine

The most surprising aspect of Symphony isn't what it does, but how it's built. In an AI ecosystem dominated by Python, Symphony's core orchestration engine is written almost entirely in Elixir. Why would an AI lab famous for Python choose a functional language running on the 30-year-old Erlang Virtual Machine (BEAM)?

The answer lies in the nature of the problem. Managing autonomous agents isn't an AI problem; it's a highly concurrent, fault-tolerant state-management problem. Agents are unpredictable. They enter infinite loops, they time out waiting for API responses, and they crash sandbox environments. If a Python-based orchestrator crashes due to a single rogue agent, the entire system goes down.

Elixir's `GenServer` architecture solves this elegantly. Each agent run is an isolated, lightweight process. If an agent's process crashes, the BEAM simply restarts that process according to a defined supervision strategy. The orchestrator continues running, unaffected. Furthermore, Symphony is designed to be 'database-less.' It uses the issue tracker as its source of truth and the filesystem as its state store. If the entire Symphony service is restarted, it simply polls Linear and checks the disk to resume exactly where it left off.

Forcing Proof of Work

Autonomy is dangerous without accountability. An agent that can write code and create PRs is useless if the code doesn't work or breaks existing functionality. Symphony addresses this with a strict 'Proof of Work' protocol.

Before an agent can submit a pull request, it must complete a rigorous 'Turn' loop. It isn't enough to just write the code. The agent must run the test suite, analyze the complexity of the changes, and, remarkably, generate a recorded video walkthrough of the modifications. Only when this complete package of evidence is assembled is the PR presented to a human reviewer.

In-Repo Policy and AI GitOps

How do you tell an autonomous agent how to behave within a specific codebase? Symphony introduces the concept of In-Repo Policy via a `WORKFLOW.md` file located directly in the target repository.

---
name: Frontend Bugfix
triggers:
  - linear_state: Ready
skills:
  - linear
  - commit
  - land
---
# System Prompt
You are an expert React developer. When fixing bugs in this repository, always ensure that component tests are updated to reflect the new state. Do not modify the core styling variables without explicit permission.

This approach brings GitOps principles to AI management. The agent's 'personality,' rules, and available skills are version-controlled alongside the code it is meant to edit. When an engineering team wants to adjust how the AI works, they submit a PR modifying the `WORKFLOW.md` file, subjecting the AI's instructions to the same review process as the application code.

Harness Engineering vs. The Terminal

Giving a Large Language Model raw bash access to a server is a recipe for disaster. Symphony mitigates this risk through a philosophy of 'Harness Engineering.' Instead of an open terminal, agents are provided with discrete, validated Python scripts located in the `.codex/skills/` directory.

These 'skills' act as guardrails. If the agent needs to commit code, it must call the specific `commit` skill script, which enforces formatting and commit message standards. This limits the blast radius of the AI, ensuring it can only interact with the system in predefined, safe ways.