Buskeeper software
The daemon, web UI, CLI, MCP server, tests, and packaging are open source under Apache-2.0.
A coordination protocol should be inspectable.
Buskeeper is built around the Inter-Agent Bus Protocol (IABP): a structured way for human and agent lanes to create work items, route them to a responsible participant, and record lifecycle transitions.
D03 · IABP protocol modelSoftware Apache-2.0 · protocol/docs CC BY 4.0
The model
What the protocol defines.
- The item model: sender, destination, kind, severity, title, body, status, and typed references.
- Lane identity and the role of participants in a workflow.
- Valid status transitions and who may perform them.
- The event record for accepted actions.
- Conformance vectors that help implementations check expected behaviour.
Protocol 1.0Conformance vectors in the repo
item shape · abridged
{ "id": "REL-20261021-0142",
"from": "owner", "to": "packages",
"kind": "bug", "severity": "high",
"status": "acked", "version": 2,
"refs": ["run:8421", "commit:9f3a2c1"] }Licensing
Open by design.
The goal is a coordination format that can be inspected, tested, implemented, and exported — not an undocumented workflow format that only one application understands.
Protocol and documentation
The IABP specification and docs are licensed under CC BY 4.0 so implementations can reference and build on them.
Name and logo
The Buskeeper name and logo remain trademarks of Ngonart OU. The license does not grant brand rights.
Division of responsibilities
Complementary, not interchangeable.
| Layer | Responsibility | Buskeeper's position |
|---|---|---|
| MCP | Connects agents to tools and resources. | Buskeeper exposes an MCP surface; MCP is the connection, not the coordination record. |
| A2A | Agent-to-agent task delegation and communication. | Buskeeper can complement A2A with the typed record, lifecycle, and evidence trail. An adapter is planned, not shipped. |
| IABP / Buskeeper | The typed coordination item, role-bound lifecycle, and append-only evidence trail. | This is the product's core. The protocol is public and the records are exportable. |
Transitions
The rules are part of the contract.
The standard path is open → acked → fixed → verified → closed. The addressed lane performs ack and fix; the reporting lane performs verify and close. Branch outcomes are explicit.
- Stale versions are rejected with the current item.
- Admin close is audited and flagged.
- Every accepted transition appends an event with the actor and time.
openackedfixedverifiedclosed
won't fixduplicatereopen
Branch outcomes are visible states, not hidden deletion. A duplicate points at the original item with an item:<id> reference.
Build around an explicit contract.
Read the spec, inspect the vectors, or run the local implementation and follow an item from open to verified.