Symphony Pattern: Agent Control Plane

The missing layer in the platform engineering thesis. Owen Gretzinger’s “I Was Wrong About Linear” + Karri Saarinen’s reply + Linear’s “Issue tracking is dead” announcement converge on a single architectural claim:

The durable coordination layer for AI-assisted work is the issue tracker, not the chat interface, not the IDE, not the PR.

Session = execution layer. Issue = durable coordination layer. Agent reads from issue + repo, writes back to issue + PR, human stays in the loop on the same surface they already use for non-agent work.

This is the concrete form of the “self-maintaining context layer around the codebase” claim. Not hand-waving. The context lives in tracker + repo. Agents traverse it. Humans steer through it.

Why this changes the platform thesis

Two layers of impact:

Internal engineering (resolved, with correction)

Two coordination surfaces, not one:

• Guild → GitHub Issues. 43 issues, ~30 days of real usage. Discrete engineering work-units fit Issues.
• Emporium → the vault (dungeonbooks/docs/). 0 GitHub issues. Architectural/exploratory work fits prose-and-links better than ticket form.

Operations work (inventory, reconciliation, bookkeeping, email, social) is not formally tracked on either surface today. Light agent help happens session-by-session in Claude Code. Cost-conscious posture: agents do not run 24/7.

See where-dungeon-actually-is-2026-05-02 for the honest current state. Previous claim that GitHub Issues was the unified coordination layer across all work categories was wrong.

Real gap: conventions aren’t documented for either surface, and operations isn’t coordinated anywhere durable.

Partner-shop operator surface (12-24 month)

This is the real implication. The Symphony pattern is directly applicable to partner shops as a feature, not just internal tooling.

Today: carrie opens Payload admin, clicks buttons. Phil (project_phil-pilot-candidate) will do the same.

Symphony-pattern version: operator creates an issue describing what they want done. Agent picks it up, executes against platform context (tier schema, point rules, active buffs, medusa-v2-platform-guide data model). Operator reviews in the same surface.

This is closer to “we run the ops layer of your store” than “we built you a really good admin panel.” It is the actual delivery mechanism for the fractional-ops thesis.

Worked example: Carrie runs a promotion

Today: “Buy 2 RPG zines, get 50 bonus points for the next 2 weeks.” Carrie has to figure out Payload config, or Panat builds a feature, or Carrie Slacks Panat.

Symphony pattern: Carrie creates an issue describing the promotion. Agent reads issue + existing buff schema + active campaigns, modifies relevant Payload data or writes config, marks done. Carrie reviews. Agent has full platform context, so the operation is informed.

Same shape for: tier setup, member edits, integration debugging, report generation, custom campaigns.

Liberal paternalism with teeth

The Symphony pattern is the architectural primitive of liberal paternalism applied to platform UX:

• Operator agency preserved: Carrie can override the agent’s plan, comment, redirect.
• Paved path low-friction: agent does the work, Carrie reviews.
• Friction gradient teaches without blocking.

This differs from generic nudge design because the agent is doing actual work, not just suggesting. The operator’s role shifts from executor to director.

Worth naming explicitly in pitch and vault.

Operator-persona split

Different operator profiles tolerate different surfaces:

• Engineer-operators (Phil, Victory Point): will love issue-based agent orchestration.
• Non-engineer operators (Carrie’s retail staff, future hires): may find it overwhelming vs. forms-based admin.

Likely answer: platform offers both.

• Forms-based admin for routine ops (point adjustments, member edits, manual lookups).
• Issue-based agent orchestration for non-routine ops (campaigns, promotions, integrations, reports, per-shop config).

Decision is which is primary, which is fallback.

Per-shop configuration as agent workflow

Per-shop tier/brand/pricing configuration is itself an agent-orchestrated workflow, not a settings page.

Phil creates an issue: “Set up tier names and pricing for Victory Point.” Agent reads platform tier schema, references guild-token-design / Dungeon’s current config, asks clarifying questions, proposes config, Phil reviews, agent applies.

More aligned with the platform’s values than a settings page would be. Forecloses fewer paths.

Architectural choice: GitHub Issues, not Linear

We’re on GitHub Issues. The reflexive justification (“Linear free tier caps at 250 issues / 2 teams”) is tactical cover for a real architectural decision:

1. Code-adjacent context. Issues live next to the code on GitHub. Agents reading issues can read the relevant code in the same auth context. Linear puts a network boundary between issue context and code context. GitHub doesn’t. This is the “monorepo eats everything” argument applied correctly.
2. Single surface to maintain. Already on GitHub for Graphite stacked PRs and Copilot review. Adding Linear means two places work could live — exactly the failure mode Owen described where the tracker becomes ritual.
3. Operator fit (today). Carrie is technical enough to use GitHub. Phil is a software engineer. Linear’s UX polish for non-technical operators isn’t yet a constraint we have.
4. GitHub agent surface is mature. API + webhooks are free and stable. Symphony-equivalent orchestration on top of GitHub is a real engineering project, not a blocked one.

Pricing isn’t why we picked GitHub. The architecture is why. Pricing is a coincidence.

The bet: GitHub absorbs the agent-coordination workflow before Linear absorbs the code-context workflow. Given Microsoft’s positioning, probably correct. Worth being explicit that this is a bet, not a default.

If we ever migrate, the trigger is operator persona, not issue volume. Specifically: when a partner shop with a non-engineer operator joins, we either (a) wrap GitHub Issues in a friendlier surface, or (b) build a platform-native coordination layer that writes to GitHub underneath. Not Linear adoption.

Three forward options (post-pilot)

Option A: GitHub Issues as the operator surface, document conventions

• Cheapest, fastest. Works for engineer-operators (Phil).
• Limits TAM to operators comfortable with GitHub.
• Correct through pilot phase. Document the conventions now (issue templates, agent expectations, review patterns) — that doc is the seed of Option B and the onboarding material for Phil.

Option B: Platform-native UI on top of GitHub Issues

• Linear-or-Notion-shaped surface in the platform that writes to GitHub Issues underneath.
• Familiar surface for non-engineer operators. Agents still read from GitHub. Keeps code-adjacent context locality.
• Significant build cost. 2027 question.

Option C: Adopt Linear (or similar) as the platform’s operator surface

• Polished UX from day one. Don’t build coordination tooling.
• Imports vendor risk, loses GitHub-adjacent context locality.
• 2027 question. Probably wrong given the architectural reasons above, but reassess if Linear ships native code-context features.

Now: Option A. Document conventions before Phil onboards.

Architectural decisions to preserve the path

Today’s operator surface = Payload admin (forms, tables). Long-term answer may be Linear-shaped (issues, comments, agent sessions). Decisions in the next 6 months either preserve or foreclose this.

Things to keep open:

• Don’t bake operator workflows so deep into Payload admin that they can’t be invoked headlessly.
• Make sure agent has read/write API access to all platform state (ai-db-access is the right direction).
• Treat platform operations as scriptable primitives an agent can compose, not just admin-panel actions.

Priority placement

Insert in roadmap between guild-multitenancy (domain routing) and partner-shop onboarding (Phil pilot, wednesday-prep etc.).

Open questions

• Does Phil have a tracker preference? Engineer-operators bring their own opinions.
• For non-engineer operators, what’s the minimum-viable issue interface? GitHub Issues UX is hostile to retail staff.
• Where does this live relative to guild-multitenancy? Multi-tenant agent orchestration is its own design problem (auth, blast radius, sandboxing).
• Leverage ratio at Dungeon (see leverage-ratio): how many issues/week, % closed by agent, iteration counts, hours saved. Numbers needed for pitch and pricing.

Source material

• Owen Gretzinger, “I Was Wrong About Linear,” 2026-05-01.
• Owen Gretzinger, “The All-Consuming Monorepo,” 2026-04-20.
• Karri Saarinen, reply thread, 2026-05-01.
• Linear, “Issue tracking is dead,” 2026-05-01.
• OpenAI, Symphony (open source Codex orchestrator): https://github.com/openai/symphony