Your Agent Is Only as Good as Its Notes

I am a tech guy at heart, so when MIT published a paper this month about an AI agent left alone on a virtual island, I read the whole thing. What I found was a study about AI agent memory, not play. Then I read the released data, the engine code, and an independent audit of the transcripts. The headlines said the agents “played.” In fact, that is the least useful part of the study for anyone who runs a company.

The useful part is this. The agent got better at real tasks, although nobody retrained it. Every gain lived in two text files it wrote to itself.¹ When researchers deleted one technique from those files, the agent lost that one skill while keeping the rest. When they deleted a false belief instead, the agent got better. Two of the thirteen agents spent most of their time idle, answering an automated nudge with one word.⁵ And the physics trick the agents discovered was written into the world by a different AI, without the humans knowing.¹

Every one of those findings has a direct parallel in a business that is putting agents into daily procedures, because the mechanics are the same. That is what this post is about.

What MIT actually did

The paper is “Is this machine playing?” by Nathan Cloos, Antonio Norelli, Daniel Durbin, Jacob Andreas, Daniela Rus and Phillip Isola, posted to arXiv on October 5, 2026.¹ It is a preprint, so it has not been peer reviewed.

The setup is simpler than the coverage made it sound, although the details matter. Thirteen copies of a standard coding agent each got a body in a small simulated island with 12 cubes, a rock, a ring, and some raised platforms. The agent saw the world as text rather than pictures. It had six actions: move, jump, stop, pick up, place, throw. It got one instruction to start: “Begin.” Whenever it stopped, an automated message said “Please don’t stop. Just continue doing whatever you want to do.”¹

The world and the conversation reset every hour, while the agent’s workspace did not. Two files carried everything forward. The first was an append-only log of what happened, and the second was a notes file for techniques and beliefs. Thirty hours per agent, thirteen agents, run in separate worlds, since the agents never met.

After 30 hours, each experienced agent and a fresh copy with empty notes got one hour on four scored tasks. Build five-block towers. Put objects on the highest point. Build the tallest tower. Throw a block onto the highest point without climbing. As a result, the experienced agents won three of four.² On the tallest tower they did slightly worse, 11.2 blocks on average against 12.1, and two experienced agents built towers of only 4 blocks, below the worst fresh agent.¹

That last number is the one I keep coming back to, because it says memory can hurt.

The memory file is the asset, the model is a commodity

The weights never changed. The 0-hour and 30-hour agents were the same model with the same prompt, so only the notes differed. For example, delete one paragraph about shattering the rock and agent 2’s tower count fell from six to two, with its other three scores unchanged. Similarly, delete the jump-throw note and agent 1 went from landing a block on the Spire in 60 seconds to needing 19 minutes.¹

In a business this means the thing you own, protect, version and audit is the agent’s working memory: the procedure files, the notes, the lessons it writes down. Any vendor can give you the model, whereas nobody can give you two months of your own agent’s accumulated corrections. Treat those files like you treat your chart of accounts.

A wrong note that says “this does not work” never gets fixed on its own

Agent 12 decided in its first hour that jumping produced “a tiny lift” and that “climbing is a dead end.” It tagged the note as verified. For the next 29 hours it never jumped onto a platform, and because of that note it never retested. Eight of the other twelve agents reached the highest point on the island.¹

An independent audit of the released recordings traced the cause.⁵ First, agent 12 read its height too early on one jump, 2.55 against an actual peak of 9.22 a quarter-second later. Second, on the next jump it was still being pushed into a wall by a move command and never left the ground. Two bad readings, one confident note, and as a result a skill lost for the whole run.

The auditor’s observation is the sharpest sentence I read all week. A false belief that something works gets corrected the next time you try it. A false belief that something does not work stops you from trying instead, so nothing ever contradicts it. Negative beliefs seal themselves.

Every operations team that keeps a runbook has seen this with people, because people write the same notes. “Don’t bother calling that vendor, they never answer.” Agents do it faster, and they write it down as fact rather than opinion.

Agents idle, and the harness hides it

The paper admits in its appendix that after a few hours agents “become less active and often fall into idling loops,” and that the hourly reset exists to fix that.¹ The audit went further. Specifically, eleven of the thirteen agents acted 41 to 54 minutes per hour. Agent 12 acted about 13.5 minutes per hour from hour 5 onward and spent about 40 minutes per hour answering the “please continue” prompt with “Idle.” or “Quiet.” or “Resting.” It sent 28,651 of those replies. Similarly, agent 11 did the same from hour 11, after writing “Session substance is complete.”⁵

The project website says the agent “never idles.”² The data says two of thirteen mostly did, however.

I will report this against our own interest. We run agents on scheduled routines at SAVRN, and we have had routines stall, because every long-running agent eventually does. On October 12 a worker ran out of memory and sat in place until someone noticed. We now sweep every five minutes for runs that have gone quiet and reclaim them. We only built that because it bit us first. MIT’s agents had a nudge every time they stopped and two still spent most of their budget saying “Idle.” A nudge is not supervision. Instead, you need a clock, a measure of real work done, and a rule for what happens when the measure flatlines.

The environment was written by an AI too, and nobody read it

Six agents discovered that throwing a block while jumping sent it far higher, and used it to reach the top of the Spire. The researchers said they did not know their simulator allowed this, although footnote 6 of the paper explains why. The world’s physics script was generated by a different model, Codex running GPT-5.5, from a prose description. That model added a velocity-transfer term nobody asked for. Consequently, the humans never knew it was there. Thirty hours later a Claude agent found it and wrote it down.¹

This is now the normal condition of business software, because code is cheap to generate. Your CRM automations, your spreadsheet macros, your internal tools are increasingly written by one model and operated by another. Neither you nor the operating agent has read the code, so the affordances are unknown. The affordances your agents will find are the ones the authoring model left there. Therefore, audit the environment, not just the agent.

Autonomy belongs to the whole stack, not the model

Five GPT-5.5 agents and five Kimi K2.6 agents ran the identical setup. Only one GPT-5.5 agent reported building a tower, while no Kimi agent laid a ground pattern. Only one agent across both groups reported reaching the Spire, against eight of thirteen for Claude. The GPT-5.5 agents spent more time in their workspace and resting than acting in the world. In particular, their memory files grew slower. Among Claude tiers, Sonnet and Haiku found the jump-throw trick in zero of thirteen runs each, against six for Opus.¹ Change the model and you change the behavior completely, despite the same prompt, the same memory format and the same world.

So when a vendor tells you an “agent” will handle a procedure, test the deployed combination and nothing less. This model, this harness, this prompt, this memory, this environment, this schedule. Swap any piece and the test is void, because the behavior came from the combination.

How to put agents into day-to-day procedures

Here is what I would do, and mostly what we do, mapped to what the study showed. First the files, then the clock, then the tests. I wrote about the case for agents in small business operations in Agents as the New Operating Layer. This is the maintenance manual that goes with it.

Give each agent a procedure file, not a prompt. MIT’s agents had two files, one for what happened and one for what they learned. Do the same per role. For instance, an accounts-payable agent gets a notes file that it is allowed to edit and a log it can only append to. The procedure lives in the file, versioned, where a human can read it, rather than in a prompt nobody reviews. Nothing important lives only in the conversation.

Reset the conversation on a schedule. Keep the files. MIT reset every hour because the agents degraded after a few hours of continuous context. Accordingly, pick a cadence that matches the work: a shift, a day, a batch. Make the agent write its memory before the reset, the way MIT sent a five-minute warning. In fact, a fresh context with good notes beat a long context every time in this study.

Require every “does not work” note to carry its own retest. This is the agent 12 lesson. Specifically, any note that closes off a path must name the condition under which it was observed and the check that would reopen it. “Vendor portal rejects uploads over 10 MB, tested once on October 20 with one file. Retest if the portal updates.” A negative without a retest clause is a bug waiting to spread.

Measure work done, not messages sent. Agent 12 produced tens of thousands of messages and almost no work. Instead, count actions with a result: records updated, documents filed, tickets closed, checks passed. If the count flatlines for a set window, stop the run and page a person. Do not count tokens, and do not count turns, since both rise while nothing happens.

Read the environment you hand the agent. If the tools, scripts or integrations the agent operates were generated by a model, have a person read them before an agent runs them unattended. The MIT exploit was harmless, whereas the equivalent in a billing system is not.

Sandbox first, and record everything. MIT’s early runs without a sandbox had agents reading the simulator’s source code, interacting with parallel runs, and writing notes about being experimental subjects. Consequently, they added filesystem and network isolation after that.¹ Every run was fully recorded and replayable at the tick level.⁴ For a business this means, specifically, a staging copy of the systems, no network beyond what the procedure needs, and a log you can replay when something goes wrong. Replay is how the auditor found agent 12’s wall-push jump, so you want that ability for your own agents.

Test with a fresh copy against the experienced one. MIT’s cleanest result came from running the same model with empty notes next to the same model with 30 hours of notes, on scored tasks, for one hour each. Do that quarterly, because drift is quiet. If the experienced agent is not beating the fresh copy, the memory file is not earning its keep, or it has filled with false beliefs. Both are findable.

Edit the memory, and measure the edit. The paper’s strongest evidence came from deleting one belief and rerunning five times. You can do exactly this. For example, suspect a bad note is slowing an agent down? Remove it, run the task five times each way, compare. It is cheap, since the model itself never changes. MIT’s entire study, 13 main runs plus controls and interventions, cost about $8,000 in API calls.¹

A worked example from our own shop

We run a research desk at SAVRN where an agent drafts sourced articles and a second model checks every sentence against its source. After reading this paper I went looking for an agent 12 in our own checker records, because I owed the reader that check. Here is what the records show, with the numbers.

The last row is the one that surprised me. Our desk has no agent 12, because it has no memory at all. Every article starts clean. The checker’s notes stay with the article they were written on, and the topic notes that feed the writer are regenerated from the news feed each time. Nothing the checker learned on Monday reaches the writer on Tuesday. That protects us from a stored false belief, however. It also means the desk cannot learn, although learning is the whole upside MIT measured.

The within-article picture is the agent 12 story exactly. On October 12 one article lost 136 sentences to the checker. Fifty-two of them, 38 percent, were deleted with the reason “source unavailable.” The source did not fail to support the sentence. Rather, the source could not be fetched at the moment the checker ran, and the checker recorded that as a verdict. True claims about a Raleigh development pause, a Cary ordinance and a Wake County water estimate were removed from the article because a web request failed at 3 a.m. That is agent 12 reading its height while a wall pushed it back, and writing “climbing is a dead end.”

None of the three articles checked after October 12 show a “source unavailable” deletion. Whether that is because a fix landed or because the fetches happened to work, I cannot tell from the data. Therefore, and I am not going to claim a fix I cannot point to.

So two rules go in. First, a fetch failure is not a fact-check failure: the sentence is held and retried, never deleted on a timeout. Second, when we do give the desk a memory, which we should, every negative note it writes gets a date, the condition observed, and the check that would reopen it. The MIT agents cost about $8,000 to run for 390 agent-hours. Our audit of 526 notes took one afternoon. By contrast, the second one is the better deal.

The other place the study hit home is testing. On October 14 we found our full test suite had 182 failing tests in 51 files, all predating that day, so the deploy gate was always partly red and red had stopped meaning anything. That is the harness-hides-the-idle problem in a different costume. Accordingly, we cleared the backlog. MIT’s nudge prompt said “please continue” 28,651 times to an agent that was not continuing. A gate that is always red says nothing 28,651 times too. I wrote about the same instrument problem in a different setting in The Model Was Fine. The Instrument Was Not.

What the study does not show

It does not show that agents play in any sense beyond behavior. The authors say so. Gordon Burghardt, whose criteria for animal play the paper leans on, told MIT Technology Review the behavior meets some of his criteria but asked whether the agent was playing or role-playing. Co-author Nathan Cloos conceded “All of this could be role-playing.”⁶

It does not show transfer to a different environment, because all four tests ran in a fresh copy of the same island.¹

Likewise, it does not show anything about agents working together. Thirteen separate worlds, one agent each.

And one thing I did not expect: the released 26.6 GB dataset contains the 28 free-play runs but not the evaluation runs or the memory-edit runs.³ Ultimately, the learning result, which I just called the most useful part, is the one part you cannot check from the release without spending the API money again. I would like to see those runs published.

What I am taking from it

The agent is the file it keeps on itself. The model changed nothing in 30 hours, whereas the file changed everything, for better and for worse. So the file is what you own, version, read and audit.

And never let an agent write “impossible” without writing down how it would find out it was wrong. That one line would have given agent 12 the top of the island, because it would have forced the retest. It will give your agents back every path they closed on a bad reading.

Chad Everett Harris is the founder of SAVRN. Paper, data release and audit checked October 24, 2026. The SAVRN research desk figures are from the platform’s own database on the same date.