Runtime
The runtime decides what happens to a run’s work when the process dies. With a durable runtime, every model call and tool dispatch is recorded in a journal. Restart the process, continue the same session, and steps that already finished return their recorded results instead of running (and billing) again; only the unfinished work re-executes. Use one for long or expensive runs that must survive crashes and deploys.
from loomflow import Agent
from loomflow.runtime import SqliteRuntime
agent = Agent(
"...",
model="claude-opus-4-7",
runtime=SqliteRuntime("./journal.db"),
)Each journal entry is keyed by the session and user, the run, the step’s name and a fingerprint of its inputs, so a step replays only when the same run is resumed with the same inputs. A run that finished is never replayed into the next request on the session; see Runs and epochs.
Three backends, same protocol
InProcRuntime (default; no durability) · SqliteRuntime (single file) · PostgresRuntime (production durable).Replay and resumeHow runtime.step() and runtime.stream_step() keep cached results stable across crashes. The agent.resume() API.CheckpointsTranscript snapshots with Tuning(checkpoint=True): resume without re-billing, or fork from an older point.SignalsPark a live run until your app delivers a named payload, for human-in-the-loop approvals.What gets journaled
Every wrap point in the agent loop:
model_call_<turn>: the streamed model response (text + tool calls + usage).tool_call_<turn>_<slot>: each parallel tool dispatch in a turn.persist_episode_<turn>: thememory.remember(episode)call.
Architecture-specific steps add more, for example plan_step_<id>
for each step of Plan-and-Execute.
Default: InProcRuntime
Without a runtime= kwarg, Agent uses InProcRuntime. There is no
journal and no durability, so a crash loses everything. That’s fine
for stateless one-shot scripts and tests.
When to upgrade
| Symptom | Backend |
|---|---|
| ”I want crashes to resume” | SqliteRuntime (single file) |
| “Multi-instance” | PostgresRuntime |
| ”Just dev / tests” | InProcRuntime (default) |
Where journaling matters
- Long-running runs. In research agents and multi-stage pipelines, one model call gone wrong shouldn’t lose the work.
- Expensive tool calls. Slow APIs, paid endpoints, work that’s hard to redo.
- Resumability after deploys. Restart the process, pick up ongoing runs.
The journal vs. the audit log. The journal is for correctness:
it stores every step’s result so a crash recovers cleanly. The
audit log is for compliance: it stores who did what, with HMAC
signatures and user_id attribution. They’re separate stores with
separate lifecycles. See Audit log attribution.