Hivebus

A signed channel for agents that binds the world they observed, not just who spoke.

Open source (MIT). A dumb, provenance-bound coordination bus for agent-to-agent questions, issue intake, investigation, and promotion-ready handoff. github.com/obstalabs/hivebus

Hivebus opens a typed thread around a real problem, keeps evidence and provenance attached, refuses to promote vague guesses into work, and only prepares downstream handoff when evidence is sufficient, clarification gaps are resolved, and the diagnosis passes policy checks.

Standalone by design. Hivebus does not need Hiveram, NeuroRouter, Verdict, or any other Obsta Labs product to do its core job. Those tools can strengthen execution routing, context safety, or operator boundaries later, but the coordination thread itself must make sense on its own.

What Hivebus does

Typed issue threads

Nullbot or any intake client can open a thread with envelopes, receipts, artifacts, and clarification turns instead of dumping raw chat blobs into a queue.

Promotion gate

Hivebus is allowed to investigate. It is not allowed to mint work until there is sufficient evidence, resolved clarification, and a promotable diagnosis object that passes policy checks.

Clean handoff

When you enable downstream execution, Hiveram is the execution ledger — routing, claims, and attempt history. Hivebus keeps provenance and thread history; it does not shadow execution state.

Compact recovery

When a thread is promoted, Hivebus can emit a bounded recovery capsule with verified facts and rejected assumptions. No raw thread replay. No memory dump cosplay.

What it is not

How it fits

Hivebus Intake, investigation, evidence, clarification, and verified diagnosis.
->
Optional Hiveram execution layer When enabled, Hiveram becomes the ledger of record — routing, claims, leases, execution attempts, and commercial workflow.
->
Optional companions NeuroRouter shapes context. Verdict enforces action boundaries. Neither is required for Hivebus core coordination.

Protocol shape

# observed issue
nullbot -> Hivebus thread

# investigation
specialist agents -> clarification.request / diagnosis.proposed

# promotion gate
promotion-ready diagnosis -> optional Hiveram execution handoff

# recovery
thread capsule -> verified facts, rejected assumptions, next action

Why it's different

The agent-to-agent space is crowded, and the established protocols already authenticate who connected — transport-layer identity, OAuth and JWTs, optionally a signed agent card. What none of them do is make the signature cover the reality the answer describes. Hivebus binds the world the answerer actually observed — the git directory, device, and inode it read — into the signed claim itself. A validly-signed answer from the wrong checkout is caught at verification, not at 2 a.m.

Open source, free, self-hostable

Hivebus core is MIT-licensed and ships as a single self-hostable Go binary. There is no paid Hivebus edition and no checkout — the protocol, signing, provenance binding, key pinning, trust classes, and CLI are open and stay open.

# install
go install github.com/obstalabs/hivebus/cmd/hivebus@latest

# run the local loop
hivebus serve   --auth-disabled --listen 127.0.0.1:7097
hivebus answer  --server http://127.0.0.1:7097 --agent project/agent --repo .
echo "which checkout is canonical?" | hivebus ask --to project/agent --type repo_status

Commercial adaptations

Hivebus stays free. Deeper, managed integrations are built on top — not behind a wall on the bus itself. If you want a durable execution ledger, managed deployment, or live-session integration around the open core, that is where the commercial work lives.

Scope is governed by the boundary charter: the bus is a dumb signed channel, and anything that makes it decide, generate, judge, or bridge a live session stays out of the open core.