This is the canonical onboarding demo for AgentMemory.
It shows the most important current value of the project:
one memory backend exposed as one shared local runtime for different client surfaces.
Write memory through the HTTP API and read it back through the CLI using the same runtime and scope.
.\.venv\Scripts\agentmemory.exe configure --provider localjson
.\.venv\Scripts\agentmemory.exe doctor
.\.venv\Scripts\agentmemory.exe start-apiSuccess means:
doctorreports no blocking errorsstart-apiprints the API URL that the runtime is serving from
.\.venv\Scripts\python.exe .\examples\http_python_roundtrip.pyThis script adds a memory record through the local API and then performs a list and search through the same API.
Success means:
- the script prints
Created memory - the script prints both
List resultandSearch result
.\.venv\Scripts\python.exe -m agentmemory.ops_cli list --user-id examples-http-roundtrip --limit 5
.\.venv\Scripts\python.exe -m agentmemory.ops_cli search "provider contracts" --user-id examples-http-roundtrip --limit 5 --no-rerankSuccess means:
- the
listcommand shows at least one memory forexamples-http-roundtrip - the
searchcommand returns the memory written through HTTP
Without AgentMemory, each surface would need to embed backend-specific behavior separately.
With AgentMemory:
- the API, CLI, and MCP surfaces talk to one runtime
- provider-specific behavior stays behind the provider adapter
- multiple tools can share the same backend and scope model
Switch the provider to mem0 and rerun the same flow:
.\.venv\Scripts\agentmemory.exe configure --provider mem0 --openrouter-api-key "your-openrouter-key"
.\.venv\Scripts\agentmemory.exe doctor
.\.venv\Scripts\agentmemory.exe start-api
.\.venv\Scripts\python.exe .\examples\http_python_roundtrip.pyThe point is not that the commands change. The point is that the client surface stays stable even when the backend changes.
.\.venv\Scripts\agentmemory.exe stop-api