The Problem

Developers who use coding agents often spend more time supervising the agents than delivering value. Missing isolation, unclear hand‑off points, and ad‑hoc tooling make it hard to treat “work items” as autonomous, reproducible runs. The result is fragile pipelines and constant manual triage.

What This Does

Symphony provides a reference implementation (the elixir sub‑project) that treats each work item as a self‑contained execution. The core runtime lives in elixir/lib/symphony_elixir/*.ex – e.g. orchestrator.ex decides which agent to launch, app_server.ex and workspace.ex manage the isolated environment, and cli.ex exposes a command‑line entry point. Docker support for end‑to‑end tests is in elixir/test/support/live_e2e_docker/. The repository also ships a small .codex helper library used by the original OpenAI spec.

How It Is Wired

  • Entry point – elixir/lib/symphony_elixir/cli.ex implements main/1. The Mix task mix symphony (defined in mix.exs) invokes CLI.run/1.
  • Orchestration – CLI.run/1 calls SymphonyElixir.Orchestrator.start/0. The orchestrator loads configuration from elixir/lib/symphony_elixir/config.ex (which reads config/config.exs) and creates a Workspace (workspace.ex).
  • Workspace – Workspace provisions an isolated directory, writes a temporary spec, and hands it to AppServer.start/1 (app_server.ex). The app server spawns an Elixir process that runs the agent code (agent_runner.ex) and streams logs via LogFile.ex.
  • Agent execution – AgentRunner selects a tool (e.g. Linear adapters in linear/) and runs the work payload. Results are posted back through HttpServer.ex and recorded in Tracker (tracker.ex / tracker/memory.ex).
  • Status reporting – StatusDashboard.ex aggregates live metrics; tests in core_test.exs snapshot its output. The LiveView dashboard_live.ex renders the dashboard in the Phoenix web UI.

All side‑effects (filesystem writes, network calls) are confined to the Workspace directory and the HTTP server port configured in config.ex. No circular dependencies appear in the import graph (1 internal module, 0 import edges). The biggest blast‑radius modules are orchestrator.ex, status_dashboard.ex, and the core test suite (core_test.exs), each exceeding 1 300 lines.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/symphony
cd symphony/elixir

# Install deps (Mix)
mix deps.get

# Run unit tests
mix test

# Start the server (example)
mix run --no-halt   # invokes CLI → Orchestrator → AppServer

The Docker‑based live‑E2E tests can be exercised with the provided Dockerfile:

cd elixir/test/support/live_e2e_docker
docker compose up --build

Configuration lives in elixir/config/config.exs; adjust the :http_port or workspace root as needed before running.

Real‑World Use

A product team that tracks tickets in Linear can point Symphony at a board. When a new ticket appears, the orchestrator creates a workspace, runs the agent (via AgentRunner), and posts a PR with CI status. The team reviews the PR and merges; Symphony then archives the workspace automatically. The whole flow requires only the CLI start command and a Linear API token placed in config.exs.

Code Health & Issues

  • HIGH – Pin third‑party GitHub Actions to a commit SHA (.github/workflows/*).
  • MEDIUM – Declare least‑privilege permissions for GITHUB_TOKEN (make-all.yml).
  • MEDIUM – Pin Docker base image by digest (Dockerfile).
  • MEDIUM – Move large binary symphony-demo.mp4 to Git LFS.
  • MEDIUM – Add a non‑root USER in the Dockerfile.
  • LOW – Set timeout-minutes on workflow jobs.
  • LOW – Add missing convention files (.editorconfig, .gitattributes, formatter config).

Additional observations: tests and CI are present; a license file exists; no lockfile (no mix.lock‑based pinning beyond mix.lock itself); no secrets detected.

The Bottom Line

Symphony offers a concrete, Docker‑enabled Elixir reference for turning work items into isolated runs, with a clear call chain from CLI to workspace to agent. The codebase is functional but suffers from duplicated logic, oversized modules, and several CI‑security hygiene gaps that should be addressed before production use. It is best suited for teams comfortable with Elixir/Phoenix who need a sandboxed agent execution framework and are prepared to refactor the identified hotspots.