The state problem in Claude workflows
You've built something useful with Claude. Maybe it's a research agent that scrapes a topic each morning. Maybe it's a code review assistant that checks PRs. Maybe it's a personal assistant you've wired up to your calendar and email.
And then you hit the same wall every Claude developer hits: where does anything actually live between sessions?
You've probably tried a few options:
- Files and text dumps — works until your agent has 300 research entries and you need to search them
- Notion or Airtable — heavy. Great for humans. Expensive on tokens when Claude reads them.
- Custom database tooling — solid choice, but now you need to ship database tooling alongside your actual application logic
- Putting everything in the system prompt — fine at 200 tokens. Terrible at 5,000.
Stash is the fourth option you probably didn't know existed: a hosted FTS5 record store that Claude talks to over MCP. You add it like any other connector. Your agent reads from it and writes to it. The data lives on industry-secure servers, not on your laptop.
What Stash gives a developer workflow
The tools your agent gets are:
That's it. Deliberately minimal. Each call costs you a fraction of what a Notion API read costs in tokens, because the response is structured and terse — designed to be parsed by Claude, not displayed to humans.
A concrete pattern: research agent with recall
Here's a real workflow. You have a morning briefing agent. Each day it:
- Checks Hacker News for items matching your interests
- Summarises the relevant ones
- Looks up anything it found before to avoid repeating itself
- Stores today's findings for future recall
Without persistence, step 3 doesn't exist. With a custom DB, you write a schema, migration, query layer, and serialisation — before you've even built the interesting part.
With Stash, the agent gets two extra instructions in its system prompt:
The MCP connector gives Claude the tools. You don't write any of the storage layer.
Another pattern: agent-to-agent handoff via shared state
If you run multiple Claude sessions — one for research, one for writing, one for review — they can share state through Stash collections. The research agent writes to research. The writing agent searches it. The review agent appends notes.
Each session starts with a fresh context window, but the accumulated knowledge persists. This is what you get from a vector database at 10x the complexity, for use cases where keyword recall is enough (and for most developer workflows, it is).
When FTS5 is enough: full-text search handles "find me anything about Redis performance in the last month" or "what did I store about that AWS architecture decision". If you need semantic similarity search — "find me records similar in meaning to this concept" — that's a vector database use case. Stash doesn't do that. We're clear about the boundary.
The collections pattern for agent workflows
Most agent workflows map cleanly to 3–5 collections:
| Collection | What lives here | Typical size |
|---|---|---|
| research | Daily findings, summaries, links worth keeping | 50–200 records |
| decisions | Architecture choices, tradeoffs, rationale | 20–80 records |
| contacts | People worth remembering — context, what was discussed | 50–150 records |
| agent_log | What the agent did, errors caught, notable runs | Rolling — purge oldest |
| context | Standing context — who you are, session defaults | 1 record (loaded via context()) |
The token cost matters in agent loops
If your agent calls Stash in a loop — each research run, each PR check, each morning briefing — you're adding tokens every iteration. This is where Stash's design matters.
A typical Stash search() response is 200–400 tokens for 5 matching records. The same data from Notion (reading a database page) costs 800–1,500 tokens and requires parsing. At 50 agent runs a month, that gap compounds.
We benchmarked this for a 500-record store: Stash returned matching results in ~192 tokens vs ~410 tokens for the equivalent Notion query. That's a preliminary single-test number — real ratios vary — but the direction is consistent because we design responses to be token-light by default.
Setup is 30 seconds
You don't configure anything. You add the MCP connector:
Sign in with Google. That creates your account, provisions a structured store, and seeds a context collection. Your agent can immediately call add() and search().
No Terraform. No Docker. No database migration. If you want to wipe the whole thing and start over, delete_collection() exists. If you want to hand your stored data to a different system, call search() with a broad query and pipe the output.
Free tier is enough to test
Free gives you 2,500 records and 50 queries per month. That's enough to build and validate most agent workflows before committing to anything. Pro is £8/month for 100,000 records and 1,000 queries — at which point your agent is doing real work and the cost is negligible against the value.
Pricing may change as we're a new service, but the free tier is a real tier, not a trial. Cancel anytime with no friction.
What Stash isn't
It's not a vector database. It's not a graph store. It doesn't sync from Notion or Google Drive. It doesn't have webhooks, streaming, or a web UI for editing records manually.
It's a record store Claude talks to. That's it. The scope is deliberate — every extra feature competes for tokens in your context window and makes the MCP surface harder to reason about.
If your workflow needs semantic similarity search, use a vector database. If it needs complex joins, use a full relational database. Stash fills the gap where you just need fast, cheap, searchable persistence that Claude can access in any session without you writing infrastructure code.
Add Stash to your Claude workflow
Claude → Settings → Connectors → Add custom connector → paste this URL:
Get started — free