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 pairs a Rust control plane with a desktop app for dependency-aware task graphs, run inspection, changed files, and graph-based project memory. Each issue keeps its own workspace while OpenHands and the supported local Codex app-server route provide explicit harness choices.
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.
What OpenSymphony adds
A concrete local-first implementation in Rust
OpenSymphony uses Linear for issues, OpenHands as the default harness, and a supported local Codex app-server route. The control plane is observable through the TUI and a rich desktop app with Knowledge Graph, Task Graph, and Code Graph visualizations.
Architecture
Five layers keep the system legible.
OpenHands or Codex 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 selected harness runtime
Each issue maps to a deterministic workspace, and the selected harness handles the session and tool execution inside that boundary. OpenHands is the default, with a supported local Codex app-server route.
Clients
Control plane and clients
The TUI and desktop app read from the control plane, keeping monitoring, task graphs, run detail, and project context separate from orchestration correctness.
Workflow summary
The loop in one pass.
The loop keeps planning, execution, review, and recovery attached to the same issue context.
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 or desktop app and can inspect snapshots, events, retries, task state, and issue context.
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 execution boundary.
Workspace isolation is how durable state and recovery remain understandable.
Clients stay focused on supervision.
The TUI and desktop app provide observability and supervision while orchestration remains authoritative in Rust.
Human review is part of the model.
The model centers on supervised long-horizon agent work with a clean audit trail.