From Spec-Driven Work to Work Orchestration

Introducing OpenSymphony

Last year I wrote The Six Pillars of Spec-Driven Work. The main claim in that piece was simple: AI-assisted development works better when intent, constraints, validation, and collaboration are explicit. Specs help because they turn vague requests into durable artifacts that humans and agents can both act on.

What was still missing was a concrete work system that could carry those ideas through execution, review, and recovery.

That is the gap OpenSymphony is meant to address. OpenSymphony is my implementation of the OpenAI Symphony design. It uses Linear as the work source, OpenHands as the execution harness, and a Rust orchestrator to manage issue runs, workspaces, retries, and recovery. This article is the written companion to that release. The best starting point is https://OpenSymphony.dev. It sits alongside the OpenSymphony launch video and my three-hour video series, Work Orchestration for Agentic Engineering.

The problem after better prompts

Specs improve task definition. Long-horizon agent work still has an operational problem.

Once a task runs across hours, days, or multiple review cycles, three problems dominate:

• scope: how work gets bounded, decomposed, and retried

• context: how useful state survives across runs

• execution: how the system edits files, runs checks, handles review, and proves completion

That is the theory spine behind this project. It matters because many agent workflows still treat long-horizon work as one extended session. That works for short demos. It degrades quickly when the task gets larger. The session drifts. The context bloats. The work becomes hard to inspect. Review turns into archaeology.

A long chat transcript is a weak system of record. It mixes planning, execution, corrections, and memory into one surface. It is difficult to audit, difficult to hand off, and difficult to resume cleanly.

That was the missing layer I kept running into after writing about spec-driven work. I wanted a higher-density review trail. I wanted issue comments, repository artifacts, and workspaces to carry more of the state. I wanted the work item to be the unit of control.

A short theory of orchestration

An agent harness is the operational environment around the model. It gives the model tools, file access, terminal access, memory, approvals, and an execution loop.

Context engineering is the design of the agent’s informational environment. It decides what plans, summaries, rules, issue details, repository instructions, and local artifacts the harness sees at run time.

Orchestration is the control logic around the work. It decides how tasks are decomposed, when runs start or stop, how retries behave, what gets verified, and how state moves across steps.

Those are different layers. The harness answers how the agent acts. Context engineering answers what the agent can see. Orchestration answers how the work advances.

From there, orchestration splits into several patterns.

Some orchestration lives inside the harness. Skills, routing rules, tool selection, and durable repository artifacts shape how the harness behaves inside a single working environment.

Some orchestration lives outside the harness. An outer loop can launch a fresh run, inject focused context, inspect the result, update external state, and decide what to do next. This pattern is useful because long runs often improve when important state lives outside the session instead of inside it.

Persistent workspaces add another step. They preserve the working surface of the task. Files, branches, logs, state artifacts, and partial progress survive restarts and review cycles.

Work orchestration sits above those layers. At that level, the ticket or issue becomes the control surface. The workspace becomes the execution boundary. Workflow policy becomes explicit. Review, retry, and landing become part of the system itself instead of cleanup around a chat session.

That framework points to a work system with its own control plane.

From session control to work control

That shift in control is the most important idea in this model.

In a chat-centered workflow, the human manages the session. The human decides what to paste next, how to remind the agent what happened, when to restart it, and how to interpret partial progress.

In a work-oriented workflow, the human manages the work item. The issue defines the task. The workspace holds the task state. The policy files describe how the repository wants work to be done. The orchestrator owns retries, recovery, and scheduling. The harness executes inside those boundaries.

That changes the job of the human operator. The operator still matters. The operator defines tasks, reviews results, adjusts policy, and handles exceptions. What changes is the surface where that work happens.

This is also where the Six Pillars connect directly to work orchestration:

• collaboration becomes issue-level supervision and review

• transparent process becomes visible run state, issue comments, PR feedback, and repository artifacts

• orchestration and handoff become concrete paths across issue tracker, workspace, harness, and review system

• good specs become implementation plans with dependencies and acceptance criteria

• rule-driven validation becomes repository-owned workflow policy, review gates, and verification steps

• final artifacts become merged code plus the audit trail that explains how it got there

The Six Pillars article argued for explicit artifacts. Work orchestration gives those artifacts a runtime.

Why Symphony mattered

I became much more interested in this direction when OpenAI published Symphony. The part that mattered was the architecture.

Symphony treats the ticket, the workspace, and the workflow contract as first-class runtime concepts. It assumes a long-running orchestrator outside the harness. It preserves issue-scoped workspaces. It keeps policy in repository-owned files. It treats review and evidence as part of the execution loop.

That made several things concrete at once.

First, it made the issue tracker legible as the actual command surface. Second, it made workspace isolation a normal part of the runtime instead of an optional convenience. Third, it made workflow policy explicit and versioned. Fourth, it separated the harness from the orchestrator cleanly enough that the harness could stay focused on execution.

That design matched what I had been reaching toward since the Six Pillars article. Once I saw Symphony, it became clear that the missing piece was a work-level control plane.

What OpenSymphony implements

OpenSymphony is a new implementation of the Symphony design with a different runtime stack. It is separate from the Elixir reference implementation.

In the current MVP:

• Linear is the work source

• the orchestrator is written in Rust

• OpenHands agent-server is the execution harness

• each issue gets its own workspace

• repository policy comes from WORKFLOW.md

• the operator can watch the system through the terminal UI and through Linear

The orchestrator polls for eligible issues, creates or reuses issue workspaces, dispatches work through OpenHands, tracks retries and reconciliation, and keeps scheduling state outside the harness. Operational commands such as doctor, debug, and rehydrate exist for the same reason. A real work system needs inspection and recovery surfaces alongside the happy path.

That separation of responsibilities is one of the main points of the system.

The orchestrator owns scheduling, retry policy, recovery, hierarchy-aware dispatch, and state reconciliation. OpenHands owns agent execution. The TUI reads the control plane and reports its state. The issue and PR trail capture review and rework. Each layer has a narrower job.

For greenfield projects there is also OpenSymphony-template, which packages WORKFLOW.md, AGENTS.md, local skills, and automated PR review into a starting repository. Existing repositories can add the same pieces incrementally.

Token budget and model economics

This is a token-heavy workflow. A serious project can consume hundreds of millions or billions of tokens once planning, execution, review, retries, and rework all live inside the loop. That is part of the operating model, not an edge case.

That cost profile is one reason the harness choice matters. Because OpenSymphony uses OpenHands, an independent agent harness, provider and model choice stay flexible. You can run the workflow against third-party providers and open models, such as GLM-5.1 through Fireworks. In practice, that means you can keep working beyond subscription plan ceilings and run large projects at per-token prices that can be an order of magnitude lower than Anthropic or OpenAI APIs.

What building it taught me

The project made several theory points more concrete.

Rework needs continuity. If review feedback means “throw away the run and start over,” the system becomes brittle. A better model is patch and continue. The issue stays the same. The workspace stays the same. The audit trail stays attached to the work item.

Issue hierarchy affects execution policy. Parent issues and sub-issues affect what should run now, what should remain blocked, and what counts as complete.

Review automation works best when it stays inside the same branch and discussion surface. Once review comments, fixes, and follow-up work are spread across disconnected places, the loop gets weaker and the history gets harder to read.

These are operational details. They are also the difference between a short demo and a system that can supervise real work.

Where this points

The current OpenSymphony release is a local, supervised MVP. It covers the core loop: issue intake, workspace isolation, policy-driven execution, monitoring, review, recovery, and landing.

The next step is a hosted mode with a conversational planning surface that helps produce the spec, the implementation plan, and the issue set before execution starts.

This points back to the same claim behind the Six Pillars article. Better specs matter. Better harnesses matter. Better context matters. Long-horizon reliability also depends on the work system around them.

If the issue becomes the control surface, the workspace becomes the execution boundary, and the workflow contract becomes explicit, agentic engineering becomes easier to supervise, easier to review, and easier to resume.

Resources

• Website: OpenSymphony.dev

• Launch video: OpenSymphony launch video

• Six Pillars article: The Six Pillars of Spec-Driven Work

• Orchestration course: Work Orchestration for Agentic Engineering

• Repository: kumanday/OpenSymphony

• DeepWiki: OpenSymphony on DeepWiki