← Back to Blog Jun 03, 2026 PR #26

PR #26 — v0.3.0: The Multi-Agent Foundation

PR #26 — v0.3.0: The Multi-Agent Foundation

PR: feat: synlynk v0.3.0 — multi-agent foundation
Merged: 2026-06-03
Tests: 60 passing (plus 3 pre-existing gh CLI mock failures, unrelated)

The Broader Goal at the End of v0.2.2

At v0.2.2, the goal was: stable solo workflow for a developer switching between Claude, Gemini, and Codex. The harness provided shared context, cost visibility, and loop detection. The roadmap anticipated a "Lite → Full" tier progression and eventual team mode.

The vision was real but conservative: synlynk as a better context switcher.

The Strategic Shift That Changed the Goalpost

Between v0.2.2 and v0.3.0, three things happened:

1. The hybrid workgroup studies were written. Claude, Gemini, and Codex each independently analyzed the RxCC.me workgroup across ~294 PRs. All three converged on the same four failure modes (context asymmetry, memory asymmetry, manual coordination overhead, no constraint propagation). The studies were not hypothetical — they were empirical analysis of production behavior across hundreds of actual software deliveries.

2. The Trio Protocol design was completed. A full architectural spec was written for rearchitecting synlynk as a workgroup orchestrator: an Architect→Build→Verify pipeline, capability-based routing, domain keyword inference, cold-start round-robin assignment, interactive TUI review, and async dispatch via a background daemon. The spec documented not just what to build but why each decision was made and what the alternatives were.

3. The OS metaphor crystallized. The v1.0 architecture design session mapped synlynk's evolution to OS primitives — kernel, filesystem, IPC, scheduler, shell, ecosystem interface. The framing recast everything: synlynk is not a workflow tool on top of the existing OS; it is the OS that agents run on.

These three events together shifted the goalpost from "stable Lite tool" to "workgroup orchestrator on a path to autonomous dispatch." v0.3.0 was the first release designed with that destination in mind.

What This PR Shipped

AGENTS.md — third agent, first-class support

v0.2.x generated CLAUDE.md and GEMINI.md. Codex (OpenAI CLI) had no instruction file. v0.3.0 adds AGENTS.md, generated alongside the other two.

This matters structurally, not just cosmetically. The constraint propagation failure mode — organizational constraints not reaching all agents — requires that every agent has an instruction file that the harness generates from the same source of truth. Adding AGENTS.md closes the gap for Codex.

The three instruction files become the harness's primary IPC mechanism in the flat-file era: instead of message-passing between agents, the harness writes the shared constraints once and all agents read their own copy at session start.

synlynk init flags — parametric initialization

Four new flags:

synlynk init \
  --agents claude,agy,codex \      # which agent files to generate
  --mode solo|team \               # written to .synlynk_config.json
  --org <github-org> \             # stored in .synlynk/config.json
  --repo <repo-name> \             # stored in .synlynk/config.json
  --project-id <PJ_kwDO...>        # fills PROJECT_ID placeholder in all agent files

The --project-id flag is the most consequential. GitHub Projects v2 uses opaque node IDs (PVT_* for projects, PJ_kwDO* for project items). These IDs are required for the GraphQL mutations that move board items. Previously, agent instruction files contained TODO: PROJECT_ID placeholders that the user had to manually fill in.

With --project-id, the harness fills the placeholders at init time, and the agent instruction files contain live, usable GraphQL blocks immediately:

mutation MoveItem {
  updateProjectV2ItemFieldValue(input: {
    projectId: "PJ_kwDOA1234"    ← filled by synlynk init
    itemId: "<item-node-id>"
    fieldId: "TODO: STATUS_FIELD_ID"
    value: { singleSelectOptionId: "TODO: IN_PROGRESS_OPTION_ID" }
  }) { projectV2Item { id } }
}

This is a small but meaningful step toward autonomous board management: the agent has a live GraphQL block it can execute, not a template it has to fill in manually.

The v0.3.0 Pivot: Solo Tool → Workgroup OS

Enriched agent instruction templates

The session protocol in all three agent files was significantly expanded:

Live Issues SOP. A full escalation framework — Sev1 (core broken / data loss → full RCA doc), Sev2 (major feature degraded → comment-level RCA), Sev3 (minor UX → no RCA required). With a process: Declare → Investigate → Post findings → Write RCA (Sev1) → Action tickets → Resolution comment → Close.

Git Worktree-First Policy. Every feature requires a dedicated worktree: git worktree add ../feat+<name> feat/<agent-prefix>/<name>. Branch current confirmed before every commit. No commits on main, no reuse of a worktree checked out to a different feature's branch.

Mid-Session Anti-Amnesia Protocol. Phase 1 (context ≤ 75%): every ~25,000 tokens, write devlog entry + memory update. Phase 2 (context > 75%): every ~5,000 tokens, same plus a ⚠️ Compaction imminent: rescue bullet listing open threads and "about to do X" states.

Mandatory 4-Doc Discipline. All four docs (roadmap, devlogs, costs, memory) updated during the session — not only at session end. Specifically: any numbered list of fixes, options, or recommendations written to devlog in the same response that presents them, not later.

GitHub Projects v2 GraphQL integration block. A complete, parameterized example for moving board items and looking up field/option IDs via the GraphQL API.

These are not suggestions injected into a README. They are the behavioral contract encoded in the agent's primary instruction file — the file the agent reads at session start, every session, without exception.

_build_templates() — parametric template generation

Internally, the static TEMPLATES dict and _SESSION_PROTOCOL string were replaced by _build_templates(org, repo, project_id). This function returns the complete template dictionary with all values filled in from the provided parameters.

This refactor is load-bearing for v0.4.0's migrate() command: a repo that already has agent instruction files needs semantic section matching to identify what's already covered and what needs to be added. That matching works against template sections, which must be generated from parameters that vary per repo. A static dict cannot support this.

The Brainstorm Behind This Release

The Trio Protocol design was a full brainstorming session documented in the spec at docs/superpowers/specs/2026-06-01-synlynk-trio-protocol-design.md. The key design decisions:

Decision Choice Reasoning
Role assignment Emergent from usage Routing earned by data, not assumed by vendor identity
Primary interaction Autonomous dispatch Human reviews the result, not each sub-task
Cold-start routing Round-robin Systematically generates diverse score data
Phase failure Auto-retry once, then halt Minimizes human interruption for transient failures
Score decay Recency-weighted Agent improvement surfaces in routing within ~3–4 jobs

The gap analysis that preceded this spec surfaced the core strategic insight: the roadmap was building a better solo dev assistant. The studies described a workgroup coordinator. The difference was not one feature — it was a different conceptual model of what synlynk was for.

What This Achieved on the Path to Autonomy

v0.3.0 is the foundation layer for multi-agent coordination:

  1. Instruction file parity. All three major agent CLIs now have a harness-generated instruction file. Constraint propagation can now reach all agents — the architectural prerequisite for the constraint system in v0.6.0.

  2. GitHub Projects v2 integration. The --project-id flag and the GraphQL block in agent instruction files establish the board as the coordination layer. synlynk start in v0.4.0 builds directly on this: it reads the cached field IDs and moves board items autonomously.

  3. Behavioral contracts formalized. The enriched templates turn session protocols from developer suggestions into formalized agent contracts. The Anti-Amnesia Protocol and 4-Doc Discipline, in particular, directly address the memory asymmetry failure mode.

  4. Parametric template generation. _build_templates() is the infrastructure that makes migrate() possible in v0.4.0 — the ability to analyze an existing repo's agent files, identify what sections are present, and append only what's missing.

Strategic Note: The Goal Moved

The goal at the end of v0.3.0 was no longer "stable solo workflow." It was:

Workgroup orchestrator on a path to full autonomy. The OS for multi-agent development. synlynk = the local OS client. Tokq = the distributed backend. Stable v1.0 in Q1 2027, Tokq Alpha bridge in Q3 2027.

The three studies, the Trio Protocol spec, and the v1 architecture design session together constituted the first complete articulation of what synlynk was eventually building toward. The Solo/Team/Enterprise tier model was retired. The OS layer model — Kernel → Filesystem → IPC → Scheduler → Shell → Ecosystem Interface — replaced it.

v0.3.0's code is modest — enriched templates, four new init flags, a refactored template generator. But the release marks the moment when the product knew what it was building.

Next: PR #27 — v0.4.0: The Autonomy Driver — synlynk migrate and synlynk start: the first autonomous board management and the first steps toward hands-off dispatch.

← Back to all posts