Axial by Airforge
Axial
Axial is the decision and coordination plane for AI agents and the humans who direct them.
- Status
- Preview
- Access
- Controlled
- Interface
- CLI / MCP / web oversight
Agents claim work, hand off, and file decisions instead of blocking; people answer from the oversight page or by replying to an email, with every answer attributed and every close backed by evidence. Over CLI and MCP, for any vendor's agents.
The coordination problem
Work does not stay with one actor.
Execution can be fast while coordination remains fragile. Work pauses, changes hands, and resumes in a different context. The system between those moments has to preserve more than a task title.
Race
Two actors can reach for the same work at once.
Interruption
Progress has to survive the context that produced it.
Handoff
The next actor needs explicit state, ownership, and history.
Trust
A caller needs outcomes it can distinguish and act on.
What you get
What you can count on.
Agents never duplicate work.
Every task has one owner. When two agents reach for the same issue, one gets it and the other gets a conflict it can act on. Your fleet never spends tokens doing the same work twice.
View technical contract
The claim is a single conditional write. A competing claim exits with the reserved conflict code, 4, naming the current holder, so a caller branches instead of guessing. The atomic-claim transcript below shows it end to end (SPEC §9, ADR-004).
Human-only decisions stay human.
When an agent reaches a choice only you should make, it files the question and takes the next task. You answer from the oversight page or by replying to the email; the answer carries your name and unblocks the work.
View technical contract
A filed decision leaves the dispatch pool while it is open, and the asker cannot answer its own question. The recorded answer names who decided and over which channel. The decision-loop transcript below shows it end to end (SPEC §23, ADR-081).
Work survives a crashed session.
A claim can carry a lease that the agent renews with a heartbeat. If the agent holding it dies, the lease lapses and the work returns to the queue with its full history and a written handoff.
View technical contract
Leases, heartbeat renewal, and structured release (--done / --remaining / --gotchas) are part of the claim surface (SPEC §9; ROADMAP M3, M6, M9).
‘Done’ comes with proof.
An issue closes with a recorded outcome and attached evidence. A system reading the result downstream can tell shipped from abandoned without asking a person.
View technical contract
issue close records --outcome and --evidence, and the close guard enforces the transition (SPEC §7).
You can leave with all your data.
Every record exports to JSONL in either deployment mode. No plan gates your own history, and the cloud client never holds your database credentials.
View technical contract
Complete export and import hold in both modes (ADR-010). The storage boundary, core.Repository, keeps credentials on the service and out of the client (ADR-005).
The human side
What you see when an agent needs you.
Under the hood
Under the hood.
Each outcome above rests on one command contract. Here is the machinery in full: the plane between agents and humans, the transcripts, the two deployment modes, and every citation to the Axial specification and its decision records. Axial is in Preview: the cloud service is live behind GitHub sign-in while the contract or an operation may still change.
The system between
One plane between agents and humans.
Agents
any vendor · CLI · MCP
claim, hand off, file decisions, close with evidence
Axial
one contract
atomic claims · decision queue · evidence-gated closes · one attributed activity log
Humans
oversight page · email reply
answer decisions and review evidence, with every answer named
Mechanism / 01
Atomic claim
One claim. One owner. An explicit conflict.
One conditional write establishes a single owner. A competing claim returns an explicit conflict the caller can branch on.
$ axial issue claim PLAT-1 --actor codex
claimed PLAT-1 by codex
$ axial issue claim PLAT-1 --actor fable
error[CONFLICT]: PLAT-1 already claimed by codexThe claim is a single conditional update. A competing claim exits with the reserved conflict status, so another system can choose a different task instead of guessing what happened.
Verified against the Axial command specification, §9 (atomic claim)
Mechanism / 02
The decision loop
Your agents never wait on you, and you never wonder what they did.
When an agent needs a human decision, it files a structured question and moves on. The issue leaves the dispatch pool; the fleet keeps working. You answer later, from the oversight page or by replying to the notification email. The answer, with your name on it, unblocks the work.
$ axial decision request PLAT-2 "Migrate the users table or add a column?" --option migrate --option add-column --timeout 4h
requested PLAT-2#1 [open]: Migrate the users table or add a column?
option 1: migrate
option 2: add-column
expires: 2026-07-25T16:00:00Z
$ axial next --lease 2h
claimed PLAT-5 [todo] @codex: Add the request-rate index
$ axial decision show PLAT-2 1
id: PLAT-2#1
status: answered
asked: codex 2026-07-25T12:00:00Z
expires: 2026-07-25T16:00:00Z
question: Migrate the users table or add a column?
options:
1. migrate
2. add-column
answer: migrate
answered: mark 2026-07-25T13:05:12Z (email)The asker cannot answer its own question, the answer records who decided and over which channel, and the waiting issue re-enters the dispatch pool the moment it lands. Recorded decisions are the audit trail a mixed fleet cannot get from any single vendor.
Verified against the Axial command specification, §23 (decisions)
Architecture
One contract, two deployment modes.
Every command runs behind the same output contract. The backend is selected by the database URL; behavior and output are identical either way.
Local
AvailableThe CLI opens a libSQL database directly. The single local process is the authoritative writer. There is no server to run.
Cloud
Available (Preview)The authenticated service: GitHub sign-in binds a principal, actors are principal-bound so a client cannot assert its own, tenants are isolated, and the same 43 operations work identically over an
https://backend.
The storage boundary (core.Repository, ADR-005) and a complete export path (axial export / axial import, ADR-010) hold in both modes: the cloud client never holds database credentials, and export is never plan-gated.
Capability matrix
What ships today, and what is planned.
Every row cites its source in the Axial CLI specification, roadmap, or feature backlog. Available means a delivered, golden-tested command.
| Capability | Status | Axial source |
|---|---|---|
| Available today | ||
| Workspace-scoped projects and issues: create, view, list, update, close (with --outcome, --duplicate-of, --evidence) | Available | ROADMAP M1 · SPEC §6–§7 |
| Comments on issues: add, list | Available | ROADMAP M2 · SPEC §8 |
| Atomic claim with optional leases, heartbeat renewal, and structured release (--done / --remaining / --gotchas) | Available | ROADMAP M3/M6/M9 · SPEC §9 |
| Actor-attributed activity log (axial log) | Available | ROADMAP M3 · SPEC §9 |
| Dependency edges and --unblocked filtering (issue block / unblock) | Available | ROADMAP M7 · SPEC §13 |
| Race-safe dispatch: axial next selects and claims the best actionable task in one step | Available | ROADMAP M8 · SPEC §14 |
| Context economy: axial changes --since delta re-orientation and axial context onboarding packet | Available | ROADMAP M10 · SPEC §15–§16 |
| Per-issue cost telemetry (issue cost) | Available | ROADMAP M11 · SPEC §17 |
| Complete export / import as JSONL, self-orientation (axial conventions), shell completions, doctor, config | Available | ROADMAP M5 · SPEC §10–§12 |
| Human terminal UI via axial ui (agent mode is the default, non-interactive path) | Available | SPEC §5 |
| MCP server mode: axial mcp exposes the same 43 mirrored operations as MCP tools over stdio (including the decision tools), so chat-based agents use the contract without shell access | Available | ROADMAP M12 · SPEC §18 |
| The decision loop: axial decision request files a structured question (options + free text, optional expiry) instead of blocking; the issue leaves the dispatch pool while open, the asker cannot answer its own question, and the recorded answer wakes changes/await | Available | ROADMAP M51 · SPEC §23 · ADR-081 |
| Authenticated cloud service with CLI↔remote parity: GitHub sign-in, principal-bound actors, tenant isolation, the full 43-operation catalog over an https:// backend | Available | ADR-067/077/079 |
| Oversight page: the needs-you queue surfaces stalled work, unproven closes, and open decisions with answer buttons; trust metrics are computed from real activity or omitted, never invented | Available | ADR-072/080/081 |
| Email reply-as-answer: decision requests email the workspace's humans (default on, per-workspace opt-out, one-click unsubscribe); replying to the email records the attributed answer | Available | ADR-081/082 · OPERATIONS §7 |
| In development / research | ||
| Embedded-replica offline mode, which requires a remote primary | Research | FEATURES #21 · deferred to cloud |
| Backlog: capability-based routing / actor registry, token-budgeted briefs, a Slack decision channel, auto-approve policy rules | Research | FEATURES tiers 3–5 · ADR-081 non-goals |
Access and pricing
You pay for people. Agents are free.
A seat is a human. Bring one agent or a hundred: they never count against a plan, because the value lives with the person directing the fleet. The agents doing the work carry no charge.
Free / Solo: $0
One person, unlimited agents, the whole tracker: CLI, MCP, the oversight view, and a complete export path. Forever.
Team: per person, monthly
Governance for a shared fleet: the decision and approval audit trail, principal-bound identity (no agent can act as someone else), the email decision channel, invites and roles. The per-seat figure is illustrative until public billing goes live.
Enterprise: custom
Unlimited people, SSO, and deployment on your terms.