Strands Agents

Save a note with a Strands Agents tool, then read the same file in a fresh worker.

mountable.io is a persistent filesystem for AI agents. A Strands Agents tool can save a Markdown note there so another worker can open it after the first process exits.

mountable.io maintains this community example separately from AWS and the Strands project. It defines real @tool functions and invokes them through Strands' validated tool-use stream with synthetic tool-use requests. It checks tool dispatch and storage without a model call. It is not a Strands session manager.

Setup

Use Python 3.11+ and uv, an existing mountable.io account with a saved payment method, a filesystem and an API key that can access it. Storage and downloads are ordinary paid usage at the published prices. The example creates no account, filesystem or credits and makes no model calls.

Keep MOUNTABLE_API_KEY in your private environment or secret manager. Never put it in source, command arguments or logs.

git clone https://github.com/writeitai/mountable.git
cd mountable/examples/strands-workspace
uv sync --locked
export FS_ID=your-filesystem-id
export NOTE_PATH="strands-note-$(uv run python -c 'import uuid; print(uuid.uuid4().hex)').md"
export NOTE_TEXT="Parser review complete. Open the stored note."

Dependencies are pinned to strands-agents 1.62.0 and mountable-sdk 0.3.0. The lockfile pins their dependency tree.

Save a note and read it in a fresh process

uv run python notes.py write --filesystem "$FS_ID" --path "$NOTE_PATH" --text "$NOTE_TEXT"
uv run python notes.py read --filesystem "$FS_ID" --path "$NOTE_PATH"

The writer prints stored. The separate read process prints:

Parser review complete. Open the stored note.

Your backend selects the authenticated user's filesystem and the note path before building the tools. The write tool exposes only text. The read tool exposes no arguments. Strands' input validation silently drops unknown keys, so the invoke_tool wrapper rejects extra arguments before dispatch. Generated tool schema alone is not an authorization check.

Fresh tools in the second process read the saved file through a read-only SDK session. The note does not come from a previous tool's return value. SDK permissions apply to the whole filesystem; the tools fix this one path. Use separate filesystems and appropriately scoped API keys for different users.

Preserve the first note

The note must be nonempty UTF-8 text up to 16 KiB, with a root filename such as strands-note-<id>.md. Create-only writes send If-None-Match: *. A second write to the same path returns HTTP 412 and leaves the first note intact. A read-only session refuses writes with HTTP 403.

Storage failures raise errors through the invocation wrapper. Writes are not retried. After a timeout, read the note before deciding whether to write again. A filesystem_spending_cap_reached error stops that user's billable filesystem work. See limits per end user. A filesystem cap does not limit a model provider's charges if you add a model later.

Cleanup

After the second worker has finished, delete just the note you created:

NOTE_SHA256=$(uv run python -c 'import hashlib,os; print(hashlib.sha256(os.environ["NOTE_TEXT"].encode()).hexdigest())')
uv run python notes.py cleanup --filesystem "$FS_ID" --path "$NOTE_PATH" --sha256 "$NOTE_SHA256"

Cleanup checks the note's hash and deletes with its current ETag. Changed bytes or a concurrent replacement refuse deletion. Deleted data remains billable until reclamation. Closing the SDK client closes its HTTP connections; server token sessions expire after one hour. If your application needs earlier cutoff, revoke only the sessions it created through the management API.

Offline checks

uv run --locked pytest -q

The tests exercise actual Strands tool schemas and tool-use stream dispatch with the released SDK over fake HTTP. They cover argument bounds, first-note preservation, read-only refusal, storage errors without retries and conditional cleanup. They make no cloud or model calls.

Sources: Strands tool decorator API, Files API.