Both systems coordinate AI and tool work as a network of tasks, and both are legitimate choices. They differ in what they optimize for. This page gives the plain-language version first, then the full technical comparison for engineers evaluating either one.
LangGraph is a broad, ready-made workflow platform. LoopKernel is a specialized runtime optimized for rapid reaction, traceability, and tight control. The short version
// the analogy
Imagine a manager coordinating researchers. The difference between these two systems is mostly a difference in how that manager works.
| The question | LangGraph | LoopKernel |
|---|---|---|
| How is work coordinated? | Work proceeds in rounds. The manager waits for everyone assigned to the round before making the next decision. | The manager reacts whenever one person finishes, even while others are still working. |
| Where is information kept? | On a shared project whiteboard that multiple workers update. | In separate, attributable records for each task. |
| Can unnecessary work stop early? | Normally the current round reaches its synchronization point first. | Remaining workers can be cancelled as soon as enough successful answers arrive. |
| How does recovery work? | Saves workflow checkpoints that support resuming and revisiting earlier states. | Saves current task status plus an audit journal of outcomes and planning decisions. |
| How much control is built in? | Highly flexible — your application team defines the safety and authorization policies. | Ships with a restricted toolset, provenance controls, and a separate gateway for model access. |
| How mature is the platform? | Extensive ecosystem — deployment tooling, streaming, debugging, integrations. | Smaller, purpose-built runtime with fewer platform features. |
// what it means in practice
Suppose three researchers investigate the same question, and two satisfactory answers are enough to proceed.
That can reduce response time and avoid paying for work nobody needs. The trade-off is real: LoopKernel's planner has to handle a more complicated mixture of finished, failed, cancelled, and still-running tasks.
LangGraph works like a shared whiteboard — flexible and convenient, but if you need to know who contributed each fact and who was allowed to read it, your team has to design and enforce that discipline. LoopKernel keeps every result attached to the task that produced it, so origins are easier to inspect. Selected workflows can restrict a worker to evidence produced by its predecessors, though that restriction is opt-in rather than the universal default.
LangGraph takes comprehensive checkpoints, which gives it strong resume, history, and "time travel" capabilities. LoopKernel stores current status alongside an ordered audit journal — recoverable and inspectable, but not a pure event-sourcing system that rebuilds everything from historical events alone.
LangGraph is deliberately neutral: organizations can build strict deterministic workflows, or give an AI model significant decision-making authority. LoopKernel starts with tighter boundaries — an approved-capability list, restricted planner actions, provenance-oriented memory, and a gateway that keeps provider credentials outside the runtime. It can optionally use an AI planner, but that planner's proposed actions are constrained and validated before anything runs.
Choose LangGraph when ecosystem maturity, standard integrations, broad workflow flexibility, debugging tools, and faster adoption matter most.
Choose LoopKernel's architecture when rapid reaction to partial results, early cancellation, per-task auditability, evidence lineage, and tightly enforced execution boundaries are central requirements.
The full technical comparison, verified against LangGraph's official docs.
// side by side
| Dimension | LangGraph | LoopKernel |
|---|---|---|
| Graph definition | Topology declared with StateGraph and compiled. Conditional edges, Command, and Send provide runtime routing and dynamic fan-out. |
Per-run topology is emergent: the planner returns a GraphPatch (add / connect / cancel / wait / resume / finish) for each event. |
| Execution model | Pregel / Bulk Synchronous Parallel: activated nodes run in a superstep; channel updates become visible at the next barrier. | No wave-wide barrier — wakes on first completion; the planner runs after each durable completion while siblings may still be active. |
| Communication | Nodes read shared typed state and return partial updates; reducers combine concurrent writes. | Results stay attached to individual nodes. Tasks marked evidence_scope: "ancestors" receive only transitive graph ancestors. |
| Durability | A checkpointer saves full state snapshots at superstep boundaries plus per-task writes during a step. | SQLite stores materialized run/node/edge state plus ordered events and idempotent patch records; missing patches are recovered by replaying terminal events. |
| Failure semantics | A failed superstep doesn't apply its updates; checkpointed task writes are retained on resume. External side effects aren't rolled back. | Worker exceptions become task_failed events; sibling results remain materialized and the planner can add recovery work. |
| Cancellation | Core execution waits for selected superstep actors to complete, fail, or time out. | A patch durably cancels an active sibling: CANCELLED is written first, the coroutine is cancelled, late results are discarded. |
| Control flow | Framework-neutral: deterministic edges or LLM-chosen tools, the application decides. | Deterministic by default; an opt-in LLM planner proposes strictly parsed patches from allowlisted roles. |
| HITL / waits | interrupt() checkpoints a thread; resuming restarts the interrupted node from its beginning. |
A pending node enters WAITING; a trusted external event applies a resume patch. No node restarts. |
| Identity | A thread_id spans invocations and conversation turns. |
A run_id identifies one durable request graph: context, nodes, patches, events. |
| Scope | General-purpose library and platform: streaming, subgraphs, Studio, deployment, many persistence backends. | Purpose-built runtime: provenance-bearing memory, constrained skills, gateway-only model access, A2A integration. |
// deep dive
LangGraph's Pregel heritage means parallel branches synchronize at a superstep boundary: actors selected for step N execute, then channel updates apply, then step N+1 is planned. During execution, those updates are invisible to other actors. LoopKernel instead wakes on the first completion and replans immediately while siblings are still running.
This is why speculative quorum is a natural fit for LoopKernel's executor. When two of
three speculative researchers succeed, quorum evaluation selects the two stable winners and
the planner cancels any still-pending, waiting, or running loser before adding the distill
step. A normal LangGraph superstep would let all actors selected for that step reach the
barrier before their updates drive the next step — matching the exact early-quorum behavior
would require additional orchestration rather than a straightforward parallel
StateGraph branch.
LangGraph's failed-superstep behavior is transactional only with respect to graph state updates: with a checkpointer, successful task writes are durable and reused on resume, while arbitrary side effects are not rolled back. LoopKernel exposes partial frontier outcomes directly to its planner, which improves reaction latency but requires the planner to reason about mixtures of succeeded, failed, running, and cancelled nodes.
In LangGraph, developers normally define node types and routing structure before
compiling the application; runtime decisions use conditional edges,
Command(goto=...), and Send. In LoopKernel, durable task instances
and their edges are created incrementally by a planner that receives
(snapshot, event) and emits the next graph mutations.
Indexing a directory is a clear example: listing must finish before the runtime can
create one stable index task per discovered file. LangGraph's Send API can
express the same unknown-cardinality map, so the important difference is representation,
not capability: LangGraph dynamically invokes declared nodes inside a compiled program;
LoopKernel persists newly added task nodes and edges as the run's graph.
LoopKernel's topology is dynamic but its authority surface stays closed: a task's skill must resolve in the worker registry, the store rejects duplicate IDs, unknown endpoints, invalid state transitions, and cycles, and the optional LLM planner may only add allowlisted roles.
LangGraph nodes normally read graph state and return partial updates, with reducers specifying how parallel writes combine. Applications can store provenance as structured values, but LangGraph does not automatically treat graph ancestry as a read-access policy.
LoopKernel retains each result under the task that produced it, making task identity and lineage directly inspectable. The visibility rule is precise:
evidence_scope: "ancestors" receives only
transitive parents reachable through incoming edges — never unrelated completed
siblings.The answer stage adds another policy layer: memory and graph results become bounded, typed evidence entries; user facts retain source attribution; external pages are never represented as user statements; and claims must cite supplied source URIs. Those are application-level guarantees rather than properties of graph scheduling itself.
LangGraph checkpointers save a full StateSnapshot at each superstep
boundary, plus individual task writes during the step — supporting resume, checkpoint
history, state edits, replay, and time-travel forks.
LoopKernel maintains current graph state directly in SQLite (runs, nodes, edges). Alongside it, an events table records lifecycle outcomes and a patches table records one idempotent planner decision per triggering event. On startup or resume, terminal events without a corresponding patch are found and planned exactly once. Previously successful nodes remain successful; nodes interrupted while running return to pending.
This is journaled and replay-safe, but it is not strict event sourcing: snapshots read the materialized tables rather than being rebuilt from the log. The honest trade: LangGraph centers execution history on checkpointed shared state and task writes; LoopKernel centers it on materialized task state plus an auditable outcome/patch journal. LoopKernel makes planner reasons and graph mutations easy to inspect; LangGraph provides richer checkpoint branching and time travel.
LangGraph itself is neutral about whether an LLM controls routing — a
StateGraph can be a fully deterministic workflow, a tool-calling agent, or a
mixture, and langchain.agents.create_agent lets the model choose from supplied
tools.
LoopKernel defaults to deterministic intent routing and planning, with a hard worker registry controlling executable skills. Its LLM calls reason over supplied evidence or perform bounded roles; they do not receive arbitrary tool authority. When the optional LLM planner is enabled, strict parsing limits proposed patches to safe IDs, allowlisted roles, known mutation fields, and store-level graph invariants — with deterministic fallback on invalid output.
The architectural distinction is therefore application-enforced authority, not "LangGraph lets the LLM decide and LoopKernel never does." LangGraph lets developers build either policy; LoopKernel ships one constrained policy and enforces a separate gateway boundary so the runtime never owns provider credentials.
A LangGraph thread_id is a persistent cursor for state that survives and
accumulates across invocations. Calling interrupt() inside a node saves the
graph's position; resuming with Command(resume=...) restarts that node from
its beginning, so preceding side effects must be idempotent.
A LoopKernel run_id identifies one request graph. Its stored context —
original prompt, memory scope, source identity — lets an HTTP resume reconstruct the
request. A graph patch can place a pending node in WAITING; the executor
returns when nothing is runnable. A trusted transport event later journals and applies a
resume patch. The wait occurs between worker attempts rather than
suspending and restarting inside a worker function.
// trade-offs
LangGraph when a project needs a mature general-purpose graph framework: shared typed state, reducers, subgraphs, streaming, HITL, checkpoint branching, or platform tooling. Its barrier model naturally fits fan-out/fan-in workflows, and its APIs support both deterministic and agentic control flow.
LoopKernel when per-task auditability and provenance dominate, when speculative work should stop the moment a completion quorum lands, when downstream evidence must follow explicit lineage, or when executable actions and provider access must be provably constrained.
The most honest framing: LoopKernel is not a smaller LangGraph. It is a purpose-built
runtime that chooses completion-driven graph mutation, explicit task results, an
outcome/patch journal, and application-level authority boundaries. A LangGraph port could
reproduce most LoopKernel workflows — but preserving exact per-completion replanning and
active-sibling cancellation semantics would require deliberate additional orchestration
rather than a direct StateGraph translation.