No waiting for the slowest
Most systems work in rounds — everyone assigned to a round has to finish before the next decision gets made. LoopKernel reacts as soon as any one task finishes, while the rest keep going.
LoopKernel runs AI work as a team of tasks. The moment one finishes, it decides what to do next — while the others are still working. Every decision is written down, so you can always see how an answer was reached.
// in one sentence
Think of it as a manager coordinating a research team — one who reacts the moment any researcher reports back, instead of waiting for the whole group to finish. Faster reactions · less wasted work · a complete record of every decision
// how it works
Most systems work in rounds — everyone assigned to a round has to finish before the next decision gets made. LoopKernel reacts as soon as any one task finishes, while the rest keep going.
The workflow isn't fixed in advance. After each result, the planner adds the next tasks, connects them, or stops the ones that are no longer needed — one recorded decision at a time.
Every result stays attached to the task that produced it. A task can be limited to only the work it builds on, so discarded or unrelated work can't quietly shape the final answer.
Every outcome and every planning decision is written to disk as it happens. If the system restarts, finished work stays finished and the rest picks up where it left off.
// what you get
Things most frameworks expect your team to design and enforce themselves come with the runtime.
cost
Run three attempts at the same question. As soon as two succeed, the third stops immediately — even mid-run — so you don't pay for work you no longer need.
human review
A task can wait for human approval. The system stops cleanly, and when approval arrives the work carries on from where it paused — nothing is repeated.
control
Fixed rules decide what happens next, not a model's judgement. Letting an AI plan the work is optional, and anything it proposes is checked against strict limits first.
trust
Facts carry their source. Something read from a web page is never presented as something the user said.
safety
Tasks can only use capabilities from an approved list. The plan can grow while a run is in progress, but never beyond that list.
security
All access to AI models goes through a separate gateway, so the runtime itself never holds your provider API keys.
Everything above in the terms you'd use to evaluate the runtime.
// the loop
The planner receives (snapshot, event) and emits the
next graph mutation. Each patch is idempotent and journaled against its triggering
event — replay-safe by construction.
# event → planner → patch (illustrative trace)
event task_completed plan_0
patch add spec_1 spec_2 spec_3 # fan out 3 attempts
connect plan_0 → spec_*
event task_completed spec_2 # others still running
patch wait # 1 of 2 needed
event task_completed spec_1 # enough answers
patch add distill
connect spec_1 spec_2 → distill
cancel spec_3 # stopped mid-run
event task_completed distill
patch finishIllustrative trace of LoopKernel's patch semantics — public API docs are on the way.
// positioning
The two runtimes solve the same broad problem and make substantially different architectural choices. The honest version, side by side:
| Dimension | LangGraph | LoopKernel |
|---|---|---|
| Execution | Pregel supersteps — updates visible at the next barrier | Replans on first completion, siblings still active |
| Topology | Compiled StateGraph with runtime routing | Emergent — planner patches the graph per event |
| History | Checkpointed shared-state snapshots | Materialized state + outcome/patch journal |