Semantic Kernel
Save a note with a Semantic Kernel native function, then read the same file in a fresh worker.
mountable.io is a persistent filesystem for AI agents. A Semantic Kernel plugin 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 Microsoft. It registers real @kernel_function methods with
Kernel.add_plugin and calls them through Kernel.invoke. It checks native
function dispatch and storage without a model call. It is not a Semantic
Kernel memory backend.
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/semantic-kernel-workspace
uv sync --locked
export FS_ID=your-filesystem-id
export NOTE_PATH="sk-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 semantic-kernel 1.45.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 constructing NotesPlugin. The write function exposes only text.
The read function exposes no arguments. The invoke_note wrapper rejects
extra arguments before dispatch because KernelArguments accepts extra keys.
Generated function metadata alone is not an authorization check.
A new Kernel in the second process reads the saved file through a read-only SDK session. The note does not come from a previous function's return value. SDK permissions apply to the whole filesystem; the plugin fixes 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 sk-note-review.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 -qThe tests exercise actual Kernel metadata and 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: Microsoft native plugins, Kernel.invoke, Files API.