Agent durability? Yes
From reading 2.0’s docs and code, the concepts feel like there is some sort of analog/overlap with CQRS and Functional Event Sourcing. I haven’t thought it through, and am just spit-balling here … I see vaguely see similarities and differences:
Not a critique in any way, just reconciling my own mental model of the approaches.
Both:
- keep the decision logic purely functional
- makes outcomes explicit as data
- lets infrastructure execute side-effects outside the core
Differences:
- what is emitted
- CQRS/ES Aggregates (i.e. Commanded or the Functional Deciders) use “events” as the canonical output.
events = f(command, state)
- Jido Actions have state+directives as the canonical output.
{state, directives} = f(command, state)
- CQRS/ES Aggregates (i.e. Commanded or the Functional Deciders) use “events” as the canonical output.
- Ownership of side-effects:
- CQRS/ES Aggregates: downstream observers own the decision about what side-effects to perform; more descriptive.
- Jido Actions: agents (the producer) owns the decisions about side-effects; more prescriptive.
- State
- CQRS/ES – state is a projection of events; events are the source of truth
- Jido Agents – current agent state an object, and is snapshotted.
References:
Round about way to get to my question…
I see that Jido has Threads, and storage docs diagram states that agent state is a projection of threads, and that the thread is “Replayable, auditable” , but it seems like that the current state is what is snapshotted and serialized into a datastore; that the restoration is loading the serialized state directly. Am I reading correctly that “state checkpointing” is the durability strategy employed? That threads are more for auditing purposes – or LLM conversation building– instead of rebuilding state? What are your thoughts about the descriptive vs prescriptive nature of Aggregates vs Agents? Can we think of Agents as a kind of long lived Aggregate (DDD, not CQRS/ES)?
thanks ahead for clearing up my confusion 
