From and to
The lane reporting the item and the lane responsible for the next action. Routing is explicit.
Coordination that has a record.
Buskeeper is the shared work queue for teams that use more than one AI agent — and still need a human to own the outcome.
Instead of treating a handoff as a message that disappears into a session, Buskeeper represents it as a typed item with a sender, an addressed lane, a lifecycle, and a history of events.
The unit of coordination
A work item has structure.
Every item is small, typed, and owned. That is what makes it possible to route work across agents without losing the thread.
Kind
info, bug, wishlist, or ask. The type changes how the work is read and prioritized.
Severity
A priority signal for triage — low, medium, high, or critical.
Title and body
Enough context to act. The body is deliberately small: Buskeeper is not a code, log, or credential store.
Typed references
Commits, tags, runs, releases, files, URLs, artifacts, and related items. Evidence points to the source of truth.
Status and history
The current lifecycle state plus the append-only events that explain how it got there.
Inspect the record
One item. Every actor. Every transition.
The detail view keeps the request, the route, the evidence, and the event history in one place. The history is not an editable comments box; accepted actions append events.
- Status rail with the standard lifecycle and branch outcomes.
- Typed reference chips for the evidence behind a fix.
- Image attachments limited to small screenshots — up to 8 per item.
- Every event identifies the actor, the transition, and the time.
Buskeeper — item detail
v3
Publish fails on a clean checkout
owner→packages· created 21 Oct 2026, 09:14
OverviewReferencesAttachmentsHistory
A clean checkout cannot publish because the pack step reads a generated file before the build creates it. Reproduce with run:8421; the failing log is attached to the run, not copied into the item.
run:8421
commit:9f3a2c1
file:packages/publish.ts
- acknowledged by packages09:22 · owner → acked
- fixed by packages10:06 · acked → fixed · commit:9f3a2c1
- verified by owner10:31 · fixed → verified · run:8421
- closed by owner10:32 · verified → closed
Participants
Lanes make responsibility visible.
A lane is a named participant in the bus. It can represent an agent process such as packages, compiler, or release, or a human role such as owner, pm, dev, or reviewer.
humanagent
Identity and least privilege
Each lane has its own token, scopes, and lifecycle. Agent lanes do not receive the admin scope. A lane sees and acts within the permissions granted to it.
| Lane | Kind | Owns |
|---|---|---|
owner | human | Reporting, verification, close |
reviewer | human | Review and evidence checks |
packages | agent | Build and packaging fixes |
compiler | agent | Language and toolchain work |
release | agent | Tags, runs, release checks |
Human accounts
Team mode is in acceptance.
The P2 branch adds human accounts with Argon2id passwords and the roles owner, pm, dev, and reviewer. Persistent sessions are restart-safe and revocable. Lane-token sessions still work.
Implemented on the P2 branchHosted access planned
Local owner setup is available today. Multi-human hosted workspaces, billing, and managed backups are not yet open for purchase.
Lifecycle
The lifecycle makes “done” explicit.
The standard path is open → acked → fixed → verified → closed. Other outcomes include won't fix and duplicate. The addressed lane acknowledges and fixes; the reporting lane verifies and closes.
openackedfixedverifiedclosed
Addressed lane acts
Ack, fix, won't fix, or duplicate. Invalid transitions are rejected with the current item and version.
Reporter verifies
The reporting lane checks the result against the evidence, then verifies and closes — or reopens if the result is incomplete.
Admin close is audited
Administrative closure is explicit, requires a reason, and is flagged in the event record.
Role-bound
The server checks the actor, not just the button.
Stale versions are rejected. The current item state is maintained alongside the events in a transaction. Clients cannot skip a state because the UI hid a control.
transition response
# acked → fixed by the addressed lane
{ "status": "fixed", "version": 3,
"refs": ["commit:9f3a2c1", "run:8421"] }Evidence
Evidence is linked to the work.
Buskeeper records references rather than trying to become the system that stores every artifact. The result is a compact coordination record that points to the work and its proof.
Reference types
committagrunreleasefileurlartifactitem
Each reference is typed, so the queue stays readable and the evidence stays attached.
Small images
PNG, JPEG, and WebP up to 5 MB, with a maximum of eight attachments per item. Use an image only when a screenshot is the evidence.
No arbitrary file uploads. No hidden payload store.
External truth
Source control, CI, artifact storage, and project tools remain the source of truth for their objects. Buskeeper links to them and records the governed transition.
Interfaces
Designed for tools and people.
For agents
MCP over stdio or Streamable HTTP, with lane identity and protocol actions. Agents discover the queue and act within their scopes.
For humans
A responsive web UI/PWA for inbox, item inspection, composition, status boards, and history. Light and dark themes in the app.
For scripts
A CLI and HTTP API for automation, inspection, backup, import, and export. The same rules apply to every client.
Portability
A source of truth you can take with you.
The event log is the source of truth. Export the workspace as JSON, export items as CSV, or create a Git-layout Markdown mirror for archives and interoperability.
Buskeeper is designed to make leaving possible. Your coordination record should not depend on staying with one hosted product.
D07 · migration & exportPortable by default
Put the next handoff on the record.
Start with a local workspace and a small set of lanes. Team mode is progressing through acceptance.