A workflow that dies at step seven of twelve should not send you back to step one. It should pick up at step seven with everything it already learned still in hand.
Almost no one builds it that way. We build agents that are impressive when they work and completely amnesiac when they break. Then we blame the model.
What's becoming clearer to me is that reliability in agentic systems is not a model problem. It is a state problem. The agents that actually finish the job are the ones whose progress survives a crash, and that is something you design, not something you prompt for.
Why Do AI Agent Workflows Fail Like Dropped Calls Instead of Failing Like Software?
Normal software fails loudly and locally. A function throws, you get a stack trace, you fix the function.
AI agent workflows fail quietly and globally. The agent drifts, a tool returns garbage, a context window overflows, and the whole run collapses into a pile of text you have to read to understand. There is no stack trace. There is a transcript.
I have watched this play out across the AI companies I currently run. The pattern is always the same. Somebody builds a genuinely good workflow, it handles eighty percent of cases beautifully, and then the twentieth percent eats an entire afternoon of manual cleanup. The work is not the failure. The work is reconstructing what the agent knew before the failure.
That is where AI agent workflow recovery starts: treat a run as a durable object with a life of its own, not as a conversation you hope stays alive.
Three things break in the halfway-fail scenario, and they break in this order:
- Tool output gets lost. The agent pulled the client's last six months of tickets, and that data lived only in the context window. Window resets, data is gone, and now you are re-pulling it or, worse, guessing.
- Human decisions get lost. The agent asked you a clarifying question and you answered it. That answer was the whole point of the run. It vanished with the session.
- Position in the sequence gets lost. The agent does not know it already drafted the proposal outline, so it drafts another one, slightly differently, and now you have two.
None of these are intelligence failures. They are bookkeeping failures. Bookkeeping absolutely bores me, which is precisely why I automate it instead of trusting vibes.
How Do You Checkpoint an Agent Run So Context Survives a Crash?
You write state to disk after every meaningful step, not after the run finishes. That is the whole idea. A checkpoint is a small file that says: here is the task, here is what I know, here is what I have produced, here is what is left.
I use a structure that looks roughly like this on every run:
`json { "runid": "client-acme-2026-03-14-01", "clientid": "acme", "goal": "draft renewal proposal", "stepscomplete": ["pulltickethistory", "summarizeissues"], "artifacts": {"ticketsummary": "...", "openrisks": ["..."]}, "openquestions": ["is the Q3 discount still approved?"], "nextstep": "draftpricingsection" } `
The practical moves that make this work:
A run ID and a client ID on every checkpoint. I key everything on the client so context accumulates across runs, not just within one. When Acme comes back next quarter, the agent is not starting from zero about Acme. It is starting from the last checkpoint plus everything since.
Artifacts, not transcripts. Save the summarized output of each step, not the full back-and-forth. Transcripts blow up context windows and make recovery slower than the original run. A good summary of the ticket history is worth more on resume than four thousand tokens of raw JSON.
State in something you can query. For lighter builds I use Airtable or a plain Postgres table with a JSON column. For heavier stacks I use Supabase and write through a small function so nothing gets skipped. If you are building no-code AI agents in n8n or Make, the built-in execution log is not enough. Write your own row at each node, because execution logs expire and your client context should not.
Checkpoint before the expensive step, not after. If step seven costs money or takes four minutes, write the checkpoint at the start of six. That way a failure at seven costs you one step, not six.
This is context engineering for founders in its most unglamorous form. Not prompt poetry. Just durable, boring, queryable memory.
What Should Happen the Moment a Step Fails?
Failure handling should be a branch in the workflow, not an alert in your inbox. I want the agent to do four things in order, automatically.
First, classify the failure. Is this retryable, fixable by a human, or fatal to the whole run? A rate limit is retryable. A missing API credential is fixable. A client who does not exist in your CRM is fatal, and pretending otherwise wastes everyone's time. Encode those three into the workflow as explicit paths and stop letting the agent improvise.
Second, retry with a slightly different approach, not the same one. Same prompt twice is the definition of hoping. If the tool call failed, retry once with a narrow scope, once with a different tool if you have one. I use the model's own judgment here by telling it plainly: attempt one more time, then escalate. Two attempts is usually right. Five is how you burn tokens to learn nothing.
Third, write the failure into the checkpoint. The checkpoint should now say what failed and why, so the recovery run does not repeat the same dead end. This is the single most-skipped step in agentic workflow error handling, and skipping it is why people's agents loop.
Fourth, escalate to a human with the state attached. Not "an error occurred." Something like: "I pulled Acme's ticket history and summarized the open risks. I could not pull the billing record because the API returned 403. Do you want me to proceed with the pricing section using the contract amount, or should I wait?" That message takes me a minute to answer. It saves me forty minutes of reconstruction.
Set the escalation threshold low. I would rather answer a question than debug a mystery.
How Do You Resume Without Repeating Work You Already Paid For?
Resume is a separate workflow, and it should be built as one. Do not try to make your main workflow self-healing across every failure mode. Give it a sibling that starts by reading the last checkpoint and asking one question: what is the cheapest path to done from here?
Then make it explicit. The resume workflow should load the checkpoint, verify the artifacts still exist, re-run only the steps listed as incomplete, and pass the accumulated artifacts forward. If the client record changed since the checkpoint, say so and let a human decide whether to refresh.
Two concrete things I do that pay for themselves immediately:
Idempotent steps. Every step that writes something external should be safe to run twice. Before creating a document or sending a message, check whether it already exists using the run ID. Without this, recovery becomes duplicate generation, and duplicate generation becomes the most annoying cleanup job in the business.
A weekly review of failed runs as a set, not individually. I look at every run that escalated in the past seven days and ask one question: what would have made this recoverable without me? Usually it is one missing field in the checkpoint. Fix that field and the class of failures disappears. That is the compounding part.
Because of that habit, the number of escalations drops every month even as the number of runs grows. The system is getting quieter, which is what I want from a system.
Does Recovery Need a Real AI Agent Operating System, or Can I Hack It?
You can hack it, and for three clients you should. A checkpoint file and a retry branch will get you a long way.
Where the hack breaks is when you have thirty clients, eight workflows, and a scheduled job that moves between them. At that point the thing you actually need is an AI agent operating system: one place that holds client context, one place that owns run state, and one place that decides what happens next. Not a chatbot. A layer.
The distinction matters because recovery is a property of the layer, not the agent. If every workflow writes to the same state store and reads from the same context store, then any agent can pick up any run. That is when you stop thinking about which agent is running and start thinking about whether the work is done. Agentic, in the useful sense of the word.
This is the part that takes me a minute to explain and years to appreciate: the agents that scale are not the smartest ones. They are the ones whose failures are cheap.
FAQ
How often should an agent checkpoint its state? Before every expensive or external step, and after every step that produces an artifact. In practice that means every step that costs money, calls an API, or writes something a human will see. Read-only reasoning steps do not need their own checkpoints if the surrounding ones are solid.
Can I do this with no-code AI agents in n8n or Make? Yes. Both let you write to an external store mid-workflow, which is all a checkpoint really is. Use a Postgres table, Airtable, or Supabase, write a row at each major node with the run ID and accumulated artifacts, and build a second workflow that reads the last row and resumes. Do not rely on the platform's execution log, because those get pruned.
How do I stop the agent from repeating a failed step forever? Cap attempts at two and write the failure reason into the checkpoint so the resumed run can see it. A loop almost always means the failure was never recorded, so the agent has no memory that the path is closed. Once the failure is durable state, the loop stops.
I wrote the full playbook for this. How to Build Your Own AI Agent Operating System walks you through the exact architecture I use, step by step, including the checkpoint schema and the resume logic. You can get it at a.mastermindshq.business/ai-os-book.