Storage

Where a routine's records live. The artifact-db adapter behind every Desk, its limits and write rules, artifact assets, and the unverified alternatives reachable through MCP.

What it is

A routine’s store holds everything it remembers between runs: records, the Inbox, runs, settings, decisions and viewer state. [store] adapter in routine.toml (and [store] kind in app.toml) selects where it lives. The default, and the only one the Desk reads, is artifact-db: the database of the published Desk page.

Why it exists

Every run starts on a fresh machine with nothing from the last run. The store is the routine’s memory, and putting it in the Desk’s own database means the people who use the Desk and the run that writes it share one source, with no server to run.

How it works

Adapters

From skills/routineos/references/storage-adapters.md:

The registry records the artifact-db limits as a conflict (artifact-db-limits-vs-no-backend): the limits above and Anthropic’s “no backend” wording are both on record and not reconciled. A run writing to the store is pilot-verified (run-writes-artifact-db).

Anthropic’s help article on artifacts says persistent storage is on Pro, Max, Team and Enterprise, on web and Desktop; storage is personal or shared per artifact; it gives 20 MB per artifact and text only (support article, fetched 2026-10-30). That 20 MB figure is a third number beside the 25,000 docs and 256 KiB per doc that RoutineOS uses. Plan for the smallest until it is reconciled.

Write rules for artifact-db

• Build JSON with a script into a file and pass the file path, to avoid escaping errors.
• set on an existing doc fails unless it carries the current version. Read first, then set with the version.
• get on a missing doc returns text, not an error. Treat it as absent.
• Write the report, then state. A crash between them repeats work rather than losing it.
• A run can write to several artifacts if each declares db. Never point a probe at a real routine’s artifact.

In practice a run never writes the store by hand. It builds a run input and calls routineos.py write, which applies the write contract: only the collections the routine owns, with every rule checked.

Finding the store

A run whose skill does not name the store URL looks for the store by listing artifacts (run-finds-store-by-listing, pilot-verified). Name the Desk’s URL in the routine so a run never guesses.

Other stores reachable by MCP

These are reachable as MCP servers or connectors, per their own docs. RoutineOS has no adapter for any of them, and none has been called from a routine.

The Postgres, SQLite, Google Drive and Redis reference servers in modelcontextprotocol/servers are archived (repo, fetched 2026-10-30). Do not build on them.

Worked example

Hiring Signals uses the default:

[store]
adapter = "artifact-db"

Each run writes its role and company records, Inbox messages and a run record through routineos.py write. As an example figure, 40 roles a run at two runs a week is about 4,200 role docs a year if every role were new, inside 25,000 but not by a lifetime. Sightings of the same role update one doc, so the real number is lower. The routine’s README should still say what to prune when it gets close.

Common pitfalls

• A plain set on a doc that exists. It fails without the current version.
• Reading “not found” text as data. A missing get returns text.
• Writing state before the report. A crash then loses items instead of repeating them.
• Pointing a test at the real Desk. Use a throwaway artifact.
• Assuming a database MCP is safe unattended. Supabase and Neon both warn against it.

Related

• Store and write contract
• Store collections
• Desk capabilities