Persistent Memory Now Scales to a Large Store
August 19, 2026 · InfraScout Team
Persistent memory is how the AI carries an engagement across conversations — it writes down what it learns about your environment and reads it back at the start of the next chat, rather than rediscovering the same domain controller five times.
That works well on a small store. On a large one it did not scale, and this release fixes both halves of why.
A map, not a size-capped list
The AI used to receive a flat alphabetical index of the store at the start of every conversation, truncated to fit a size budget. Which means that past a certain store size, entries simply fell off the end of the index — and on a store of a couple of hundred entries, most of the per-host and per-user entries were below the cut.
It now receives a map: the anchor entries, per-namespace coverage naming the hosts and users each namespace actually covers, the recently-updated entries, and the tags in use.
The map represents the whole store rather than a prefix of it, and it does so in roughly a fifth of the space. Two things follow: no entry is invisible to the AI regardless of how large your store grows, and every conversation carries noticeably less overhead before its first message.
Search that answers ordinary phrasing
Search previously required every word in a query to match. So a natural phrase — "rotating admin account passwords" — returned an empty result even when the store held exactly that. An empty result reads to the AI not as "try different wording" but as "nothing is stored about this", and it proceeds on that basis.
Queries are now normalized: filler words and punctuation are dropped, and single-character fragments ignored. Where few entries match every term, the closest partial matches come back too — explicitly marked as partial, naming which terms actually matched, so the AI knows it is looking at an approximation rather than a direct hit.
Results also carry their last-updated time, so the AI can prefer a current entry over a stale sibling covering the same subject.
Fewer near-duplicate entries
The tooling around the store was tightened at the same time. Listings page rather than truncate, reading a folder path pages the same way, and search results carry enough detail to triage without opening each entry.
The change with the most effect on a long engagement is the smallest. When the AI is about to create a new entry, it is first shown the handful of existing entries closest to what it is about to write. Combined with an instruction to search before creating and to update in place where an entry already exists, that is what keeps a two-week assessment from accumulating a dozen slightly different entries about the same server.
Measured, not assumed
We evaluated the map against the previous index across ten realistic recall scenarios, three runs each:
| Map | Previous index | |
|---|---|---|
| Scenarios resolved correctly | 29 / 30 | 27 / 30 |
| Average input tokens | 32,021 | 44,077 |
About 27% fewer input tokens for the same answers, consistently, across every scenario.
The honest reading of that table is that the map is mostly a cost improvement rather than a capability one — the search tool could already reach an entry whether or not the index had mentioned it, which is why the outcome columns are close. What changes is that you are no longer paying a large overhead for an incomplete picture. Two scenarios did improve outright: filtering by tag went from one correct run in three to three in three, and searching a topic across the environment from two to three.
Nothing to configure, and nothing to migrate. See Memory for the inspector and the filters.
Questions or feedback? Reach us at info@infrascout.cloud.