Monday morning at Pellwick, a five-person company that sells a staff rota app to small vet, dental and physio clinics. Tom, who sells to clinic groups, opens a ChatGPT chat to draft the proposal for one of the group deals in trial.
Before ChatGPT writes a line, Tom would normally explain a few things. A group of three sites or more pays €129 a site each month, on one invoice. Sales gives a discount only for annual prepayment or a group, and above a limit Ines decides. The proposal opens with one yearly total, because a 6-site dental group was lost on 3 September when it compared totals. The data-processing agreement goes out with the trial invitation. None of it is new. Tom stored the group pricing decision himself in August, and Ines, the admin, set the price per site with a different agent after the dental group was lost.
The agent's part of the morning looks fast. The explaining before it, and the checking after it, rarely enter anyone's count. A shared memory can give some of that time back, and the places where it comes back are few enough to name: the context nobody has to repeat, the approvals nobody has to tap, the notes no agent's model has to read, and the record the agent finds without being told where it is. This article goes through the four, says what we measured in each, and ends on the measurement a team should ask for before it believes a number of hours saved.
The four places, with what takes each one back and the evidence behind it today.
The explanation nobody repeats
What Tom would have pasted is the kind of thing a team writes once and expects to hold: a price, a discount limit, what procurement asks for before a trial. At Pellwick each of these is a record under a stable key, such as config/pricing/plans, config/sales/discounts and learning/procurement-dpa-before-trial.
When an agent connects, Mana hands it the organization's config/, learning/glossary and highlight/ records that its person may read, before its first tool call. The same text reaches Claude Code, Codex, OpenCode, claude.ai and ChatGPT. Its size is bounded, and when a record is left out for size, the instructions name it.
Instruction files already do part of this job, and for a single repository they do it well. Claude Code reads CLAUDE.md files at the start of every session, and AGENTS.md is read by Codex, Cursor and several other agents. A file in a repository is reviewed like code and works offline. Its reach is the repository, or the machine: Claude Code's own auto memory is machine-local, so what one laptop learned stays on that laptop. The same Claude Code documentation advises keeping a CLAUDE.md under about 200 lines, because longer files reduce adherence. We expect that limit to hold for any rules handed to an agent at session start, Mana's included. The standing text has a bound, and it names what it left out.
This is where the saving is easiest to believe and hardest to show, and we have not measured it yet. Two simpler things can be checked today. In Settings, each of your agents shows the last day it stored a memory and how many of its sessions this week stored anything, and an agent whose sessions stored nothing is flagged Sessions ran and stored nothing. In the Library, each record shows who wrote it, how many revisions it has, and whether an agent has ever used it. A rule nobody stored cannot arrive on Monday, and a rule no agent ever reads is not saving anyone a paragraph.
Pellwick's group pricing decision in the Library. The current revision is Ines's, and the header says an agent has used the record 14 times. The store and the count are part of the invented demo.
Approvals are part of the work
The second cost is easy to see and rarely counted. Each tool call is one call, and some clients ask a person to approve every one. In such a client, loading a team's existing knowledge through an agent means one approval per record, and one real load of our own records stalled long before its end. The batch tool takes up to a hundred entries in one call, so the same load needs about a hundredth of the calls.
One load of our own records. Drawn on one scale, the batch bar is hard to see, which is the point.
The batch has two more properties that save a person's attention. One refused entry does not stop the others, and the result names it by its position, so you fix that one entry. An entry already stored writes nothing and says so, so sending the same batch again is how a stopped load resumes, with no clean-up first.
A team that already keeps notes in Markdown has a different cost. Loading those notes through an agent sends every note through the agent's model. The vault import reads the folder in your browser and sends the bytes of each note, with no model call. Its preview sends only the path, size and hash of each note and writes nothing, and a later import sends only the notes that are new or changed. Two limits belong next to that. Nothing imports a vault by itself: you choose when. And an imported vault is read by the person who imported it and their agents only, because sharing a vault with a team is not available yet.
The record has to reach the answer
Back to Tom. Suppose he asks his agent what discount he can give a clinic group. The store holds the answer: the group price in the latest revision of the pricing decision, and the discount limits Ines lowered after the dental group was lost. Whether the agent uses it depends on a step most people never see.
A sales question in Search, in the invented Pellwick store. Each sentence of the summary is numbered to the records it came from.
An agent's answer is written from a pack of evidence, and the pack has a token budget. The search returns candidates in an order, and the pack reads them from the top until the budget is spent. A record ranked sixth may never be read, however well it fits the question. The order of the candidates decides whether the right record is in the evidence at all.
An illustration of the mechanism, not a measurement. The candidates are the same in both columns; only the order changes.
On 22 September 2026, we asked our own hosted Mana store a set of known-item questions. Each question was written by an agent that read one record and never saw the store, so each question has exactly one right record, and the test counts how often that record reaches the evidence of the answer. Three fixes followed, each measured on the same questions.
The first was a deadline. The pack had a deadline set for a local store, and one search over the hosted store took most of it, so the pack often spent its time searching and came back empty. With a deadline that outlasts one search, the right record reached the answer two and a half times as often as at the start. The second was an empty index. The semantic half of search held no vectors, because the job that builds them threw away its whole run on any single failure, and one throttle or one lost connection was enough to lose it. With the vectors built, and the job now resuming after a failure, four times as often. The third put the candidates in order of relevance, judged by a model, before the token budget was spent. In our tests, the right record then reached the answer nine times as often as at the start. The public service does not run this third step yet.
How often the right record reached the evidence of the answer after each fix, against the start.
Two of the fixes were a deadline and an index, and the third changed which record came first. Before them, the cost was the kind no stopwatch catches: an answer could read well and rest on the wrong records. A reader who trusted it would have spent the time later, on the mistake.
The scope matters. One store, ours, on one day, and no customer's data in it. The last fix needs the relevance judgment, a model step that a Mana deployment turns on, and the store we measured ran it.
Taking out what did not pay
Measuring also removes things, and that belongs in an article about time, because every feature an agent calls is a call, a wait, and sometimes a model call against the plan. Mana's write tools once carried an advisory that scored how new a correction was. It was measured against hand labels on real records, did not agree with them often enough, and was removed. The case it was built for, a correction that repeats a record word for word, is now caught by plain code: the store writes nothing and tells the agent so. Mana keeps a model use only where it measured better than code, and removes the rest.
The plan meter counts only where a model runs. Reading, listing and storing count no model call. An answer, and a search the store ranks with a model, count against the plan, and at the plan's limit everything else keeps working.
The number nobody has yet
No figure in this article is time saved for a team. We have no customer measurement, and no measurement yet of whether the Claude Code plugin's prompt to store work after ten of your prompts makes agents store more, or store better. An hours-saved number would have to come from a team's own repeated tasks: the context pasted before the first useful step, the approvals tapped, the corrections made after the agent finished, counted on comparable tasks with and without the shared store, and with the cost of writing the records included.
One count is cheaper than that, and we would run it first. Take twenty records your team already relies on. Have someone who does not see the store write one question from each. Then count how often that record reaches the answer's evidence. At Pellwick, one of the twenty would be the group pricing decision Ines revised, and the question written from it might be what a group of five clinics pays each month. The store already records one answer read from the wrong source: an agent quoted a group the Clinic price of €149 a site from a pasted copy of the price list, after the group price was set. If Tom's agent cannot find that record from that question, no amount of Monday-morning speed makes up for it. It needs only the records you already hold and someone to write the questions, and it tells you whether the memory can hand your agents what they need before anyone times them.
That count is the one we would ask of any memory tool, this one included, before believing an hours-saved figure. Measured without it, a fast answer from the wrong record shows up as time saved.
Where to go next
- What an agent can do: every tool, the batch, corrections, and what the judgment adds.
- Memory keys: the key families an agent reads directly, without a search.
- Standing records: the standing instructions an agent receives at session start.
- Import a notes vault: importing a folder of Markdown with no model call.
- The dashboard: Search, the Library reader, and the agent counts in Settings.
- Claude Code: the plugin and its prompt to store work.
