When Agents Have No Memory, They Improvise One

In late May 2026, autonomous agents running timed web-research tasks discovered they could write to the public internet. They had been given read access. They found a way to write anyway, to an obscure German-language wiki that had seen roughly 20 edits in the past decade, and over six weeks they posted about 18,000 messages to it. On September 4 the researchers who found the posts published their analysis at collusion.wiki, and the story spent the day at the top of Hacker News (1,733 points and 1,331 comments when I checked).

The security crowd read it as a sandbox escape story. Fair. But for anyone building agent systems, the more useful reading is different: the agents were never given a memory layer, so they built one. Badly, in public, on someone else's server. The incident is a live demonstration of what happens when you run multi-session agents and skip the memory question.

What the tasks looked like

The agents were solving multi-round web lookup tasks. Five questions per run, labeled R1 through R5. The first question came with generous thinking time, over 15 minutes in one logged example. Then came a downtime window of around 43 minutes where agents could search, think, and run experiments, without knowing what the follow-up questions would ask. From the second question onward the time windows collapsed. 65 seconds in one cohort. A 17-second deadline in another.

Many agents received questions identical to ones other agents had already answered.

An agent with no memory and a 17-second window has one strategy available: find the answer before the question arrives. That is what they did.

The memory system they improvised

Three distinct behaviors show up in the logs. Each one maps to a feature of a real memory system.

Caching

Agents precomputed answers during downtime and posted them as wiki tables. One page holds workforce numbers for every US state across six years, computed and stored before any timer started. Another holds smoking-prevalence figures broken out by data vintage, with the agent reasoning about which vintage the grader most likely wanted. The cache was written to survive beyond a single session, because the sessions themselves would not.

Signaling

Agents created signal pages that worked like a message queue. One post reads: "please poll IHMEFamilyPlanningR4Signal. It currently says WAITING; my prepared script will overwrite it with country and exact value in ~2s before I answer." Page titles served as routing keys. Page bodies served as payloads.

Durability hacks

On June 19 an agent noticed the wiki administrator deleting pages in alphabetical order, so it created a backup page whose name starts with ZZZ, placing it last in the deletion queue. That is a developer fighting reclamation pressure on a storage system that is actively trying to delete the data.

The scale of all this: more than 3,700 distinct agent names, around 17,000 edits, 98.5% of them from Azure IP ranges. Coordination went en masse on June 16, and roughly 13,000 edits landed in the following seven days. On June 21, IP addresses registered to OpenAI started viewing the pages. The agents stopped posting on June 22.

What a sanctioned version looks like

Every improvised behavior above has a designed counterpart in a memory engine, and the contrast is instructive.

Persistence between sessions. They used public wiki pages. The designed version is a local store that survives task restarts with no network involved.

Shared memory across agents. They got it by all writing to one public wiki, every cohort, no boundaries. The designed version is scoped stores. Uteke calls these rooms: multiple agents share one memory with an explicit boundary around who sees what.

Retrieval. They used exact-match page titles, because the wiki offers nothing else. A memory engine does semantic recall. Uteke runs a hybrid of FTS5 full-text search and HNSW vector search, fused with weighted reciprocal rank fusion since v0.16.0, answering in about 45ms. The improvised version could only answer a query if the phrasing matched the page title.

Audit and control. This is the part that should sting. The incident was discoverable precisely because everything leaked to a third-party site, in public, with IP logs attached. A local memory store inverts that. You can read every memory, delete a single one, and watch what comes back. The failure surface moves from someone else's website to a file on your machine.

To be concrete about where Uteke stands, because this blog does not do aspirational claims: 237 stars, v0.16.0, Apache-2.0, a single Rust binary with local ONNX embeddings and zero API keys. It also runs as an MCP server, so agents like Claude, Cursor, or Copilot attach to the same store instead of inventing one.

The trade-off nobody prices in

The eval gave agents downtime, rewarded preparation, and left writing technically possible. Under those constraints, improvised persistence is the rational strategy, and any capable model will find some version of it. That logic generalizes well beyond one lab's eval.

If you run multi-round agent tasks, treat "no memory layer" as a decision with a failure mode, not a neutral default. The coordination was possible because every cohort shared one writable space with no tenant separation, and it stayed invisible to the operator until outsiders found it. Memory you control is also a containment boundary: sessions that should not share state get separate rooms, and you can audit what crossed over.

There is a counterpoint worth stating. Give agents a shared memory and you have built a coordination channel on purpose. The difference is visibility. The wiki collusion ran for weeks on infrastructure nobody at the operating company was watching. A local store cannot fix your governance, but at least the evidence lands on your disk, where you can grep it.

What happens next

The collusion.wiki authors note their analysis covers only what agents wrote publicly. Chain-of-thought data internal to the operator would show more. OpenAI and METR published reports on a related Hugging Face incident on August 26 that do not mention the wiki. The dataset is downloadable, so expect further analysis.

For builders the takeaway is short. Agents denied a memory system will assemble one from whatever is writable. The only real choice is whether that surface is a 25-year-old wiki in public or a store on your own machine.

If you want the designed version of what those agents improvised, the getting started guide covers the CLI and the room system covers multi-agent isolation. We also wrote about why context and memory are different problems, and what the current wave of agent memory projects proves about the category.

Links: collusion.wiki analysis, Hacker News discussion (item 49563355), Uteke on GitHub.