Published: 2026-05-07

AgentSpan Makes LangChain and CrewAI Pipelines Crash-Proof with Per-Step Persistence

Chapters / key moments (click to jump — plays here on the page)

AgentSpan is an open-source (MIT), self-hosted runtime that solves a fundamental problem with production AI agent pipelines: when a crash or restart happens, agents currently re-run from scratch and repeat every side effect — duplicate emails, double database writes, extra API calls. AgentSpan fixes this by moving orchestration state to a separate server and persisting every individual tool call, not just nodes. Built by the team behind Netflix Conductor.

Source video

"Agentspan: Build Crash-Proof AI Agents Pipelines (Free) with LangChain/LangGraph/CrewAI" by FuturMinds — Watch on YouTube →

Key Takeaways

Every individual tool call and LLM call becomes its own persisted task — more granular than LangGraph checkpointers, which only save at the node level.
Orchestration state moves to a separate AgentSpan server; your Python code becomes a worker that registers functions and receives dispatched tasks.
A crashed pipeline resumes from the exact failed step — completed tool calls are not re-executed, preventing duplicate emails, charges, or API calls.
Human-in-the-loop approvals are stored as durable tasks — a thread doesn't need to stay open for hours or days, and approval state survives process restarts.
MIT-licensed, fully self-hosted — your agent data never leaves your own infrastructure.
Works alongside LangGraph, CrewAI, and OpenAI Agents SDK — no framework migration required, just a few lines of change.

The Problem: Why Agent Pipelines Fail in Production

Every major agent framework today — LangGraph, CrewAI, OpenAI Agents SDK — runs the entire pipeline inside your Python process. Every LLM call, every tool call, every intermediate result lives in process memory. This creates four compounding problems: a single crash or container restart forces a full restart from scratch; there's no visibility on which agents completed or what they produced; restarting causes duplicate side effects from already-executed tools; and human-approval workflows require blocking an open thread for hours or days.

LangGraph has checkpointers (memory server, Postgres) but they work at the node level — they save state between agents, not within them. If a researcher agent calls three tools and crashes after the second, the checkpointer doesn't help: the entire node reruns. FuturMinds demonstrates this exact scenario: a researcher-writer-editor pipeline that crashes during the writer stage ends up sending duplicate notification emails to the team when restarted.

How AgentSpan Fixes It

AgentSpan separates your code from the execution state. Your code still defines the agents and tools — nothing changes there. But orchestration state (which agent runs next, what each previous agent produced, where in the pipeline you are) moves to a separate AgentSpan server. Your Python process becomes a worker: it registers tool functions with the server, receives dispatched calls, and returns results. The server persists every completed step.

When your Python process dies, the server still has the full workflow state. It knows which steps completed and which were in progress. When your process restarts, it picks up exactly where it left off. Already-completed tool calls are skipped entirely — no duplicate notifications, no double-charged transactions. Tool idempotency is built in at the platform level, not left to individual developers to implement per tool.

What you can actually set up from this

Extracted from the video's own transcript — the specifics the original summary left out.

Reproducible steps

Why agent pipelines are not durable by default
<strong>Four problems, and they are the clearest statement of this failure mode we have seen.</strong> Every LLM call, tool call and intermediate result lives in your Python process memory. So: <strong>(1)</strong> an out-of-memory error, a deployment or a container restart restarts every agent from scratch; <strong>(2)</strong> you have no visibility into which agents completed, what they produced or where they failed — you dig through logs; <strong>(3)</strong> rerunning tools repeats side effects, so <em>an agent that sent an email before the crash sends it again on restart</em>; <strong>(4)</strong> a human-approval step holds a thread open for hours or days, and a restart loses the approval state.
Why framework checkpointers do not solve it
<strong>The sharpest technical point in the video.</strong> Checkpointers save state <em>between</em> agents, at node level — not within them. So if an agent calls three tools and crashes after the second, the checkpointer does not help: <strong>the entire node reruns</strong>. With per-call persistence, every individual tool call and LLM call is its own persisted task. The granularity is the difference.
What the architecture change actually is
Your code still defines the agents and tools — nothing changes there. <strong>The orchestration moves to a separate server</strong>: which agent runs next, what the previous one produced, where you are in the pipeline. Your process becomes a <strong>worker</strong> that registers its tool functions with that server. The server dispatches work and persists the result of every completed step.
What recovery looks like
If the worker dies or is redeployed, the server still holds the workflow and knows step one completed and step two was in progress. When the worker comes back it polls, receives the pending work, and <strong>completed steps are skipped entirely rather than rerun</strong>.
Observability comes free with the persistence
Because every LLM call, tool call, timing and token count is already tracked to make recovery possible, a dashboard on a local port shows all of it — <strong>no extra setup and no third-party observability tool</strong>.

Gotchas

<strong>Sponsored — the video states the partnership up front.</strong> The runtime is MIT licensed, self-hosted, and the pitch is that data never leaves your infrastructure.
<strong>You do not replace your framework.</strong> The explicit claim is that this layers on top of LangGraph, CrewAI or the OpenAI Agents SDK with a few lines of change. The demo is a before-and-after of the same three-agent pipeline.
Tool idempotency is the part worth thinking hardest about: the email-sent-twice problem is the one that causes real damage, and it is a design question about your tools as much as about the runtime.
Built on a workflow engine that has been in production at large companies for close to a decade — which is a reasonable argument for the durability claims, and is still the vendor's framing.