Ledgenter vs Redis (as agent shared state)
Redis is the reflex answer when agents need to share state: SET NX (or Redlock) for a lock, a KV for scratch state two runs both read, pub/sub to pass a handoff. It's a superb primitive — in-memory, fast, atomic where it counts — and if what you need is a distributed lock or a hot cache, reach for it. Ledgenter doesn't replace that.
But Redis is a primitive, not a work model. It hands you an atomic key and an empty value; the shape of the work — the task, the dependency graph, the append-only record of what was decided, the check that says 'done' is real — is yours to build and maintain on top of a store that is ephemeral by default. Keys expire, an eviction policy can drop them under memory pressure, and a lock without careful fencing is a known footgun (the Redlock debate is exactly this argument). A Redis lock answers one narrow question — can I hold this key right now. Ledgenter answers a different one — what is the state of the work, who claimed it, what was decided, and is 'done' actually real — as first-class, durable, queryable primitives an agent reaches over an MCP server, not structure you hand-roll into a KV. The overlap is honest: task_claim's atomic lease is lock-like, and Ledgenter leans on Postgres the way you'd lean on Redis for the lock. The difference is that everything around the lock is modeled and durable, not left to you.
Use Redis for a distributed lock, a hot cache, or a rate limiter — it's the right primitive and Ledgenter doesn't replace it. Use Ledgenter when the hard part isn't 'hold this key' but 'what's the state of the work — claimed by whom, blocked on what, decided how, and is done real.' They compose: keep Redis for the lock, coordinate the work over Ledgenter.
| Dimension | Ledgenter | Redis |
|---|---|---|
| What it is | A work model — tasks, dependencies, decisions, done — durable over MCP | A primitive — a fast atomic key and an empty value |
| The core question | What's the state of the work — claimed by whom, blocked on what, decided how | Can I hold this key right now |
| Durability | Persistent by default — state is the record, transactional on Postgres | Ephemeral by default — keys expire, eviction can drop them under pressure |
| Picking up work | Atomic claim with a lease — one owner, and the claim stays recorded | SET NX / Redlock — atomic, but fencing is on you and a drained lock leaves nothing to read |
| Dependencies | A real graph — a task is blocked until its blockers are done | None — you model ordering yourself in keys and values |
| “Done” | Gated on the dependency graph and a verification check | A value you set to 'done' and hope was true — no check |
| History | Append-only decision, knowledge, and activity logs a later run can read | Whatever you chose to write to a key — no built-in trail |
| How agents reach it | An MCP server any host calls directly — the tools appear alongside the agent's | A client library you wire in, and structure you design and maintain |
If the hard part is a distributed lock, a hot cache, a rate limiter, or a pub/sub bus — reach for Redis; it's the right primitive and nothing here replaces it. Reach for Ledgenter when the hard part isn't 'hold this key' but 'what's the state of the work across everything that touched it — who claimed what, what's blocked, what was decided, and is done real.' The two compose cleanly: keep Redis for the lock, the cache, and the rate limit, and coordinate the work itself over Ledgenter's MCP — claim the task, log the decision, write the finding, hand off — so the coordination is modeled and durable instead of hand-rolled into keys that expire.
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 task_claim just SET NX with extra steps?
For the lock itself, they're close — both hand exactly one caller the right to proceed, atomically, and Ledgenter leans on Postgres for that the way you'd lean on Redis. The difference is everything around the lock. A Redis lock is a key you hold and then release; when it's gone there's nothing to read, and if you didn't add fencing a delayed holder can still act on stale ownership. A Ledgenter claim is a lease on a task that keeps existing — it has a status other agents can read, a dependency graph that says what it blocks, an append-only trail of what was decided while it was held, and a 'done' that has to pass a check. The atomic grab is the small overlapping part; the durable, modeled work-state around it is the point.
Can I use Redis and Ledgenter together?
Yes — that's the intended shape, and they don't compete. Keep Redis for what it's unbeatable at: a hot cache in front of your data, a rate limiter, a pub/sub bus, a short-lived distributed lock for a critical section. Use Ledgenter for the work-state that has to outlive any one run — the task an agent claims, the decision it logs, the finding it writes, the handoff it leaves. One is the fast primitive under your infrastructure; the other is the coordination layer your agents clock into. Give Ledgenter's writes an idempotency key so a retried step doesn't double-write.
Redis is durable if I turn on AOF/RDB — doesn't that close the gap?
Persistence keeps your keys across a restart, which is real and worth turning on — but it doesn't turn a KV into a work model. You still have flat keys and values, not tasks with a dependency graph, not an append-only decision log, not a 'done' gated on a check. Durability answers 'will my data survive'; the gap Ledgenter fills is 'is the shape of the work — claims, blockers, history, verified done — a first-class thing the system enforces, or structure I designed on top and have to keep correct myself.' AOF makes the store durable; it doesn't make the coordination modeled.