Ledgenter vs an agent orchestration framework
A framework like LangGraph, CrewAI, or AutoGen models your agents as a graph: nodes do work, edges pass control, and the whole thing executes start to finish inside one run. It's good at exactly that — how a set of agents flows through a task in a single process.
Ledgenter is a different layer. It isn't an executor; it's the durable, shared work-state — projects, tasks, decisions, knowledge, handoffs — that any agent or session reads, independent of which framework (or none) is driving. The framework answers 'what's the next node.' Ledgenter answers 'what did the last run decide, and what's still open.' Most real systems need both.
A framework drives one run; Ledgenter holds the state that outlives it. They compose — reach for Ledgenter the moment work spans more than one run, agent, or framework.
| Dimension | Ledgenter | An orchestration framework |
|---|---|---|
| What it is | Durable shared work-state, read by any agent or session | A control-flow graph you define and run in code |
| Lifetime | Outlives every run — state persists across sessions, agents, even frameworks | Lives inside one execution; gone when the run ends |
| Coordination | Atomic task claims + handoff inboxes — agents self-coordinate over shared state | Edges wired ahead of time — coordination is the path you coded |
| Memory | Decisions and knowledge are first-class, searchable, permanent | In-run message history / scratchpad — you persist it yourself |
| “Done” | Gated on a dependency graph and a verification check | Whatever the next node assumes — no check on the claim |
| Across runs & sessions | Many agents, many sessions, one shared state — by design | One process, one run; cross-run sharing is yours to build |
| Coupling | An MCP server over open primitives — framework-agnostic | Your logic is the framework's graph API |
If your workflow is a fixed pipeline that runs start to finish inside one process — fan out, gather, return — an orchestration framework is the right tool, and Ledgenter doesn't replace it. The two compose: let the framework drive the run, and let Ledgenter hold the state that has to outlive it. The case for Ledgenter is the moment work spans more than one run, more than one agent, or more than one framework — when the real question becomes 'what's been decided and what's still open,' not 'what's the next node.'
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 LangGraph or CrewAI already coordinating my agents?
Inside a single run, yes — that's what they're for. The gap is everything outside that run: when the graph finishes, its state evaporates. A second agent, a later session, or a human picking the work back up has no shared record of what the first run decided or what's still open. Ledgenter is that record — durable, shared, and queryable — so coordination survives the end of a run instead of resetting with it.
Can I use Ledgenter and an orchestration framework together?
Yes — that's the intended shape. The framework is the executor within a run; Ledgenter is the shared state across runs. Agents call Ledgenter's MCP tools from inside your framework's nodes: claim a task, log a decision, write a finding, hand off to another agent. The graph decides the next step; Ledgenter remembers it for the next run.
My whole pipeline is one graph — do I even need shared state?
If it genuinely starts and finishes in one process and nothing else ever needs to know what happened, no — keep it simple. The need shows up the first time a second agent, a later session, or a person has to continue where the run left off, and 'it was in the message history of a process that already exited' stops being an answer.