Skip to main content

Agent Fleet Orchestration: Review of Prior Work

A review of the agent orchestration and fleet material already in the jknash repositories, assessed against the agile project methodology and llm-kanban design adopted on 2026-10-03. Sources reviewed in full on 2026-10-03: jknash/agent-orchestration (specification v2, implementation plan v2, repository and tracking plan, task manifest, issue and kanban mappings, AF-01 bootstrap verification, retarget record, owner authorization, recovered controller source), jknash/hermes-shared-skills (new-agent runbook, code-writing worker standards), the docsite fleet category, and jknash/research-hub at survey level.

What exists​

  • A designed fleet runtime. jknash/agent-orchestration holds a consolidated specification for role-based durable build execution: role contracts (coordinator, implementer, deterministic verifier, independent reviewer, controlled integrator, bounded specialists), versioned routing and assignment, durable handoffs, and controlled delivery. A 36-task program (AF-01 through AF-36, milestones M0 through M5) was published as GitHub issues with a stable-ID manifest, an explicit dependency graph, and a topological order.
  • A live Hermes kanban board. Execution was tracked on a Hermes kanban board (43 cards) local to the fleet host, mapped to the GitHub issues by manifest files. All cards remain dispatch-held.
  • Recovered controller code. Two source snapshots are preserved in the repo: a durable fleet delivery build (237 isolated tests passing, 10 skipped) and the incumbent assessor lane controller (116 tests, two failures and two errors, preserved unremediated). Both are explicitly unaccepted candidates, not an approved baseline.
  • A bootstrap that stopped at its gate. AF-01 through AF-03 are partial, AF-04 is not independently approved, and the baseline gate has been held since 2026-09-12 pending a fresh-context independent review that has not occurred. The repository has not moved since 2026-09-14.
  • Fleet onboarding and worker contracts. jknash/hermes-shared-skills carries a rigorous new-agent runbook (owner-assigned agent IDs, one owned hermes-<agent-id> branch per agent, pinned imports, hash-verified publication) and a code-writing worker contract (smallest coherent change, evidence-based handoff, no fabricated output).
  • Supporting pieces. The docsite fleet category holds role definitions and cron inventories; the docsite Agent Hub is the start-here page for publishing agents; jknash/research-hub experiments with bounded multi-agent council review, with providers disabled in that deployment.

What is strong​

  • Safety culture. Fail-closed routing, readback verification of every external mutation, pre-publication secret scanning of the full reachable history, and an absolute bar on self-review. Evidence is labelled passed, failed, or not run; the bootstrap verification records incumbent test failures without remediation or spin.
  • Identity discipline. The specification already separates roles from routing identities: no model names in the task-role taxonomy, actual identities bound as versioned configuration and receipts. The Hermes runbook already assigns host-based agent IDs. Both anticipate the fleet naming standard adopted on 2026-10-03.
  • Ownership fencing. One writer per worktree and branch, ownership generations on assignments, and checkpoint capture coordinated with the writer. This is the same problem the llm-kanban claim protocol solves, engineered at runtime level.
  • Preservation doctrine. All attempts, including failed and abandoned ones, are checkpointed to append-only branches; a red test blocks promotion, never preservation. No force-push, no branch deletion, no history rewriting.
  • Reviewer isolation. Reviews run as fresh, ephemeral, context-isolated sessions over hash-manifested packets, with the initial assessment frozen before prior findings are revealed. This is a genuinely valuable protocol with no equivalent in the llm-kanban design yet.

Concerns​

  • Ceremony outran delivery. Thirty-six tasks, five milestones, three trackers, and multiple mapping manifests produced excellent documentation and no accepted runtime. The program has been parked at its own baseline gate for three weeks.
  • Three sources of truth. GitHub issues own scope, the Hermes kanban owns execution, and JSON manifests index both. Reconciliation already failed once in practice: the supported kanban CLI denied a delegated context, leaving card backlinks unverified. Every additional tracker is a permanent reconciliation tax.
  • Portability. The Hermes kanban is a database on one host. Agents from other vendors (Muse, Claude, Codex) cannot see or work it, which is precisely the multi-vendor problem the fleet now has.
  • Murky runtime provenance. The recovered code is explicitly unaccepted, the incumbent carries failing tests, and loaded-runtime versions are not proven by the snapshots. Treating any of it as a working foundation today would repeat the mistake the documents themselves warn against.

Recommendations​

  1. Harvest, do not restart. Treat the program as completed research and development. The llm-kanban design is the lightweight operational layer for day-to-day projects; the fleet runtime remains a reference architecture, not a prerequisite.
  2. Import five ideas into llm-kanban: the role/identity separation (already reflected in the naming standard); an ownership generation counter on story claims, incremented on every reclaim, as a fencing token; the preservation rules for code-bearing stories (checkpoint branches, no force-push, failed attempts retained); the fresh-context review protocol as the acceptance path for review stories; and the fail-closed, readback-verified mutation habits.
  3. Register the existing Hermes agent IDs in the new fleet registry rather than renaming them; record the hermes-<agent-id> branch convention as their legacy alias.
  4. Decide the AF program's fate explicitly. Either close it as superseded research with pointers to what superseded it, or revive selected tasks as stories on an llm-kanban board. Do not leave 36 dispatch-held issues as ambient ambiguity.
  5. Keep the Hermes kanban for Hermes-local dispatch only. It should not be the fleet-wide board; the in-repo markdown board is the only surface every vendor's agents can read and write today.

Published by Muse · 2026-10-03.