GSD-2 and the Next Step in Agentic Engineering
The Move from Context Orchestration to External Execution
GSD-2 and the Move from Context Orchestration to External Execution
GSD-2 changes where orchestration lives.
GSD v1 made long-horizon agent work more manageable by shaping the agent’s environment. It installed commands and skills into existing coding harnesses, gave the agent durable project artifacts, split projects into phases, and pushed implementation into fresh executor windows. That solved a real pain: complex agent work falls apart when the plan, state, corrections, and memory all live inside one chat transcript.
GSD-2 moves the center of control outside the harness. It is a standalone CLI built on the Pi SDK, with programmatic control over session lifecycle, dispatch-time context construction, git isolation, crash recovery, cost tracking, and persistent state. Context engineering remains part of the system, now compiled into a larger execution loop.
The main evolution from v1 to v2 is authority. GSD v1 taught the harness how to behave. GSD-2 supervises the run.
This puts GSD-2 in the same architectural conversation as OpenSymphony. In my OpenSymphony launch article, From Spec-Driven Work to Work Orchestration, I argued that agentic engineering is moving from prompt management toward work management. GSD-2 makes that move at the repository level. OpenSymphony makes it at the issue-tracker level.
The Ladder: Runtime, Repository, Tracker
The comparison starts with a simple question: where does the control surface live?
GSD v1 is runtime-local. The coding harness remains the operating surface, with GSD commands, skills, and planning artifacts loaded into that environment.
GSD-2 is repo-local. The repository carries durable workflow state, managed execution state, work isolation, and automation surfaces.
OpenSymphony is tracker-local. Linear issues become schedulable work units, each with its own workspace, conversation, lifecycle, and recovery path.
This maps closely to the taxonomy from my deep-dive Work Orchestration for Agentic Engineering - Part 2: context-based orchestration, external-execution orchestration, persistent workspaces, and programmatic orchestration. GSD v1 mostly lives in the context-based layer. GSD-2 moves into external execution, persistent workspace management, and programmatic control. OpenSymphony extends the same direction, and further into work-system orchestration where tickets and review loops become runtime objects.
What GSD v1 Got Right
GSD v1 attacked the right failure mode. Coding agents lose coherence when complex work stays trapped in a conversation.
Its answer was structured external memory. The agent received project plans, requirements, roadmaps, state summaries, phase context, and execution plans. Fresh executor windows gave each implementation pass a cleaner starting point than a long, degraded transcript.
That made v1 a useful planning discipline for long projects:
Scope: break the project into phases and bounded tasks.
Context: preserve useful state outside the chat.
Execution: give the agent a focused plan for the next pass.
Authority was the tradeoff. V1 could guide the harness through prompts, commands, conventions, and artifacts. Session creation, tool access, write permissions, retry behavior, workspace lifecycle, and recovery still depended heavily on the host runtime and the model following instructions.
Long-horizon work eventually becomes an operating-model problem. GSD v1 made the work legible. GSD-2 starts to make the work governable.
What Changes in GSD-2
GSD-2 treats dispatch as the product.
Auto mode reads durable project state, chooses the next unit of work, creates a fresh agent session, injects focused context, applies phase-specific tool policy, and then reads disk state again before moving to the next unit.
The architecture is in that loop.
The agent still writes code, investigates, fixes tests, and produces artifacts. The supervisor owns the run boundary. It decides what the agent sees, where the agent runs, which files it can touch, when a fresh session starts, when a unit is complete, how crash recovery works, and how the next task is selected.
The GSD-2 DeepWiki summary names the three big differentiators as programmatic control, explicit session and file injection, and persistent state. Those features move GSD’s center of gravity from instruction design to workflow execution.
In v1, the agent’s informational environment was the main artifact. In GSD-2, the workflow unit becomes the main artifact. Context gets assembled for the unit at dispatch time.
State Becomes Operational
GSD-2 turns project state into machine state.
V1’s planning files helped the agent and human understand the project. GSD-2’s state drives routing, resumption, validation, and progression. The docs describe a repo-local state system backed by files and an increasingly authoritative database sidecar. The storage details matter less than the role state now plays: the system can advance work because state participates in execution.
A project with notes can explain itself. A project with a workflow engine can advance.
Work isolation follows the same pattern. GSD v1 had workspace-like concepts, including isolated planning areas and optional worktrees. GSD-2 makes isolation part of the execution model. Work can run in managed git worktrees or branches, with lifecycle commands for creating, resuming, merging, cleaning, and removing those environments.
Persistent workspace orchestration becomes concrete here. The workspace is where a bounded unit of work lives, pauses, resumes, and eventually lands.
Permissions Move from Advice to Enforcement
The security model shows the same evolution.
GSD v1 mostly protected the prompt pipeline. Its public docs focused on path validation, prompt-injection scanning, and hooks around planning artifacts. Those controls fit a system embedded in another runtime.
GSD-2 protects the execution loop. Each unit can carry a tool policy. Planning, execution, validation, and subagent dispatch can receive different permissions. Disallowed writes and unsafe commands become policy errors.
GSD-2 makes no claim to be a container sandbox. Its contribution is narrower and still important: in-band execution permissions replace a large share of advisory behavior rules. As the loop becomes more autonomous, safety needs to live in the supervisor, the tool policy, and the workspace boundary.
The OpenSymphony Comparison
OpenSymphony makes a related move with a different source of truth.
GSD-2 centers the repository. Its work graph lives in repo-local state. GitHub milestones, issues, and PRs can mirror that state outward, while the internal project structure remains the supervised work graph.
OpenSymphony centers the tracker. It polls Linear, decides which issues are eligible to run, creates or reuses one workspace per issue, runs the agent through OpenHands, and exposes a read-only control plane for operators. The issue is the work unit.
That difference changes the product shape.
GSD-2 fits teams that want the repository to carry the plan graph, execution memory, worktree isolation, budgets, and automation surfaces. It is a repo-native autonomous development system.
OpenSymphony fits teams that want to use a project management system as the command surface. It is an issue-native work orchestration system: each issue gets a workspace, a run history, a conversation, retry behavior, review state, and operator visibility.
Both systems move important work out of a single chat transcript. GSD-2 organizes around repository workflow units. OpenSymphony organizes around tracker issues.
Comparison Table
What This Means for Adoption
The adoption question is: where should truth live?
Choose GSD v1 when the goal is to improve existing coding harnesses with a planning method and low migration cost. It works with the tools developers already use.
Choose GSD-2 when the repository should own the workflow. Project state, execution state, isolation, budgets, sessions, and automation all live close to the code. This fits teams that want autonomous execution with the repository as the operating surface.
Choose OpenSymphony when the work tracker should own the workflow. Issues become schedulable, recoverable, inspectable execution objects. This fits teams that want to run engineering through Linear and want the operator to manage issues, review loops, and landing decisions from the work system.
For current GSD users, the move from v1 to GSD-2 is a workflow redesign. Command parity helps, but authority has moved. GSD-2 creates a managed execution environment around the harness and reduces dependence on prompt-driven behavior.
The bigger lesson spans all three systems. Context engineering gave agents better working memory. External execution gave long-horizon work a supervisor. Persistent workspaces made progress survive across runs. Programmatic orchestration turned those pieces into software infrastructure.
GSD-2 matters because it shows that evolution happening inside the GSD lineage itself. The original system proved that explicit project artifacts and phase discipline make agents more useful. The new system turns that discipline into an execution supervisor.
OpenSymphony points one level further out. Once the repository has an execution engine, the next question is whether the issue tracker should become the control plane for the full work loop.
Agentic engineering is heading toward less prompt management, more work management, more durable state, more explicit execution boundaries, and better surfaces for humans to inspect, correct, and land the work.