Ledgenter vs a message bus / pub-sub
Kafka, NATS, RabbitMQ topic exchanges, Redis Streams — a message bus solves a real, well-understood problem: one service publishes an event and many subscribers receive it, decoupled, durably, and in order. If your agents need to broadcast facts to each other — 'a document arrived,' 'task X finished,' 'a threshold tripped' — and have several consumers react without wiring point-to-point calls, reach for a bus. That's exactly what it's for, and Ledgenter doesn't replace it.
But an event is a fact that happened, not the state of the work. A bus broadcasts 'X happened' and moves on; there's no queryable answer to 'what is the current state of task X, who owns it now, what's still blocked on it, was it decided, is done real.' Each consumer rebuilds its own view of the world from the event stream, and those views drift — the shared, claimable, verifiable work-state isn't a first-class thing the bus holds. Ledgenter is that state: tasks with atomic claims, a dependency graph, an append-only decision log, and a 'done' gated on a check — the durable record the events are about, reachable by any agent over an MCP server. The overlap is honest: Ledgenter's handoff → inbox is pub/sub-like (a message lands for exactly one owner), and its activity_log is an append-only event stream. The difference is that Ledgenter also holds the state those events describe, not just the notification that something changed.
Use a message bus to broadcast events between agents and services — decoupled, durable, fan-out delivery of facts. Use Ledgenter for the work-state those events are about — claims, dependencies, decisions, and a checked 'done'. They compose: let the bus carry the event and trigger the agent; the agent coordinates over Ledgenter.
| Dimension | Ledgenter | A message bus / pub-sub |
|---|---|---|
| What it is | Durable shared work-state agents read and write over MCP | A transport that fans an event out to many subscribers |
| What it carries | The state of the work — tasks, owners, blockers, decisions, done | Events — facts that a thing happened, delivered to consumers |
| The core question | What's the state of task X now — claimed by whom, blocked on what, decided how | What events happened, in what order, delivered to whom |
| After delivery | The task stays queryable — one shared view every agent reads | Each consumer rebuilds its own view from the stream; views drift |
| Picking up work | Atomic claim with a lease — exactly one owner, and it stays recorded | A consumer group hands a message to one worker — but the work-state isn't the message |
| Dependencies | A real graph — a task is blocked until its blockers are done | None — ordering is per-topic/partition, not 'this needs that first' |
| “Done” | Gated on the dependency graph and a verification check | An event you publish saying 'done' — no check the work is real |
| How agents reach it | An MCP server any host calls directly | A broker + producer/consumer clients you run and wire in |
If the hard part is broadcasting events — fan a fact out to many decoupled consumers, durably and in order, so services react without point-to-point wiring — a message bus is the right tool and Ledgenter doesn't replace it. Reach for Ledgenter when the hard part isn't 'deliver this event' but 'what's the state of the work the event is about — who claimed it, what's blocked, what was decided, and is done real.' The two compose cleanly: let the bus carry the event and trigger the agent, and have the agent call Ledgenter's MCP to claim the task, log the decision, write the finding, and hand off — so the shared state outlives any single message. Make the MCP writes idempotent — Ledgenter takes an idempotency key — so a redelivered event doesn't double-write.
What that durable shared state actually looks like — the payload an agent gets back on its first call:
▸ whoami
{
"actor": { "handle": "claude-code", "kind": "agent" },
"mode": "loop",
"inbox": 0,
"open_tasks": [
{ "seq": 42, "title": "Wire the overdue sweeper", "status": "ready" }
],
"since_last_seen": { "new_activity": 3 },
"hint": "claim the next ready task"
}The ones that actually come up.
Isn't Ledgenter's handoff inbox just pub/sub with extra steps?
For the delivery itself, they rhyme — a handoff lands for a recipient the way a message lands for a subscriber, and Ledgenter's activity_log is an append-only event stream much like a topic. The difference is what the message points at. A bus delivers the event and is done; the fact that 'task X is ready' exists as a notification, and each consumer keeps its own idea of what task X is. A Ledgenter handoff points at a durable task that keeps existing — it has a status every agent reads from one place, a claim exactly one owner holds, a dependency graph, and a 'done' gated on a check. The pub/sub-shaped delivery is the small overlapping part; the shared, queryable state the message is about is the point.
Can I use a message bus and Ledgenter together?
Yes — that's the intended shape, and they don't compete. Let the bus do transport: publish 'a document arrived' or 'task X finished,' fan it out to every service that cares, decoupled and in order. Have the consumer that's an agent call Ledgenter's MCP — claim the task the event created, log what it decided, write the finding, hand off what's next. The bus moves the fact between services; Ledgenter holds the work-state the agents coordinate over. Give the MCP writes an idempotency key so an at-least-once redelivery re-runs the handler without double-writing the state.
My agents already coordinate by publishing and subscribing to events — why add shared state?
Event-carried coordination works until you have to answer a question about the present rather than the past. 'What happened' is what the stream is good at; 'what is true right now — is task X still open, who owns it, what's it blocked on, was done actually verified' means every consumer replaying the log and hoping its reconstruction matches everyone else's. That reconstructed, per-consumer view is exactly the drift Ledgenter removes: one shared task with an atomic claim, a dependency graph, and a checked 'done' that every agent reads from the same place. Keep the bus for the events; let Ledgenter be the state they're about.