Share team memory with an editor

Prepare a local folder and install the published package:

Create a local folder and virtual environment for the examples on this page. The commands reuse an existing environment without changing its files:

Expected: ~/agent-memory-tutorials is your working directory and its virtual environment is active. Install the published SDK with the command below.

Each complete code block labelled Save as names a file to create in this folder using your editor. Copy the entire block, including imports and the entry point. Expand each helper disclosure and use Copy code to copy its full source. Keep all files together so their imports resolve.

When continuing from another tutorial or guide, retain the existing environment, configuration, session files, and .tutorial-state/. Reuse unchanged helper files; compare an existing file before replacing it, and finish any pending cleanup or recovery before changing the code that owns its state.

Keep agent-memory-tutorials/ as the working directory. Create a subdirectory and save all six complete files shown below. The diagnostic program reads the three .json.example files from its own directory, so retain their exact names and placeholders. Export the intended MEMORY_API_KEY and, for a private deployment, MEMORY_ENDPOINT before seeding; keep credentials out of these templates. Configure private editor copies separately in step 3.

The two servers are not the same tool surface. Decide once:

Use the hosted server unless you need memory to stay inside a boundary it cannot reach. Details: Hosted NAMS MCP Server and MCP Tools.

Key management requires an administrator credential or user token. The editor itself needs a workspace key with the intended data-plane scopes, bound to the team’s workspace. Create it in the NAMS dashboard and store it in that editor’s environment. A separate key per developer allows individual revocation.

The complete team-memory/seed_workspace.py defines its full DECISIONS transcript and handles the client lifecycle. From agent-memory-tutorials/:

The first command prints fictional fixture decisions without writes. Review them before running the second command, which creates a conversation in the configured workspace, adds two fixture entities (Atlas and Helios) and waits for extraction. Keep the printed conversation ID. A timeout exits unsuccessfully; do not treat a generic nonempty entity search as proof that this seed completed.

The fixture contains example architecture choices and invented benchmark anecdotes, not recommendations or measurements for your system. Replace it with approved team content only when ready. Preferences and facts are Bolt-only records; recording the same prose as a message does not recreate those APIs on NAMS.

team-memory/doctor.py runs five checks in failure-frequency order: key present and well-shaped, config files parse and name a real command or URL (and contain no pasted nams_ key; it does not detect a pasted Neo4j password or OpenAI key), the tool surface each server will expose, endpoint reachability with the workspace header, and whether extraction has settled for the seeded conversation.

Rather than hard-coding the tool counts, it registers each profile on a throwaway FastMCP instance with the library’s own registrar and lists what came back — so the local Bolt core/extended counts can be checked against the installed package. This does not enumerate an authenticated hosted server. Read check_tool_surface() in doctor.py for the dozen lines that do it.

--session-strategy per_day gives the self-hosted server one session id per user per day ("{user_id}-YYYY-MM-DD"), so a day’s work is one recallable thread instead of a new one per editor restart. Set MCP_USER_ID to distinguish people.

If the host does not expose a conversation read for your scopes, inspect tools/list and use an authorized SDK readback instead of claiming successful recall.