Agent-native execution
No spec, so there's no drift to measure. No review, so nothing gets rejected. No check, so it's green. That isn't a workflow — it's a practice, and it has a name.
# your agent finishes, and marks its own work done update_item({ id: "GRPH-380", status: "done" }) → { error: "unauthorized", hint: "a worker moves an item to review. Signing it off is a reviewer that did not build it." }
The villain
Not "using AI to write code" — that part is fine, and it works. The practice is what grows around it: accept the diff without reading it, take done at its word, ship. It feels fast because nothing ever pushes back.
And nothing ever pushes back because at every point where a system could object, there is nothing there to object with. You didn't write a spec, so no tool can tell you the work drifted from it. Nobody independent reviewed it, so no review was ever rejected. There is no check for that failure mode, so the suite is green. Each silence is read as approval, and the readings compound.
That is the whole disagreement. Three emptinesses, one green tick. In Graphban the same three each produce a named state, and the summary is not green — because a thing nobody checked and a thing that passed are different results, and only one of them is a pass.
What it is
Graphban is a work tracker, a code graph and an agent memory that your coding agents operate directly over MCP — the same service layer the web UI uses, so an agent's write and your click run identical code. What makes it different from a list is what it declines to do.
The first two below are the first two silences, answered in order. The other two are the same rule applied to what the system knows rather than to what it checked — a file the map has never seen, and a lesson nobody vouched for, are absences that read as clean exactly the way an unwritten spec does.
Approval isn't a status you set — it's earned by finishing the grill. Ask for it early and you get ApprovalNotEarned, naming the dimensions still open. How the spec lifecycle works →
An agent cannot pass its own work, enforced by two separate gates keyed on identity — so promoting it to reviewer doesn't launder it. "We can't tell them apart" fails closed. How coordination works →
Re-describing prunes to stale, never deletes, and the health read distinguishes "went stale" from "never described at all". How the code graph works →
Saying it three times in one session is saying it once — the ladder counts distinct sources, and approving a shared-file recommendation writes nothing. How the learning loop works →
Graphban was built by agents running Graphban, and that last number is the one worth arguing with — the full account is here. The objection that you already have a folder of Markdown specs is answered at length, and the bug that started all of it is two minutes.
The path
There is no version of this where you sit down and start running a fleet. Every rung below is one command more than the rung above it, and none of them asks you to become a manager — because the arbitration is the server's job, not yours.
And every rung is the same four refusals. Nothing is switched on by growing: at N=1 they simply resolve to answers about you.
Multi-agent and multi-human are different problems. Twelve agents across four worktrees is free and unlimited on your own machine. But the self-hosted build has no invite flow and no way to add a teammate to a project — one owner, any number of agents. Sharing a backlog with other people, and bridging into the tracker your company already runs on, is what the platform adds.
A delegated item's outcome comes back through the ledger — the item moving on the board, with its evidence — and never as a reply in your session. That is the whole difference between delegating and supervising. Twelve agents reporting into one context window is not orchestration; it is one context window with twelve times the reading, and it collapses at about three.
cheap or frontier — the resolver picks the harness and model from a committed table of what has actually been verified for that lane and role, filtered by the project's policy and your own preferences, and it records what it chose, what it dropped at each step, and the runner-up. A choice you can read afterwards is a choice you can correct. Naming a model in twelve places is a choice you get to make once and then live with.
Run it
Self-hosted is the real product, not a trial tier. It starts empty by design, runs fully offline with stub embeddings and no API keys, and nothing phones home.
git clone https://github.com/asc-me/graphban && cd graphban ./start.sh # brings the stack up and mints your first agent key # web :8080 · api :8000 · Postgres + pgvector # writes ~/.graphban/mcp.json — paste it into Claude Code, Cursor or Codex
Migrations run automatically at startup. ./start.sh is idempotent, and refuses to run on a hosted deployment or a seeded instance rather than quietly minting a credential where it shouldn't.
A box that already has Postgres + pgvector can skip Docker altogether: python3 scripts/graphban_host.py is one CLI for install, upgrade and uninstall, under launchd or systemd. Compose stays the default and is what the hosted service runs; this is the other one.
Postgres is required and verified, never installed. The installer refuses when Postgres or pgvector is missing, and it will not create, migrate or reconfigure a cluster. A tool that quietly provisions a database is a tool that quietly owns your data directory.
# from an unpacked release, with backend/.env already written python3 scripts/graphban_host.py install --root /opt/graphban --from .
Preflight first — Postgres reachable, vector enabled, the port free — then the venv, then the unit, and it refuses if the job is not actually running afterwards. Upgrades swap the release, keep your .env, and put the old one back if /health does not come up serving the new sha. Uninstall never drops the database.
Install from the release tarball, not GitHub's source zip: a git tag is not a release and the source zip has no built web bundle. Settings → This box → Updates does the same fetch-and-upgrade from inside the app.
gban is the client for a human at a terminal — issue seats, read why an agent is stuck, re-task one — for the acts that otherwise need a browser. It installs on a laptop and pulls no dependencies at all.
# macOS brew install asc-me/tap/gban # anywhere uv tool install graphban-cli uv tool install graphban-fleet # gbfleet + gbagent, only if you run waves
The supervisor is a separate package on purpose: it exists to be resolved on PATH by whatever launched it, and it is the one that carries dependencies. If you skip it, gban fleet will offer to install it the first time you need one — and ask first.
Honestly
A list of known gaps is the only version of this section that isn't an absence reading clean. All of these are open as of 2026-09-07.
There is no feature-gated free tier here. Self-hosting gives you the whole tool, unlimited. The platform exists because some problems only start when a second person shows up.
If it's just you
One docker compose up. Postgres, API and UI, fully offline, no accounts and no keys required. Every mechanism on this page, no quotas — including multi-agent fleets. Source under FSL-1.1: free for personal, internal and development use, and each release converts to Apache-2.0 two years after it ships.
If it's a team
Teammates on one backlog, shared memory across people, org roles and audit — and an agent-facing layer on top of Linear and Jira, so your agents can work the tickets your company already files. invite-only private beta
The tracker bridge is designed and decided, not built — every capability is marked shipped, beta or planned. Already have platform access? Sign in.