core/go-agentic
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Page: Fleet Delegation Pattern
Pages
Allowance Clotho Agent Contributing From Linux Fleet Delegation Pattern Home Inference Architecture Platform Matrix Service-Lifecycle
2 Fleet Delegation Pattern
Claude edited this page 2026-02-19 20:05:22 +00:00
Table of Contents

Fleet Delegation Pattern

How we run multiple domain-expert AI agents across the Core Go ecosystem.

The Pattern

Each core/go-* repo gets three files that form the agent contract:

File Purpose Who Writes Who Reads
CLAUDE.md Build commands, architecture, coding standards, dependencies Virgil (orchestrator) Dedicated agent
TODO.md Phased task queue with checkboxes Virgil dispatches, agent marks done Both
FINDINGS.md Research notes, discoveries, decisions, cross-session context Dedicated agent Virgil + other agents

Why This Works

  • No shared state — Each agent owns its repo end-to-end. No merge conflicts.
  • Async coordination — Virgil writes tasks to TODO.md, agent picks them up next session.
  • Cross-session memory — FINDINGS.md survives context window resets. New sessions read it to resume.
  • 4th wall safety — CLAUDE.md refers to "Virgil in core/go" as the orchestrator. Agents don't need to know they're AI — they just follow the task queue.

Roles

Virgil (Orchestrator)

  • Model: Claude Opus 4.6 (macOS, M3 Ultra)
  • Owns: core/go (framework), architecture decisions, cross-repo coordination
  • Does: Reviews plans, dispatches tasks to TODO.md, updates MEMORY.md, creates Forge repos
  • Pattern: Reads FINDINGS.md from all repos, synthesises cross-cutting concerns

Charon (Linux Orchestrator)

  • Model: Claude Opus 4.6 (Linux homelab, snider-linux, RX 7800 XT)
  • Owns: Linux environment setup, fleet orchestration for Linux packages, plan review
  • Does: Environment prep (ROCm, llama-server, tooling), dispatches to dedicated Claudes per package, reviews plans, updates wiki
  • Pattern: Prepares CLAUDE.md/TODO.md/FINDINGS.md with environment findings, opens IDE for dedicated agents, reviews their plans before they implement

Dedicated Repo Agents

  • Model: Varies (Claude, Gemini, etc.)
  • Owns: Single repo end-to-end
  • Does: Implements TODO.md tasks in phase order, writes FINDINGS.md
  • Pattern: Self-contained, doesn't need to know about other agents

Current Fleet

Agent Platform Repos Status
go-i18n Claude macOS core/go-i18n Phase 3 in progress
go-mlx Claude (Go) macOS core/go-mlx Phase 4 queued (backend abstraction)
go-mlx Claude (C++) macOS/CLion core/go-mlx/cpp mlx-c binding work
go-rocm Claude Linux/GoLand core/go-rocm Phase 0 done, Phase 1 plan pending
go-p2p Claude Linux core/go-p2p Pending (after go-rocm stabilises)
go-rag Claude Linux core/go-rag Pending (after go-rocm stabilises)

Onboarding a New Agent

  1. Virgil creates the Forge repo (or splits from existing code)
  2. Virgil writes CLAUDE.md (build commands, architecture, standards)
  3. Virgil writes TODO.md (phased tasks, dependencies noted)
  4. Virgil writes FINDINGS.md (initial research, context from split)
  5. Push to Forge via SSH
  6. New agent clones, reads all three files, starts Phase 1
  7. Agent marks tasks [x] as done, adds discoveries to FINDINGS.md
  8. Virgil reviews via FINDINGS.md + git log, dispatches next phase

Cross-Platform Coordination

When macOS and Linux agents work on related packages (e.g. go-mlx + go-rocm both implementing go-inference):

  1. Shared interface in go-inference — Virgil manages, both backends import
  2. TODO.md cross-references — "Blocked on go-mlx Phase 4" or "Depends on go-inference v0.1.0"
  3. FINDINGS.md exchange — Virgil reads both, identifies conflicts or opportunities
  4. This wiki — Shared knowledge about the fleet pattern itself