What's interesting is how 'durable' in multi-agent systems means something different than it does in traditional distributed systems. There it's about surviving crashes. Here it's about surviving a model deciding to do something you didn't plan for, which is a much harder problem since the failure mode is behavioral, not mechanical. LangSmith's tracing helps you see it after the fact, but catching it before it cascades to the next agent is still mostly manual review in my experience.
The atomic decision so approval, rejection, and expiry can't resume the same thread twice is the right invariant for the graph. I'd still separate that from side effects a specialist already fired: a Postgres checkpoint that a tool call started is not the same as knowing the external write committed. If the worker dies after the API accepted the request but before the checkpoint records the result, does resume treat that call as unsent and fire it again?
Paused runs that resume on a new graph version are where I've seen teams get burned. The checkpoint saves the thread, then a deploy swaps the graph, and the approval path either deadlocks or double-fires. I'd gate every release on a resume-from-old-checkpoint test before the rest of the eval suite.
What's interesting is how 'durable' in multi-agent systems means something different than it does in traditional distributed systems. There it's about surviving crashes. Here it's about surviving a model deciding to do something you didn't plan for, which is a much harder problem since the failure mode is behavioral, not mechanical. LangSmith's tracing helps you see it after the fact, but catching it before it cascades to the next agent is still mostly manual review in my experience.
you don't need to fix the extractor. you need a scope and an expiry on every memory write.
The atomic decision so approval, rejection, and expiry can't resume the same thread twice is the right invariant for the graph. I'd still separate that from side effects a specialist already fired: a Postgres checkpoint that a tool call started is not the same as knowing the external write committed. If the worker dies after the API accepted the request but before the checkpoint records the result, does resume treat that call as unsent and fire it again?
Paused runs that resume on a new graph version are where I've seen teams get burned. The checkpoint saves the thread, then a deploy swaps the graph, and the approval path either deadlocks or double-fires. I'd gate every release on a resume-from-old-checkpoint test before the rest of the eval suite.