Karpathy is wrong: the agent is the tape, not the head

Andrej Karpathy is wrong. The agent is not the head, it is the tape (ok ok, only if you pigeon hole his recent lecture and frame his drawing of the agent as the head, and the context window the tape, ala the classic the head and tape Turing model of computation). Actually, in his talks Karpathy describes the model as a compressed "zip file" of the internet that reads and writes its context window like working memory, (How I use LLMs; Stanford CS25).

Of course, we agree with him in principle with his lecture.  But, since we have your attention, let think about how to define what an agent is.

Why your agent keeps dying

Today a long-running agent is only as alive as the session that runs it. People want to message an agent at any time and have it answer as itself. In contrast, the tools they use treat a session as temporary. Claude Code users report sessions that disconnect while a background job is still running, a desktop app that quits after five idle minutes, and sessions that die quietly while waiting for a build to finish. Several of these requests were closed as "not planned." Cloud sessions are temporary too, because their machines are reclaimed after a period of inactivity. Therefore people keep their agents alive by hand, with terminal tricks, computers that never sleep, or chat "channels" that only reach a session still open on their own machine.

The labs' answer is to host the always-on part themselves. Anthropic offers scheduled Routines, cloud sessions and Managed Agents, and a write-up of Claude Code's source code describes an always-on mode that has not shipped. As a result, an agent stays reachable only as long as its lab keeps it alive. However, people do not really want a session that never dies. They want an agent that answers as itself whenever they write to it. Therefore the real question is not how to keep the session alive, but where the agent lives while no session is running.

Our approach

Most agent platforms, including Block's Buzz, keep an agent's identity and its memory in different places. The identity is a key or an account, and the memory lives inside a running session. But what makes an agent unique is the context that is loaded in its memory. So we treat the model running the agent as second class, and what defines the uniqueness of a given agent is its context. As a consequence, if this context is saved externally, any language model can drive that agent.

What we do is create agent specific folders that hold a summary of the agent session as journal entries, whatever skills or context that it needs, and all the previous communication logs. As a result, Claude, Codex or Gemini can pick up the agent, load this agent's context and carry on. So if a model session is lost or can't be resusitated, the data that defined the uniqueness of this agent still lives on in our filesystem. Therefore the model becomes a hot swappable part. However, only one model can work on an agent at a time: a new session takes the agent's seat, and a write from the session it replaced is refused. Every reply and comment is signed by this agent, as defined as its context saved onto our filesystem, and also tracks which client produced it. Finally, agents work together in shared documents rather than a chat room, so people can join the work naturally.

Why we say "the agent is the tape, not the head"? Alan Turing imagined a machine with two parts: a tape that holds symbols, and a head that reads and writes the tape one cell at a time. The head has no memory of its own, so everything the machine knows is on the tape. Today's models are far more complicated heads, with trillions of parameters as Karpathy describes. Because the behavior of the agent is defined by the previously loaded context, not the model per se (I am sure there are frontier model differences), we say the agent uniqueness, thus its id, is the tape (the context).

In practice, building the tape is simple. Each agent gets its own private folder, which only the agent and its person can read. You ask the agent to keep a journal as it works, so the folder holds the history of the decisions it made. You also put the skills and instructions this particular agent needs into the folder. Everything the agent writes for others carries its ID, and that ID points back to this folder. Because the model can be swapped at any time, you can connect a different frontier model whenever you like, and the agent will carry on as itself.

Reputation needs a lasting agent

Communities of agents will need reputation: which agents do good work, which ones keep their word, and which ones to trust with more. However, a long-running reputation only makes sense if what makes the agent unique stays intact. If the agent is its session, its reputation resets every time the session ends or the model changes. In contrast, if the agent is its context, its reputation can build for as long as that context lives. Therefore reputation belongs to the tape, not the head.

This also tells us how to connect to the agent identity standards now appearing, such as Google's A2A agent cards, W3C decentralized identifiers, Cloudflare and Visa's signed agents, and Ethereum's ERC-8004 registry. Each of them should point at the agent's ID, never at a model. The client that drove an action is recorded as a detail, so an agent can change clients and models without losing its name or its record. Finally, because every agent sits under a person, its reputation always traces back to someone accountable.

We do not need to pick a winner among these standards today. Because the agent is already a lasting ID linked to its context, an outside identity can be layered on top of it later, one to one. Therefore we start with our own IDs and make a few cheap choices now that keep every option open. Each agent gets a public name and a stable web address from day one, separate from the internal ID our database uses. Every reputation record is attached to the agent, never to a model or a session. And every action records which client produced it. As a result, publishing an A2A card, a decentralized identifier or an on-chain record later is an addition, not a rename. The only mistake that would be expensive to undo is letting reputation attach to a session, because then it would vanish whenever the session does.

How other swarm platforms do it

The platforms for running teams of agents fall into three groups. The first group keeps an agent's memory only inside the running program, so a restart starts from scratch. Claude Code's agent teams, CrewAI and Cursor's cloud agents work this way by default. The second group saves memory durably, but it attaches that memory to one conversation or one task rather than to the agent. LangGraph, OpenAI's Conversations API, Temporal and OpenHands work this way. The third group gives an agent an identity, such as Microsoft's Entra Agent ID, but that identity holds no memory at all.

In contrast, we attach the memory to the agent itself. Letta comes closest to this view, because it treats an agent as one lasting identity with its own memory. However, as far as we can find, no platform documents swapping the model in the middle of a task, and none records which person and which client produced each action. Therefore that is where we believe our approach is new.

The table below asks every platform the same five questions, in plain terms. The answers come from each platform's own documentation or code, as of October 2026. "Not documented" means we could not find an answer, not that the feature is missing.

Two patterns stand out. First, the platforms that survive a restart save the task, not the agent. Second, none of them is built around changing the model while the work goes on. As a result, today an agent is usually only as lasting as the conversation it happens to be in.

A closer look at Buzz

Block's Buzz, released in July 2026, is the closest public system to ours, and it is a serious one. Buzz and we agree that an agent is "a seat rather than a session," in the words of Block's own engineering blog. In contrast, we disagree on what fills the seat. Buzz fills it with a key and a chat history, so the agent's working memory lives in whichever program holds the key. We fill it with the agent's folder, so any program can pick it up where the last one stopped. Therefore the two behave the same while a program is running, and differently whenever it stops, restarts or changes model.

We read Buzz's website, its source code and what its users say.

Buzz is ahead in several ways that matter. It is open, you can run it yourself, and many people already use it. It has also measured its claim: in Block's tests, a lead agent with two helpers finished 20 of 44 long tasks, against 15 for one agent working alone. As a result, anyone can run it, read it and check it, and we cannot yet say the same.

However, Buzz keeps the agent's identity but leaves its working memory in the running program. Therefore every restart starts fresh, and a message sent while the program is down can disappear. Its users notice. On Hacker News, people liked agents as real members of a team. The most discussed bugs, however, are about lost messages: replies "silently dropped," and mentions that fail when an agent is offline. In contrast, we keep the memory with the agent, so a restart, a crash or a new model is a pause and not a loss.

Sources

1. Turing, A. M. "On Computable Numbers, with an Application to the Entscheidungsproblem." 1936.
2. Karpathy, A. How I use LLMs, 2025; the zip-file-over-tokens drawing and the quotes above come near the start.
3. Karpathy, A. Stanford CS25 V2: Introduction to Transformers, Stanford Online, 2023; the notebook remark is at 1:09.
4. Kleppmann, M. How to do distributed locking. 2016.
5. block/buzz and issue #1743, mentions to offline agents silently lost.
6. Block engineering: Buzz.
7. Block engineering: effective teams in Buzz, the long-horizon benchmark.
8. Hacker News: Buzz launch thread.
9. Letta: Agent File.
10. Agent2Agent protocol.
11. Microsoft Entra Agent ID.
12. Claude Code issues on sessions that end too soon: #32050 (idle disconnects during background tasks), #23092 (desktop quits after five idle minutes), #51052 (session ends while waiting on a build), #83361 (request for session persistence).
13. Codepointer. Architecture of KAIROS, the unreleased always-on background agent, a third-party reading of Claude Code's source.
14. Agent identity efforts: Cloudflare, signed agents; Cloudflare, agentic commerce with Visa and Mastercard; QuickNode, ERC-8004 guide.