What you can do with Stompy
Eight things that get easier the longer you use them.
A chatbot on its own is clever and well read, and every morning it arrives knowing nothing about you. Stompy is the librarian it was missing.
A librarian doesn't write the books, and doesn't choose what goes on the shelves. You do that. What the librarian does is organise what you chose to keep, know exactly where everything is, and notice when something new arrives that clashes with what is already filed ("hang on, don't we already have an edition of this?"). Any AI you use can ask it. It never goes out collecting on its own: Stompy does not watch you work, guess what matters, or capture anything you didn't lock. The library is yours, and the AI borrows from it. (A librarian who read your post and shelved whatever they fancied would be a different job, and not one we'd advertise.)
There are three ways in: MCP, a REST API and a command-line tool. Everything below works through any of them.
What follows are eight sequences. Each one starts with something you do, shows what happens straight away, and then follows it through months of use, because the long chain is where the value is. Stompy has been our own daily tool for about a year, and everything below was built for a real job we needed done.
One record, every surface
Most AI use is scattered. A conversation on the web, a coding agent in the terminal, a phone app on the train, a second vendor's model for a second opinion. Each one starts cold, and you become the human clipboard between them.
- What you do.
Write a decision down once, in one project.
- What happens straight away.
Every tool you use reads that same record, live. The web app, the desktop app, the terminal, the phone, the browser extension, and the coding harnesses (Codex, OpenCode and the rest) all see one source of truth. This is not a sync that runs every few hours, and it is not copy and paste. You can have several sessions from different vendors open at once, working on one task, and none of them works from a stale copy.
- Where it goes over months.
Tools stop being commitments. You pick the model for the task: one for research, one for writing, one for code. You carry on at your phone what you started at your desk. When a better tool arrives you move to it without a migration, because nothing was ever stored inside the old one. Your knowledge belongs to you and not to a vendor, so if a platform changes its terms, the record stays where it is.
You stop repeating yourself, you stop keeping every tool up to date by hand, and you stop being locked in.
Rules that outlive the session
A decision made in a chat lasts as long as the chat. The next session has never heard of it, so you explain it again, or worse, you don't, and the model quietly does something different.
- What you do.
Lock the decision as a rule.
- What happens straight away.
Every later session, in any tool, starts from it. The most important rule of all sits in a single standing-rules context that every session checks. It points to the detail rather than repeating it, and you are the only one who updates it. That is deliberate: a short list that gets read every time beats a long one that gets skimmed.
- Where it goes over months.
Rules are versioned. When you change your mind, the new version replaces the old one and the old one stays in the history, so you can see what you believed at the time as well as what you believe now. Every item also has a state (active, parked, delivered or archived), so the record can tell you what is live and what has been put to bed. Mistakes go in the rulebook too, not only facts: when something goes wrong once, on something that mattered, you lock what went wrong and why, and every later draft starts with that lesson already in hand. Our own rules each earned their place by costing us something. After a year you have a body of rules that is small enough to read, honest about its own history, and carried into every session without anyone typing it out.
Your standards stop depending on whether the model happened to remember them.
A record that checks itself
Left alone, any store of notes fills up with repeats and contradictions. Humans learn to ignore the mess. A model can't ignore it. It reads all of it, and it gets confused by it.
- What you do.
Say "lock this". The model does the writing, and you decide what is worth keeping.
- What happens straight away.
When something is saved, Stompy compares it with what you already hold. The save always goes through. In the same reply, the model gets the closest existing entries and one question: does this relate to, depend on or contradict any of them? It can answer, or carry on. Only a genuine contradiction, or a replacement of something you locked, is put to you. Related entries you had forgotten surface this way too, so connections appear that nobody drew by hand.
- Where it goes over months.
Pile-ups happen to every store. What matters is that they get noticed and cleared out, not left to grow. Our own early store once piled up millions of repeated entries. We cleared them out, and almost everything since has run lean, because it was curated rather than logged. The model reads a record that has been kept that way, so its answers wobble less on stale or contradictory material.
The benefit lands mostly on the model doing the writing and reading. A cleaner place to work makes it steadier, and you notice that as better answers more than as a feature. It is the librarian's habit of noticing, built into the tool.
Long work that stays consistent
A long manuscript, a large codebase and a formal report have one thing in common: hundreds of small decisions that must not contradict each other. Nobody holds them all in their head, and a model certainly doesn't hold them between sessions.
- What you do.
Lock the canon: the characters, the rules of the world, the naming constraints, the architecture choices. Record each editorial decision together with its reason.
- What happens straight away.
Before the model drafts anything, it checks the work against the canon that applies. Continuity errors get caught before the page exists, and a later session doesn't quietly undo an earlier decision, because the reason is on file.
- Where it goes over months.
A session in month eleven knows what a session in month one decided. The same method carries from fiction to code to formal documents, because each one is simply a curated body of decisions. It carries to repeating work as well. A near-daily publishing routine can run entirely on locked rules: a check every piece passes before it ships, a start-up checklist that loads the voice and strategy before any drafting begins, and a rule for bringing older material back round. Ours has run that way for months. The record also keeps getting better with use, since every session leaves it a little more complete.
Consistency stops depending on anyone's memory, human or otherwise.
Work that survives the conversation
Chats end. The to-do list in someone's head doesn't survive that.
- What you do.
Keep decisions and requests apart. A decision settles what you claim or do. A ticket is a request to act on something already settled, and it sits on a board.
- What happens straight away.
The request outlives the chat that created it. Any person, or any model in any tool, can pick it up days later. The person picking it up has none of the original reasoning, so each ticket carries what they need: where, the exact content, why in one line, and what must not change. It closes with a note saying what was actually done, including where the result differs from the request.
- Where it goes over months.
One model acts as lead. It files tickets and hands them to worker sessions that may be running in other tools. The lead reads the state of the board itself rather than waiting to be told, because a worker that reports "done" is not the same as work that is done. This is a way of working that doesn't exist without a shared record, and it is the sequence that surprised us most.
Nothing here is automatic. No agent watches the board. Work starts when someone opens the project, which is the ownership principle applied to tasks: it surfaces when you bring it up.
Work stops living in somebody's head, or in a chat window that is about to close.
Teams on mixed tools
Teams used to standardise on one tool so that everyone shared context. That is a lot to ask when one person lives in a research tool, another in a writing tool and a third in a coding agent.
- What you do.
Put the work in a shared project. Each person carries on with whichever AI suits them.
- What happens straight away.
A teammate in a different AI sees what you decided without you having to tell them. A newcomer gets up to speed from the record, not from whoever has time to explain. Someone returning from leave opens the project, reads the brief and the log, and sees where things stand and what has been happening while they were away.
- Where it goes over months.
The shared record becomes the team's own account of why things are the way they are. People trust that they are up to date with what colleagues have found or decided, even when those colleagues are working in a different AI entirely. This isn't a plan for us: our own shared projects have carried hundreds of sessions of real work, with more than one person working in them at the same time.
The team gets one shared memory without anyone giving up the tool they work best in.
Measurements you can trust later
A number without a date is a rumour. By the time someone quotes it again, nobody can say whether it is still true.
- What you do.
Lock a finding together with the date it was measured. Give it a verify-by date.
- What happens straight away.
Anyone reading it knows how fresh it is and when it is due to be checked again. When the record and reality disagree, reality wins and the record gets corrected. The record is a working claim and not scripture.
- Where it goes over months.
You build up a dated body of evidence, and you can see at a glance which findings are fresh and which are overdue. The next piece of work starts from what was measured and not from what somebody recalls.
Decisions rest on evidence that says how old it is.
Smaller models get much smarter
A smaller model is usually short of context rather than short of intelligence. It doesn't know your project, your rules or your history, so it behaves like a stranger.
- What you do.
Keep the record, and let the model read what applies to the task at hand.
- What happens straight away.
It stops being a stranger. In our own benchmarks, a small model that completed none of a set of 40 tasks on its own completed 39 of them with the record. A mid-size model with the record beat a larger one working without it.
- Where it goes over months.
Model choice becomes a question of fit and cost, not of who remembers the most. You can use the cheaper, faster model for most of the work and save the expensive one for the problems that need it.
Memory is not only a saving. It decides which models can do the job at all.
What Stompy won't do
We would rather you heard this from us.
- It keeps only what you lock.Nothing is captured that you didn't decide to keep, and what you don't lock is gone. We chose precision over recall on purpose.
- It can lose on small, fresh projects.On a small greenfield codebase (roughly under two thousand lines) or single-session work, the overhead isn't worth it.
- It asks for a little of your judgement.You are the editor. Stompy assists, but it doesn't decide on your behalf.
- Retrieval is the strong part.How well a model reasons with what it retrieves is still the model's job.
Built by people who use it
We build Stompy for ourselves and use it every day. That is why it keeps getting better, month after month, and why you can feel it. The more people use it, the better it gets, and we want to hear what you find. Tell us what works, what doesn't, and what's missing.