I think we should add a distributed K-V store (Redis) in the initial release of this feature because for apps that have a distributed backend it would benefit from a centralized mechanism to store the state. After your ABC, I can add the redis implementation.

It might also be rad to also have an event driven version with tiered storage support from memory -> disk -> object storage. I can take a crack when the abc is available also.

Maybe you can take into consideration delegating state to sub graphs (where a node is another graph) that way the entire graph execution could be stored in a single state but also scoped per subgraph.

It complicates things a bit but sub graphs make much sense when it comes to complex agents execution (e..g, a main graph with a sub graph such "communication manager" that have multiple agents such "slack" and "gmail")

How would this work? We would pass a "connection or cursor" down to .next() and after it had run, it would store the history in the db?

Since we already have .dump_history() and .load_history(), in my opinion, that's what we need to persist state.

So, at least for v1, I would say that it should be the developer's reponsability to persist the given dump. This is straightfoward.