The platform

Your org lives in Jira. Your agents can't.

The absence this makes loud: work that exists in two systems and reconciles in neither.

Self-hosting Graphban is free, unlimited, and genuinely complete — for one developer. The platform is what you want when the work stops being just yours: teammates, shared context, and a bridge into the tracker your company already runs on.

The fork

Self-hosting is for one person. That's not a tier — it's the truth about the code.

We're not holding features back to sell you an upgrade. Every mechanism on this site — the grill, the gates, collision clustering, the fleet, the code graph, the learning loop — runs in full when you self-host, with no quotas and no keys. Including multi-agent fleets.

What self-hosting does not have is a way to add a second human. There is no invite flow and no add-member endpoint in the open-source build; a project has one owner and as many agents as that owner mints keys for. That is a real boundary, and it's where the platform starts.

self-host

You and your agents

Everything the tool does, on your machine, unlimited and offline. One human owner, any number of agents. Free, and it stays free.

platform

Your team, and the tracker they already use

Teammates on the same project, shared memory across people, org roles and audit — and the bridge into Linear and Jira so agents can work the tickets your company already files.

The nuance that matters: multi-agent is not the same as multi-human. A solo developer running twelve agents across four worktrees needs nothing from the platform. Two developers sharing one backlog do.

The headline planned

An agent-facing layer on top of the tracker you already have.

Nobody is migrating off Jira because their agents find it awkward. So the plan is not to replace your tracker — it's to sit on top of it. Your tickets stay where your PM, your stakeholders and your reporting already live. Graphban becomes the surface your agents actually operate.

Trackers such as Linear, Jira and GitHub mirror into a Graphban cloud hub, which serves agents and developers and writes a constrained set of changes back. Linear planned — first integration Jira planned — after Linear GitHub Issues inbound works today the tracker stays the source of record Graphban Cloud mirrors the tickets · owns claims, clusters and memory the agent-facing layer writes back a constrained set: status, links, comments agent · worktree A agent · worktree B you, in the web UI your agents talk to one surface; your company keeps the system it already reports out of.
Hub and spoke, with authority pointing outward. The tracker is authoritative; Graphban mirrors it read-heavy and writes back only a constrained set. Full bidirectional custom-field sync is explicitly not the plan.

Status, plainly: this is designed and decided, not built. Linear is the first integration — cleaner GraphQL API — with Jira second. Webhook coverage, reconcile cadence and packaging are still open. Nothing in this section ships today except inbound GitHub issues.

The argument

Why a layer, and not a Jira plugin.

You could point an agent straight at a Jira MCP server today. It would read tickets and write comments, and it would be missing everything that makes agent work safe.

A ticket list has no collision model

Jira has no idea which files a ticket touches, so it cannot partition work between four agents. Touch-areas, clusters and reservations have nowhere to live in a tracker built for humans reading top to bottom.

Nothing enforces who reviewed what

A tracker will happily let the account that did the work move it to Done. The self-review ban, the independence ladder and the sabotage receipt need an authority that knows about agents as principals.

Tickets aren't specs

The grill, the frozen baseline and the completeness pass all operate on intent that has been sharpened and frozen. A ticket description is neither.

Memory and the code graph have no home

Lessons, described code, presence and the audit ledger are agent-native structures. They don't map onto issue fields, and shoehorning them there is how you get a custom-field swamp nobody maintains.

So the split is deliberate: your tracker keeps being the system of record for the business, and Graphban is the system of record for the work. Tickets flow in, status and links flow back, and everything agents need that a tracker was never going to model lives in between.

How it works shipped

Your code never has to leave your machine.

The link between a local instance and the hub already exists and already works. Your agents keep talking to the local endpoint; only what's genuinely contended goes up.

On a linked instance the code graph stays local and authoritative, while items, claims and memory are forwarded to the cloud hub. your machine the code graph — built here, authoritative here described from a repo only you have stays local · push it deliberately, or never your agents → local /api/mcp one endpoint, whether you're linked or not unlinked, nothing is forwarded — a pure local tool forwarded the hub items · claims · clusters · memory contended state needs one authority org roster · audit ledger · quotas and, later, the tracker bridge applies its own authz, metering and audit two developers on two machines can each keep their own code graph private and still share one backlog.
Code-graph tools run locally; everything mutable and contended is forwarded. There's a never-sync privacy flag, an incremental resumable push, a portable export bundle, and a purge — all driven from the CLI.

Governance private beta

The part your security review asks about.

BYOK

Your model keys, encrypted at rest

Chat and extraction providers are per-project and resolved from your own credentials. We don't meter token cost, because we aren't buying your tokens.

audit

Every mutation on the record

One append-only row per accepted change, naming the key or user — and for agent actions, the human principal behind the key. "What did my agents do last night" is a query, not an investigation.

tenancy

Orgs, roles and seats

Owner/member roles, emailed single-use invites bound to an address and time-bounded, and a project-access model that a key can never out-rank.

quotas

Counters, not token bills

A plan is a set of counters — projects, seats, memory shards, metered calls per month. Public surfaces like the feedback intake and public roadmap are never metered, on any tier.

Honestly

Built, in beta, or planned.

A roadmap that reads like a feature list is exactly the failure the rest of this site is about. So every row says which it is. Accurate as of 2026-09-07.

CapabilityStatus
The tool itself
Tracker, PRDs, grill, gates, code graph, memory, learning loopshipped self-host and hosted
Fleet roles, collision clustering, review pool, enrolment seatsshipped self-host and hosted
Local fleet supervisor — spawns a child per seat, reaps it, orphan sweepshipped separate graphban-fleet package
gbfleet until — planner loop around the wave; takeover adopts live childrenshipped self-host
Native install — launchd / systemd, no Dockershipped self-host
Git delivery contract — agents are told the base branch, or that it is unmeasuredshipped self-host and hosted · v1 does not open PRs
Teams
Adding a second human to a projecthosted only no self-host path exists
Organizations, roles, emailed single-use invites, seatsprivate beta
Plans, quotas, operator consoleprivate beta
Cloud hub for linked local instancesprivate beta
The tracker bridge
Inbound GitHub issues → work items (HMAC webhook, routed by repo)shipped
Outbound: opening real GitHub issuesnot built the endpoint is a stub
Linear sync — mirror in, constrained write-backplanned first integration, not started
Jira syncplanned after Linear
Full two-way custom-field syncnot planned deliberately out of scope
Other sync that already works
PRD ↔ markdown folder (put it in Google Drive Desktop, no OAuth)shipped
Local → cloud code-graph push, incremental and resumableshipped

If a row you need says planned, that's the most useful thing you can tell us on the waitlist — it's how the order gets decided.

← the argumentSilence is not a pass Technical reference ↑ the mechanisms →Spec → done

What's new

Every entry is work that merged. The full history is on GitHub.