About / Overview

About

A work system around the agent for durable, supervised engineering.

OpenSymphony is a greenfield Rust implementation of the OpenAI Symphony design. It keeps orchestration authority outside the harness, gives each issue its own workspace, and uses an independent agent harness that keeps provider and LLM choices flexible while the orchestration model stays stable.
Expanded OpenSymphony TUI interface with multiple tasks running in parallel.

Created by

Two layers

What OpenAI Symphony defines and what OpenSymphony implements.

What OpenAI Symphony is

A model for work-system orchestration

OpenAI Symphony makes the ticket, workspace, and workflow contract first-class runtime concepts. It assumes polling, reconciliation, preserved workspaces, and human review inside the execution loop.

The orchestration model centers polling, selection, reconciliation, and dispatch as explicit parts of the work system.
Diagram showing the orchestration poll loop, selection logic, and backend interfaces in the Symphony model.

What OpenSymphony adds

A concrete local-first implementation in Rust

OpenSymphony uses Linear for issues, OpenHands as an independent harness layer, a read-only control plane for observability, and an operator-facing TUI for supervision.

The orchestrator prepares workspaces and owns lifecycle control, while OpenHands manages the execution session.
Diagram showing the boundary between the Rust orchestrator and OpenHands execution.

Architecture

Five layers keep the system legible.

OpenHands executes work, and OpenSymphony owns the lifecycle around that work.

Policy

Workflow files and repo-owned rules

WORKFLOW.md, AGENTS.md, and local skills define the contract for how the repository wants work to be run.

Configuration

Typed workflow and runtime settings

OpenSymphony resolves configuration, environment variables, paths, and OpenHands settings before execution begins.

Coordination

Scheduler, retries, and reconciliation

The orchestrator decides issue eligibility, bounded concurrency, hierarchy-aware dispatch, retries, and startup recovery.

Execution

Workspace manager plus OpenHands runtime

Each issue maps to a deterministic workspace, and OpenHands handles the session and tool execution inside that boundary.

Observability

Control plane and the TUI

The TUI reads from the control plane and keeps monitoring separate from correctness.

Workflow summary

The loop in one pass.

This is the operational shape of the MVP today.

Diagram showing the flow from a Linear issue through the OpenSymphony runtime layers into the coding task and AI agent.

01

Poll Linear for eligible issues

Candidate issues come from the tracker, with hierarchy-aware scheduling so blocked parent work stays blocked.

02

Prepare the issue workspace

Hooks, manifests, prompt artifacts, and ownership checks all live in the issue-scoped directory.

03

Attach or resume the execution session

OpenSymphony reuses per-issue conversations by default and handles continuation, startup recovery, and runtime reconciliation.

04

Watch progress through the control plane

The operator sees running work in the TUI and can inspect snapshots, events, retries, and issue state.

05

Keep review and recovery in the same work loop

PR feedback, rework, restart recovery, and follow-up runs stay attached to the same issue context.

Design rules

The boundaries are the point.

The orchestrator is the source of truth.

Scheduling state, retries, and recovery stay in Rust, where orchestration remains authoritative.

Each issue owns its own execution boundary.

Workspace isolation is how durable state and recovery remain understandable.

The UI is optional.

The TUI supports observability and supervision.

Human review is part of the model.

The model centers on supervised long-horizon agent work with a clean audit trail.