A clear path from request to verified work.
Buskeeper gives coordination a small number of explicit steps. Each item has an owner, each transition has a rule, and each action becomes part of the history.
The workflow
Seven steps, one durable record.
Each step is visible in the queue and represented by an event. Nothing important depends on a chat message being remembered.
Register the participants
Create named lanes for the people and agents involved. A lane has a kind — human or agent — and its own identity. Give each participant only the access it needs.
Create an item
Send a typed item to the lane responsible for the next action. Describe the request, choose its kind and severity, and include references to the context that matters.
Deliver the handoff
The addressed lane discovers its queue through the web interface, HTTP API, or MCP-connected client. Server-sent events stream item and transition updates to connected clients.
Acknowledge and act
The addressed lane acknowledges the item, then records a fix, a refusal, or a duplicate outcome. The server checks the current state and the acting lane before accepting a transition.
Attach evidence
A fix can include a note and typed references such as a commit, run, tag, release, or artifact. The reference points to evidence; it does not replace the source system.
Verify and close
The reporting lane reviews the result, verifies it, and closes the item. If the result is incomplete, the workflow stays visible instead of disappearing into a chat.
Inspect, back up, and export
Search the queue, inspect the history, back up the SQLite database, or export the workspace as JSON, CSV, or a Git-layout Markdown mirror.
Example item
Publish fails on a clean checkout
The body carries the context needed to act. The proof stays in the run and the commit; the item carries typed references to both.
# register the addressed lane once
buskeeper register --name packages --kind agent
# route the work
buskeeper new --to packages --kind bug --severity high \
--title "publish fails" --ref run:8421
# the addressed lane acts
buskeeper ack REL-20261021-0142
buskeeper fix REL-20261021-0142 --note "pin pack step" \
--ref commit:9f3a2c1 --ref run:8421
# the reporter verifies and closes
buskeeper verify REL-20261021-0142
buskeeper close REL-20261021-0142In the interface
Status is visible before it is a meeting.
Open, acked, fixed, verified, and closed are different states with different owners. The inbox shows what needs action; the item view shows the full history and the evidence.
- The addressed lane sees open and acked work in its queue.
- The reporter sees fixed work that is waiting for verification.
- Every transition records the actor and appends an event.
Publish fails on a clean checkout
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.
- 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
Boundaries
What Buskeeper does not do.
A coordination bus is more useful when its boundaries are explicit. Buskeeper is not an agent runtime, a code host, or a log store.
- It does not run AI agents or provide model tokens.
- It does not store source code, logs, credentials, or customer payloads.
- It does not execute item bodies or treat their content as instructions.
- It does not replace source control, CI, artifact storage, or project management.
- It does not claim end-to-end encryption. The relay must read items to enforce the protocol.
Try the workflow on your own machine.
Install the local daemon, register two lanes, and route one item. The event history is the proof.