Every AI agent session begins with amnesia.
The model does not remember yesterday's investigation, the decision you reached at midnight, or the three hosts it spent an hour mapping last Tuesday. It starts from whatever you put in front of it, and if you put nothing, it rediscovers your environment from scratch, often wrongly, and occasionally with great confidence. For a one-off question that is fine. For an engineering practice that runs dozens of agent sessions a week across real servers, clients, and commitments, it is expensive and unsafe. You are paying, in tokens and in time, to relearn the same facts, and you are betting that the relearning comes out the same each time.
A wiki that the agents maintain
Our answer is an LLM-maintained wiki: a folder of plain Markdown pages with structured front matter, one per entity, concept, decision, or source, that the agents themselves read at the start of a session and write to at the end. The pattern is derived from Andrej Karpathy's "LLM wiki" idea. We added the read hierarchy, the validation scripts, and the work ledger described below.
The first design decision was the read path. A naive agent, told "here is the wiki," crawls it, floods its context with pages it does not need, and runs out of room before the actual work starts. So reads are graduated. Every wiki has a hot cache: about five hundred words of the most recent, most load-bearing facts, rewritten rather than appended, loaded automatically when a session opens. If the hot cache is not enough, the agent reads the master index. If that is not enough, a domain index. Only then does it open individual pages. Most sessions never get past step two.
The hot cache has a word budget enforced by a script, and the script matters. After a major change to how we describe the firm, the cache crept to 524 words. A linter caught it, and the agent rewrote it to 444. Nobody noticed the overrun by eye. The tool did.
A rule in prose is a hope. A script is a guarantee.
An earlier wiki of ours, for a client engagement, had a required convention: every investigation had to open a trace record in a particular way. The rule was written clearly, in a file the agent loaded every session. Within three weeks, about half of new traces skipped it. Not because the model was defiant. Because a rule in a prompt is advisory, and under pressure, advisory rules lose to whatever the model is currently focused on.
So we moved every convention we could out of prose and into deterministic tooling. A linter that checks front matter, dead links, orphan pages, and index drift. A script that enforces the hot-cache budget. A pre-commit gate that blocks a commit which violates the schema. The agent still exercises judgement about what to write; it no longer gets to decide whether the page has a title field. Anything a script can check, a script checks, because a script runs every time and a sentence in a document runs only when the model happens to remember it.
Our audit found roughly one in seven findings was wrong
When we audited that same client-engagement wiki, roughly one in seven substantive findings turned out to be wrong. Most of the corrections came from me, the human, noticing that something did not match reality. The agent's own self-checks caught almost none of them.
That number changed how we write. Now a claim does not become a fact in the wiki until it passes a gate appropriate to its kind. A claim about a document requires that the document was actually opened and read; its filename is not evidence. A claim that something does not exist has to name the search that was run and the alternative explanation that was considered. A number has to carry its source. A root-cause claim stays marked provisional until something independent corroborates it. And any assumption the agent is making has to be flagged in a dedicated field in the page's front matter, rather than buried in prose where it reads like a fact. That field lets the linter list every unresolved assumption across the wiki without anyone rereading the pages.
What drift looks like
The linter found an index entry pointing to a page that had never existed; an agent had planned to write it and recorded the plan as if it were done. It found cross-wiki links missing a path segment, and a link to a page that lived in a different wiki entirely. The linter also had a bug of its own: it excluded its reports folder from valid link targets, so every report flagged its own breadcrumb as a dead link. We caught that one by reading the reports.
After we changed how the firm describes itself, the linter swept every page for the old framing and flagged each one. The agent corrected them all, with one deliberate exception: the append-only activity log was left alone, because rewriting past entries to match the present position would destroy the record of when the position changed.
Remembering what you owe
Alongside the wiki, every substantial piece of agent work keeps a requirements ledger: a file of what was asked, what was done, what was deferred and by whose decision, and what was handed to someone else. It survives the session. A guard stops an agent from ending its turn with open items it has not accounted for. Items can be closed only with evidence, deferred only with the operator's approval, and moved only to a named owner, never silently dropped.
A diagnostic session once correctly identified a durable fix for a recurring failure, recommended it, closed itself out cleanly, and archived the ledger. The fix was never tracked. Eight days later the next power outage reproduced the identical failure and a service stayed down for most of a day. The diagnosis had been perfect; the memory of what to do about it had evaporated with the session. Nothing deferred in a closing note may now be archived until it has become an owed item with an owner. Archiving must never be the mechanism by which work stops being tracked.
Shared writes, wiki conventions, and hosting
Several agents writing to one wiki will eventually collide. Two of ours once tried to commit at the same time through a shared git index and corrupted each other's staging. All wiki commits now go through a helper that only accepts explicit file paths and refuses bulk staging, and every agent re-reads the shared files immediately before writing them, not at the start of a long task.
The tooling is opinionated about folder names, status vocabularies, and link syntax, and it refuses to run against a wiki that does not carry an explicit marker saying it follows those conventions. An agent using the wrong conventions can create pages in nonexistent folders with unresolvable links and report success. The marker check makes the tool refuse a wiki it does not understand.
The wikis stay on infrastructure we control. A push of wiki content to a third-party host was attempted once and reversed. The content is the firm's accumulated judgement about its own environment and its clients. It does not belong anywhere we do not own the disk.
When persistent memory is worth maintaining
If agents repeatedly work in the same business environment, give them a cheap first read, a structured store they maintain, verification gates before a claim is promoted to fact, a linter that runs on a schedule rather than when someone remembers, and a ledger of unfinished work that outlives the session that created it.
We shelved a vector-search memory layer because we could not show it beat the graduated read path on the tasks we actually run. We will reconsider it if a benchmark shows an improvement.
If your agents keep repeating investigations or losing unfinished work between sessions, talk with us.