Pydantic AI and Mem0

Store a Pydantic AI note on mountable.io and read it from a later process. Keep one JSON file of a user's Mem0 records.

A Pydantic AI run can write a summary and then exit. The next process does not have that summary.

mountable.io is a persistent filesystem for AI agents. The note is a file there. A later process reads the same file.

mountable.io maintains these community recipes in one example. They are not Pydantic AI or Mem0 packages.

Prerequisites

Use an existing mountable.io account with a saved payment method, an existing filesystem and an API key that can access it. Storage and file operations follow the usage prices. The example creates no account, filesystem or credits.

You also need Python 3.11+ and uv. Set MOUNTABLE_API_KEY in your private environment or secret manager. Never put a key in a command argument.

git clone https://github.com/writeitai/mountable.git
cd mountable/examples/external-integrations
uv sync --locked

Your backend chooses the filesystem. Do not let a model choose another user's filesystem.

Create a note

create_note writes notes/<filename>.md. The model chooses the filename and the text. Use a Markdown name such as summary.md. The note is UTF-8 text up to 16 KiB. The write uses If-None-Match: *, so an existing file stays as it is. After a timeout, read the note before creating it again.

import os
 
from mountable_sdk import Mountable
from pydantic_workspace import build_agent
 
with Mountable() as client:
    fs = client.filesystem(os.environ["MOUNTABLE_FILESYSTEM_ID"])
    agent = build_agent(os.environ["PYDANTIC_AI_MODEL"])
    result = agent.run_sync("Create summary.md about this task.", deps=fs)
    print(result.output)

For a model call, install that provider in your own application. One example is pydantic-ai-slim[openai]==2.60.0. Supply that provider's key. PYDANTIC_AI_MODEL selects the model. Provider usage has its own bill. The filesystem cap does not cap model spending.

A 402 with filesystem_spending_cap_reached stops that user's billable mountable.io work. Other filesystems keep working.

Read it from a fresh run

A new process opens the same filesystem and calls read_note with the same filename. The note is still there.

Use a read-only handle when that process should not write:

fs = client.filesystem(os.environ["MOUNTABLE_FILESYSTEM_ID"], "ro")

Export Mem0 records

mem0_snapshot.py reads one user's records from Mem0 and writes one new JSON file on mountable.io. A later worker reads that file. This sits next to Mem0. It does not replace Mem0's storage.

Set MEM0_API_KEY, MEM0_USER_ID, MOUNTABLE_API_KEY and MOUNTABLE_FILESYSTEM_ID, then run:

MEM0_TELEMETRY=false uv run mem0_snapshot.py

The command prints the file path and the record count. It does not print the memories. Each run picks a new filename. It does not change Mem0's records. This is a point-in-time export of the records Mem0 returned. It is not a backup, and it does not restore Mem0.

Your backend chooses the Mem0 user id. The example stops at 1,000 records and 1 MiB.

Offline checks

From the example directory:

MEM0_TELEMETRY=false uv run pytest -q

The tests run real Pydantic AI and Mem0 clients against a fake filesystem. They make no paid cloud or model calls.

Sources: Pydantic AI tools, Mem0 quickstart, Files API.