sovseal-sdk’s store/recall methods as two @function_tool-decorated callables — named search_memory and save_memory here, but those are just this example’s chosen wrapper names, not sovseal’s own tool names. (sovseal’s actual methods are store/recall on the SDK, or the store_memory/recall_memory MCP tools if you’re going through an MCP client instead.) Any agent in your network — triage agents, specialists, or orchestrators — can read from and write to the same local zero-knowledge memory store this way. store/recall talk to the local ONEBRAIN engine over framed IPC, so memory retrieval adds no network round-trip to your runner loop.
Installation
Define memory-aware agents with handoffs
The example below creates atriage_agent that routes requests to either a travel_agent or a health_agent. All three agents share the same search_memory/save_memory tool wrappers, and the triage agent persists a summary of each session after the runner completes.
agents.py
How memory flows through handoffs
Whentriage_agent hands off to travel_agent, the specialist immediately calls search_memory before generating any output. This means the specialist inherits the user’s history without needing the triage agent to relay it explicitly — the memory store acts as a shared, always-available context layer across the entire agent network. Because AgentStateClient talks to the same on-device engine regardless of which agent calls it, this works with zero coordination code between agents.
Initialise
client once at module level and reuse it across all tool calls, as shown above — the native-host subprocess is spawned lazily on first call and reused across calls, so creating a new AgentStateClient per tool invocation adds unnecessary overhead. Requires the native host launcher at ~/.sovseal/native-host/run.sh (run npx -y @sovseal/mcp-server once to provision it — see SDK Reference: Overview).