AER — durable recovery for agents
AER adds write-ahead logging and semantic idempotency to LangGraph agents, so that a crash never re-runs a side effect. Against a checkpoint-only baseline it does 48% less work after recovery, makes 31% fewer LLM calls and 30% fewer tool executions, and it recovered in every fault-injection trial where the baseline failed.
- Role
- Solo. Course research, Advanced Scalable Systems for Agentic AI
- Timeline
- Spring 2026
- Stack
- Python, LangGraph
The problem
While building agents at Insora, I ran into a problem that checkpoints alone can't solve. A checkpoint saves what an agent is thinking, but it doesn't prove which actions already happened. If the process dies after a tool call succeeds but before the next checkpoint gets saved, recovery just runs the action again: the email goes out twice, the database row is duplicated, the payment is made twice.
What I built
AER represents execution as an explicit step graph instead of an opaque loop. Every model call, tool invocation, result and dependency gets recorded in a write-ahead log before execution continues. When the runtime recovers, it reconstructs the graph and replays only the work that's actually missing.
The hard part was making external actions safely replayable. I implemented semantic idempotency, which identifies an action by its intended effect rather than by a generated request ID. That lets AER recognize that an equivalent action already completed, even when execution resumes along a different path.
Results
The poster separates two experiments: under fault injection, the checkpoint-only baseline recovered 0/5 runs while AER recovered 5/5; under crash recovery, AER reduced post-recovery steps by 48%, LLM calls by 31% and tool executions by 30%.
I evaluated it against a checkpoint-only baseline on 30+-step workflows with adversarially injected failures. In the three trials where the baseline failed to recover at all, AER recovered every time. The repo has a one-command demo and the experiments are reproducible.
What I'd do differently
I'm proud of this one because it came from a real failure I actually hit, and because the fix was better infrastructure rather than a better prompt. What I'd change is that I built it as a course project and measured it against my own baseline. The next step is adoption: a real agent, a real crash, someone else's workflow. I'd do that before adding a single feature.