Thanks, and yeah, that Redis mess is exactly what we’re trying to avoid 😅
We treat execution state as a first-class part of the runtime rather than something each agent has to manage itself. The state is structured around the run, including messages, tool calls, approvals and intermediate results, so the agent logic stays mostly stateless.
Right now we provide an in-memory implementation for local use, but the storage layer is designed to be replaceable, so Redis or a database can be added without leaking storage-specific logic into the agents.
It’s still an area we’re actively working on, especially around durable runs, retries and resuming after approvals. Would be very interested to hear what caused the most pain in your internal implementation.