GAIA

Appearance

What is GAIA ​

You'll learn what GAIA does, who it is for, and which two pieces make it up.

GAIA is a ticket-driven orchestrator where every active ticket state is worked by a human or an AI. Coding agents are fast; the bottleneck is human attention spent micro-managing many sessions. GAIA inverts that: the issue tracker becomes the control plane. Every active ticket has a state, the state says what happens next, and a registered conductor on a developer machine picks the ticket up and starts an agent on it.

So you do not tell an agent what to work on. You keep the ticket board honest, and the tickets pull the work through.

Who GAIA is for ​

  • Teams that already track work as tickets and want agents to work them without someone babysitting each session.
  • Developers who keep a conductor running on their machine so tickets assigned to them, or open to their project, get worked while they do something else.
  • Project managers who want one board that is always the truth about progress, because progress is a state change on the ticket.

If you only want to try it, the Quick start takes one ticket from creation to done in about ten minutes.

The two halves ​

GAIA is one system in two pieces, installed separately.

The control plane is a Drupal application. It holds the canonical projects, tickets, runs, comments and labels; it owns each ticket's state machine; it grants the atomic claims that let several machines work the same board without collisions; and it serves the board and dashboards humans look at. It exposes JSON:API for reads and takes every write through the same API.

The conductor is the gaia CLI — npm packages you install on a developer machine with npm install -g @gaia-ai/gaia. Started in a project checkout, it polls the control plane for dispatchable tickets, claims one, prepares an isolated git worktree for it and launches an agent session there. There is no central daemon and no open port: each checkout runs its own conductor, and the control plane is the only thing they share.

The same CLI is how you talk to the control plane by hand: gaia ui for the terminal cockpit, gaia dropsh for the JSON:API shell, gaia deployment for release helpers.

Guiding principles ​

  1. The control plane is the single source of truth. Ticket state lives there, never only in a local file or an agent's context.
  2. The state machine lives in code; a repository's WORKFLOW.md is instruction text. Which states exist and how they connect is fixed per ticket workflow; what a project's skills do at each step is what the repository decides.
  3. The conductor claims and dispatches — nothing else. It never writes ticket content.
  4. Agents are autonomous. State transitions, comments, sub-tickets and the footprint are written back by the session itself. A run ends when the agent writes the ticket's next state.
  5. Model-agnostic. The coding agent is an addon — Claude Code by default; Codex, Kimi, OpenCode, pi and Grok ship too — selectable per project and per ticket.
  6. A canonical domain model. Imports normalise into GAIA's own tickets; the source system survives only as metadata (origin).
  7. The ticket is the unit of dispatch and of billing. A run is one concrete attempt with a claim, an audit trail and a cost.

Prior art

GAIA is inspired by OpenAI Symphony, extended with a Drupal control plane, distributed conductors and footprint-based billing.

Next ​