Skip to content
/
Tier A A8 Cross-runtime harness

Aigon

aigon · jayvee/aigon · ★ 10 · last commit 2026-05-25

Orchestrates 7 different AI coding agent CLIs from a single Kanban workflow with per-feature worktree isolation, Fleet mode for parallel agent comparison, and a local web dashboard.

Best whenAgent CLIs are interchangeable engines — vendor-neutral spec-driven orchestration outlasts any single subscription.
Skip ifPutting model names or effort levels in spec files, Running Fleet mode without committing the spec
vs seeds
openspecwhich focuses on spec authoring, Aigon manages the full lifecycle from inception through PR merge. Unlike superpowers (b…
Primitive shape 35 total
Commands 35
00

Summary

Aigon — Summary

Aigon is a spec-driven multi-agent harness for orchestrating Claude Code, Gemini CLI, Codex CLI, Cursor, OpenCode, Kimi, and Amp from a single Kanban board, CLI, or slash command — running each agent in its own git worktree under tmux with shared Markdown spec files.

Problem it solves: Developers using multiple AI coding agents face fragmented workflows, lost context, and no unified view of feature progress; Aigon provides a single inbox → backlog → in-progress → review → done lifecycle over plain Markdown specs that persists across agents and sessions.

Distinctive trait: Agents are interchangeable engines — Aigon orchestrates the workflow and lifecycle around them; if one vendor's subscription lapses or a model underperforms, you switch agents without losing the spec or the branch.

Target audience: Power users and teams who pay for multiple AI coding subscriptions and want to coordinate them on real branches in real worktrees, with a local Kanban dashboard for visibility, a CLI for terminal workflows, and slash commands for in-agent use.

Production-readiness: Beta (v2.66.0-beta.2); maintained by Sen Labs with 10 stars; early-access commercial product with a free open-source core (Drive, Fleet, dashboard, telemetry) and a Pro tier (AutoConductor autonomous orchestration, deep analytics, AI-powered coaching) in private beta.

Differs from seeds: Aigon is closest to taskmaster-ai in its structured task lifecycle and CLI-centric operation, but differs fundamentally in supporting heterogeneous agent pools (7 different CLI tools) with per-feature worktree isolation, Fleet mode for parallel agent racing, and a local web dashboard. Unlike openspec which focuses on spec authoring, Aigon manages the full feature lifecycle from inception through PR merge. Unlike claude-flow which bundles an MCP server with 305 tools, Aigon delegates execution entirely to the agent CLIs it orchestrates and stores all state as Markdown specs in git.

01

Overview

Aigon — Origin and Philosophy

Origin

Aigon is built by Sen Labs (senlabs.ai), founded by "john@aigon.build". The npm package is @senlabsai/aigon. Documentation lives at aigon.build. Note: aigon.ai is an unrelated privacy-focused AI agents company (Sen Labs' product is at aigon.build).

Core philosophy (from README)

"Aigon is a spec-driven harness for orchestrating multiple AI coding agents on the same codebase. Each feature is a Markdown spec in git; each agent runs in its own git worktree under tmux; the lifecycle moves through inbox → backlog → in-progress → review → done on a local Kanban board."

On vendor independence:

"Bring your own subscriptions — use the AI products you already pay for (Claude, Codex, Gemini, Cursor, OpenCode, Kimi, Amp); no separate Aigon billing, no token packs, no markup."

"Stay in the flow when a subscription lapses — switch agents or accounts mid-session instead of being stuck on one vendor's meter."

On spec-driven development:

"Context that compounds — specs and implementation summaries feed forward into later work, so context accrues in the repo rather than evaporating with a session."

Supported agents

Shortcode Agent
cc Claude Code
gg Gemini CLI
cx Codex CLI
cu Cursor
op OpenCode
km Kimi Code CLI
am Amp

Three surfaces

  1. Dashboard — local web app at localhost:4100; Kanban + Monitor + Reports + Telemetry
  2. Slash commands — inside any agent: /aigon:feature-create, /aigon:feature-start, /aigon:feature-now, etc.
  3. CLI — aigon feature-create, aigon feature-start, aigon feature-eval, etc.

Execution modes

  • Drive — single agent, interactive conversation, worktree-isolated
  • Fleet — multiple agents race the same spec in parallel; you evaluate and pick the winner
  • Autopilot — long autonomous loops (Pro tier with AutoConductor)
02

Architecture

Aigon — Architecture

Distribution

  • Type: npm package (@senlabsai/aigon)
  • CLI binary: aigon (installed globally via npm install -g @senlabsai/aigon@next)
  • Source: https://github.com/jayvee/aigon
  • Version analyzed: v2.66.0-beta.2
  • License: Apache-2.0

Install

npm install -g @senlabsai/aigon@next
aigon setup         # first-time: installs agent CLIs, configures terminal, starts dashboard
cd /path/to/project
aigon apply         # bootstraps .aigon/, kanban folders, hooks
aigon install-agent cc   # install Claude Code agent adapter
aigon doctor        # verify environment

Required runtime

  • Node.js >= 18
  • Git 2.20+
  • tmux (for Fleet/worktree mode)
  • At least one agent CLI (cc, gg, cx, cu, op, km, or am)

Directory structure (after aigon apply)

your-project/
├── .aigon/
│   ├── config.json          # Per-project settings (agents, models, complexity defaults)
│   ├── config-hash          # Integrity check for config
│   ├── docs/                # Internal aigon documentation
│   ├── git-hooks/           # Hooks installed to .git/hooks/
│   ├── benchmarks/          # Benchmark results
│   ├── matrix-refresh/      # Agent matrix refresh data
│   └── version              # Installed aigon version
├── .claude/
│   ├── commands/            # Slash commands for Claude Code (35+ commands)
│   └── skills/              # Skills for Claude Code agents
├── .agents/                 # Agent-specific configurations
├── .codex/                  # Codex CLI config
├── .cursor/                 # Cursor config
├── .gemini/                 # Gemini CLI config
├── .opencode/               # OpenCode config
├── .mcp.json                # MCP server config
└── docs/
    └── specs/
        ├── features/
        │   ├── 01-inbox/    # Newly created specs
        │   ├── 02-backlog/  # Prioritized, awaiting start
        │   ├── 03-in-progress/<feature-id>/  # Active work
        │   ├── 04-in-evaluation/  # Ready for review
        │   └── 05-done/    # Completed
        └── research/
            └── (same lifecycle structure)

Local dashboard (web)

  • Port: 4100
  • Stack: Next.js + React (docs site); server-side: Node.js + Express
  • Features: Kanban board, Monitor (live agent status), Reports (cycle time, rework ratio, commits per feature), Telemetry (token spend per agent), All Items index
03

Components

Aigon — Components

CLI binary: aigon

Major subcommand families:

Category Commands
Feature feature-create, feature-prioritise, feature-start, feature-eval, feature-review, feature-push, feature-close, feature-cleanup, feature-reset, feature-transfer, feature-now, feature-open, feature-do, feature-code-review, feature-code-revise, feature-spec-review, feature-spec-revise, feature-unprioritise, feature-autonomous-start
Research research-create, research-start, research-do, research-eval, research-close, research-open, research-prioritise, research-unprioritise, research-reset, research-spec-review, research-spec-revise, research-autopilot
Feedback feedback-create, feedback-list, feedback-triage
Server server-start, server-stop, server-restart, server-status
Setup setup, apply, install-agent, doctor, global-setup
Utility next, board, sessions-close, set-prioritise

Slash commands (Claude Code — .claude/commands/aigon/)

All 35+ commands under /aigon: namespace including:

  • /aigon:feature-now <name> — one-command: create spec + start implementation
  • /aigon:feature-create — create spec interactively
  • /aigon:feature-start — start Drive or Fleet mode
  • /aigon:feature-eval — evaluate Fleet results and pick winner
  • /aigon:board — show Kanban state
  • Plus full research lifecycle commands

Shortened slash commands (.claude/commands/*.md)

Abbreviated aliases:

  • /afc — feature-create
  • /afs — feature-start
  • /afe — feature-eval
  • /afr — feature-review
  • /afd — feature-do
  • /afn — feature-now
  • /arc — research-create
  • (etc.)

Skills (.claude/skills/aigon/)

Agent skills for integration with Claude Code autonomy system.

Config files

  • .aigon/config.json — per-project: agent models per complexity level, worktree setup command, validation command, security mode, GitHub PR checks
  • CLAUDE.md / GEMINI.md / AGENTS.md — per-agent context injection files

Spec format

Plain Markdown with YAML frontmatter:

  • complexity: — low/medium/high/very-high (drives model/effort defaults)
  • planning_context: — path to plan file (injected at implementation start)
  • Sections: Technical Approach, Dependencies, Acceptance Criteria

MCP integration

.mcp.json present — MCP server configuration for agent integration.

05

Prompts

Aigon — Prompt Files (Verbatim Excerpts)

Excerpt 1: Feature-create slash command (.claude/commands/afc.md)

Technique: Spec scaffolding with complexity rubric and plan-mode integration

---
description: Create feature <name> - creates spec in inbox (shortcut for feature-create)
argument-hint: "<feature-name>"
---
# aigon-feature-create

Run this command followed by the feature name.

```bash
aigon feature-create {{args}}

Before writing the spec

Tip: If you are running this command in your own Claude Code session (no --agent flag), press Shift+Tab now to enter plan mode before drafting — this keeps your session read-only while you explore the codebase and propose the spec.

Explore the codebase to understand the existing architecture, patterns, and code relevant to this feature. Plan your approach before writing. Consider:

  • What existing code will this feature interact with?
  • Are there patterns or conventions in the codebase to follow?
  • What technical constraints or dependencies exist?

Set the spec frontmatter

complexity: (required) — drives the per-agent {model, effort} defaults in the dashboard start modal, resolved from each agent's complexity-defaults table and then aigon config. Do not put model names or effort levels in the spec; those SKUs change over time and belong only in agent config.

Use this rubric:

  • low — config tweaks, doc-only changes, single-file helpers, trivial bug fixes.
  • medium — standard feature with moderate cross-cutting; one command handler.
  • high — multi-file changes, new public surfaces, judgment-heavy deletion work.
  • very-high — architectural shifts, write-path-contract changes, new workflow transitions.

planning_context: (set this when you ran plan mode) — if you entered plan mode (EnterPlanMode / Shift+Tab) before writing this spec and a plan file was written to ~/.claude/plans/, set this field to that path:

planning_context: ~/.claude/plans/your-plan-file.md

The implementing agent will read the plan before writing any code, and the content is copied into the implementation log at start time so it's durable even if the plan file is later deleted.

After writing the spec

Commit the spec file:

git add docs/specs/features/01-inbox/
git commit -m "feat: create feature spec - <name>"

Next step: Once the spec is committed, suggest /aigon:feature-prioritise {{args}} to assign an ID and move to backlog.


## Excerpt 2: CLAUDE.md excerpt (Aigon's own project configuration)

Technique: **Self-referential spec-driven config — Aigon uses its own workflow for its own development**

```markdown
# CLAUDE.md

This file provides guidance to Claude Code when working in this repository.

[SetupProject] instructions and project-specific commands are in `.aigon/config.json`.
Use `/aigon:feature-now` to start a feature. Use `/aigon:board` to see the Kanban.

Model routing: For `cc` agent at `high` complexity, use `opus`. The `implement.model`
field in `.aigon/config.json` overrides the global default.

Prompting techniques observed

  1. Complexity decoupling — spec stores semantic complexity (low/medium/high/very-high), not model names; agent config maps complexity to model/effort, protecting specs from LLM SKU churn
  2. Plan-mode integration — planning_context field bridges Claude Code's plan mode output into the spec, making the plan durable and discoverable by the implementing agent
  3. CLI-command-in-prompt — commands are literal aigon feature-create {{args}} invocations that the agent runs; slash command is a thin wrapper that delegates to the CLI
  4. Post-spec commit instruction — explicit git commit step in the prompt ensures the spec enters version control before any implementation starts
09

Uniqueness

Aigon — Uniqueness and Positioning

Differs from seeds

Aigon is closest to taskmaster-ai in its structured task/feature lifecycle and CLI-centric operation, but extends the concept in three distinct dimensions: (1) multi-agent Fleet mode — the same spec can be executed by 2+ agent CLIs racing in parallel worktrees, with user-evaluated comparison; (2) agent-agnostic orchestration — the harness supports 7 different CLI tools interchangeably, routing model selection through complexity levels rather than hardcoding vendors; (3) local web dashboard with real-time tmux integration. Unlike openspec (spec authoring per feature), Aigon manages the full feature lifecycle from inbox to merged PR. Unlike superpowers (skills-based behavioral injection), Aigon is a standalone CLI harness that wraps agent CLIs rather than augmenting Claude Code's behavior. Unlike claude-flow (MCP server bundling 305 tools), Aigon has no bundled MCP tools — it delegates all execution to the agent CLIs and manages workflow around them.

Positioning

Aigon targets developers who: (a) have multiple active AI coding subscriptions and want to use them without per-vendor context fragmentation; (b) want to empirically compare agent quality on real features (Fleet mode); (c) need a Kanban-visible project lifecycle that persists in git. The key competitive bet is that vendor-neutral orchestration over plain Markdown specs will outlast any single AI coding subscription.

Observable failure modes

  1. Dependency on agent CLIs — Aigon's value is 100% contingent on the quality of the underlying agent CLIs; a regression in claude/gemini/codex degrades Aigon outcomes
  2. tmux dependency — Fleet mode requires tmux; limited on Windows without WSL
  3. Beta instability — v2.66.0-beta.2 with 10 stars; API/config formats may change between releases as stated in README
  4. Pro tier opacity — AutoConductor and Insights are invitation-only; free tier lacks autonomous end-to-end execution
  5. Spec quality dependence — feature outcomes depend on spec quality; no built-in requirement-gathering interview (unlike Tessl's one-question-at-a-time skill)

Explicit antipatterns

  • Putting model names or effort levels in spec files (they belong in agent config)
  • Running Fleet mode without committing the spec first
  • Using aigon without aigon doctor on first install (environment issues)
04

Workflow

Aigon — Workflow

Feature lifecycle phases

Phase Kanban column What happens
Inception 01-inbox aigon feature-create or /aigon:feature-now creates spec Markdown; agent interviews user for requirements
Prioritization 02-backlog aigon feature-prioritise assigns ID, moves spec to backlog
Execution 03-in-progress/<id> aigon feature-start <name> cc (Drive) or aigon feature-start <name> cc cx (Fleet) — worktree created, tmux session launched, agent starts implementing against spec
Evaluation 04-in-evaluation aigon feature-eval — compare agent outputs, pick winner; code review
Completion 05-done aigon feature-push (creates PR), aigon feature-close (merges/archives)

Artifacts per phase

Phase Artifact
Inception docs/specs/features/01-inbox/<name>.md
Prioritization Feature ID assigned; spec moved to 02-backlog/
Execution Implementation on feature branch in git worktree; implementation log
Evaluation Diff comparison; review notes
Completion PR created on GitHub; spec moved to 05-done/

Approval gates

Gate When
Spec approval User reviews drafted spec before feature-prioritise
Evaluation choice User compares Fleet outputs and picks winner before merge
PR review Standard GitHub PR review (optional auto-merge in Pro tier)

Execution modes

  • Drive — single agent, interactive tmux session, human can attach and observe
  • Fleet — 2+ agents race the same spec in parallel worktrees; feature-eval compares outputs
  • Autopilot (Pro) — AutoConductor runs implement → review → close unattended

Research workflow

Parallel lifecycle for research tasks: research-create → research-prioritise → research-start → research-do → research-eval → research-close

06

Memory Context

Aigon — Memory and Context

State storage

All project state is stored as Markdown specs in git. No database or external service.

State Location
Feature specs docs/specs/features/<column>/<feature-id>.md
Research specs docs/specs/research/<column>/<research-id>.md
Implementation logs Within spec files (appended during execution)
Kanban position Directory location (inbox/backlog/in-progress/in-evaluation/done)
Agent config .aigon/config.json
Dashboard data Derived from git + specs at read time (no separate DB)

Persistence

  • Project-scoped — all specs are committed to git; full history preserved
  • Session-spanning — spec files survive agent restarts; planning_context field ensures plan is preserved even if the plan file is deleted
  • Context compounds — implementation summaries from completed features feed forward into future work via spec history in git

Context injection

When an agent starts a feature:

  1. Reads the feature spec from docs/specs/features/03-in-progress/<id>/
  2. If planning_context is set, reads the plan file and copies it into the implementation log
  3. Per-project .aigon/config.json provides model routing and worktree setup commands

Worktree isolation

Each feature runs in its own git worktree:

  • Separate working directory
  • Independent branch
  • Independent .worca/ (if using WORCA integration) and implementation state
  • Fleet mode: 2+ worktrees for the same spec, each assigned to a different agent

Compaction handling

None built-in — delegates to the agent CLI being orchestrated. If the agent exhausts its context, the spec and implementation log provide sufficient state for a new session.

Cross-session handoff

Yes — specs in git are the handoff artifact. A new session for a mid-progress feature reads the spec and implementation log to understand current state.

07

Orchestration

Aigon — Orchestration

Multi-agent pattern

Parallel fan-out (Fleet mode) — multiple agent CLIs execute the same spec in independent worktrees concurrently; user evaluates outputs with feature-eval and picks the winner.

Sequential (Drive mode) — single agent executes the spec from start to finish.

Execution mode

Interactive-loop in Drive mode (user can attach to tmux session); background-daemon in Fleet mode (multiple tmux sessions run in parallel); continuous-ralph in Pro Autopilot mode.

Subagent definition format

none (for the orchestrator) — Aigon delegates entirely to external agent CLIs (Claude Code, Gemini CLI, etc.). It does not define its own subagent persona files; it passes specs and config to whichever CLI it launches.

Spawn mechanism

subprocess + tmux — Aigon launches agent CLIs as subprocess sessions under tmux panes. Users can attach to see live progress.

Isolation mechanism

git-worktree — each feature/agent combination gets its own git worktree with its own branch. Fleet mode creates N worktrees for the same spec.

Multi-model routing

Yes — .aigon/config.json maps complexity levels to model/effort per agent:

{
  "agents": {
    "cc": {
      "models": { "implement": "opus" }
    },
    "cu": {
      "implement": { "model": "" },
      "evaluate": { "model": "" }
    }
  }
}

Per-feature complexity: in the spec selects the row from the agent's complexity-defaults table.

Supported agent CLIs

Claude Code (cc), Gemini CLI (gg), Codex CLI (cx), Cursor (cu), OpenCode (op), Kimi Code CLI (km), Amp (am)

Consensus mechanism

User-driven evaluation — in Fleet mode, aigon feature-eval presents the diff from each agent's worktree; user picks the winner. No automated consensus.

Git automation

aigon feature-push creates a PR. aigon feature-close merges it. These require explicit invocation; not fully automatic.

Crash recovery

Yes — specs in git + implementation logs provide sufficient state for session recovery.

08

Ui Cli Surface

Aigon — UI and CLI Surface

CLI binary

aigon — dedicated CLI binary, npm package @senlabsai/aigon.

Not a thin wrapper — it manages the full feature lifecycle, spawns tmux sessions, creates worktrees, and serves the dashboard.

Key CLI subcommands (partial list)

aigon setup                    # First-time environment setup
aigon apply                    # Bootstrap project
aigon install-agent cc|gg|cx|cu|op|km|am  # Install agent adapter
aigon doctor                   # Environment check
aigon server start/stop/restart/status    # Dashboard server
aigon feature-create <name>    # Create spec
aigon feature-prioritise <name>  # Assign ID, move to backlog
aigon feature-start <name> cc  # Start Drive mode
aigon feature-start <name> cc cx  # Start Fleet mode (parallel)
aigon feature-eval <name>      # Compare Fleet outputs
aigon feature-push <name>      # Create PR
aigon feature-close <name>     # Merge and archive
aigon next                     # Show next suggested action
aigon board                    # Print Kanban state to terminal

Local web dashboard

  • Port: 4100
  • Stack: Next.js + React (docs/marketing site on Vercel); server: Node.js + Express
  • Features:
    • Kanban board (inbox → backlog → in-progress → in-evaluation → done)
    • Monitor tab (live agent session status, tmux session links)
    • Reports tab (cycle time, commits per feature, rework ratio)
    • Telemetry tab (token spend per agent, activity metrics)
    • All Items index (features + research in one view)
    • Reports available on LAN/Tailscale (mobile-friendly)

The dashboard is started with aigon server start and runs as a background process.

IDE / agent integration

Slash commands installed into each agent's config:

  • .claude/commands/aigon/ — 35+ commands for Claude Code
  • .codex/ — Codex CLI integration
  • .cursor/ — Cursor integration
  • .gemini/ — Gemini CLI integration
  • .opencode/ — OpenCode integration

Observability

  • Live agent sessions — tmux panes; users can tmux attach to watch real-time
  • Implementation logs — appended to spec files during execution
  • Telemetry — token spend breakdown per agent in dashboard
  • Cycle time reports — features tracked from creation to close
  • Benchmark data — .aigon/benchmarks/ for agent performance comparison

Pro tier features

  • AutoConductor — autonomous implement → review → close without human input
  • Insights — deeper analytics over feature history (agent quality trends, cost per change)
  • AI coaching — recommendations based on workflow patterns

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k
A8 Cross-runtime harness

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k
A8 Cross-runtime harness

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k
A8 Cross-runtime harness

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k
A8 Cross-runtime harness

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k
A8 Cross-runtime harness

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k
A8 Cross-runtime harness

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.