Jido State Persistence Analysis
Summary
Jido DOES provide clean mechanisms for state persistence without framework modifications.
Available Persistence Hooks
1. mount/2
Callback
- Called when agent server starts
- Perfect place to restore persisted state
- Receives server state and options
- Can modify initial agent state
2. shutdown/2
Callback
- Called when agent is terminating
- Ideal for saving final state
- Receives server state and shutdown reason
3. initial_state
Parameter
- Pass initial state when creating agent:
new(id, initial_state)
- Pass initial state when starting:
start_link(id: id, initial_state: saved_state)
- State is merged with schema defaults and validated
4. State Change Hooks
on_after_validate_state/1
- Called after every state changeon_after_run/3
- Called after action execution- Perfect for incremental state persistence
Clean Implementation Pattern
defmodule PersistentAgent do
use Jido.Agent,
name: "persistent_agent",
schema: [data: [type: :map, default: %{}]]
# Restore state on startup
def mount(%{agent: agent} = server_state, _opts) do
case load_state(agent.id) do
{:ok, state} ->
{:ok, %{server_state | agent: %{agent | state: state}}}
_ ->
{:ok, server_state}
end
end
# Save state on shutdown
def shutdown(%{agent: agent} = server_state, _reason) do
save_state(agent.id, agent.state)
{:ok, server_state}
end
# Save after every state change
def on_after_validate_state(agent) do
save_state(agent.id, agent.state)
{:ok, agent}
end
end
No Framework Modifications Needed
The Jido framework already provides:
- Clean lifecycle hooks for state management
- Multiple integration points for persistence
- Flexible initialization with restored state
- No hacking or workarounds required
Conclusion
The initial assessment that Jido “doesn’t provide clean hooks” was incorrect. Jido is well-designed for state persistence with multiple clean integration points. No issue needs to be filed with Jido maintainers.