← The Record
For CTOs, AI Engineers & Product Leaders

Files, Not Memories

Agents don't have memories. They have files on disk. Why that single design choice does most of the work.

You give an AI agent a complicated task. It works for ninety minutes. By minute forty-seven it's confused about a detail from minute twelve. By minute eighty it's confidently building on the wrong assumption. The output looks polished. It's broken, and it's been broken the whole time.

You scroll back through the conversation trying to find where it went wrong. Somewhere around minute twenty-one there's a sentence the agent wrote that wasn't quite right. You don't catch it. You don't have time to read ninety minutes of agent-written text; not having time to do the work is why you have an agent. You ship the output. Your customer notices before you do.

This is what happens when agents have memory.

Agents don't have memories. They have files on disk.

That rule is load-bearing in the org that runs SpeyAI. Every agent invocation is a discrete session. The handoff between agents is a file the next agent reads, not a conversation the next agent inherits. The rest of this paper is about why that single design choice does most of the work, and why almost every agent framework gets it backwards.

The usual grounding applies. SpeyAI runs its own company on the agent org it sells, which means every claim below comes from watching the files move, not from a whiteboard. The specs, the reviews, and the findings described here are the documents the company produced this week.

Memory is a feature for chat. It's a bug for production.

The pitch most AI products are built on is that the agent remembers. The agent gets to know you. The agent learns from the conversation. Every feature roadmap has "memory" on it as a positive.

For chat, this is fine. A user is in a conversation, the conversation has a thread, the thread benefits from continuity. The user can tell when the agent is wrong because the user is reading every message as it arrives.

For production work, memory is how things go wrong silently. The agent is doing work the user isn't reading in real time. The agent's earlier output is part of the agent's later input. When the agent makes a mistake in turn one, the mistake becomes a fact in turn two. By turn fifteen, the agent is reasoning from a foundation that was wrong from the start, with full confidence, because the wrong thing is sitting in the context as evidence.

The research literature documented the mechanism before the frameworks shipped it as a feature. Generated errors propagate: a model's hallucinated output, fed back as input, becomes the ground truth for everything generated after it (Ji et al., 2023, ACM Computing Surveys). The longer the conversation, the more confident the agent gets, and the more wrong it gets. This is the central failure mode of agent loops in production. It looks like the agent is thinking. It's actually compounding.

The fix isn't a better model. A better model compounds errors more fluently. The fix is to not let the agent accumulate the kind of context that compounds. Each invocation is fresh. The previous agent's output is an input artifact, not a shared brain.

How lawyers do it

The closest analogy in the existing world is a court case.

A court case has filings. Every filing is a document. The plaintiff files a complaint. The defendant files an answer. Each side files briefs. None of these parties share a brain. None of them operate from a shared memory of the case. They operate from documents. The documents are the case.

The Federal Rules of Civil Procedure spell the shape out. Rule 8 defines what a filing must state to make a claim. Rule 12 defines the responses the other side files against it (Federal Rules of Civil Procedure, Rules 8 and 12). Complaint, answer, motion: every step in the proceeding is a discrete document, produced by one party, read by an adversary.

When the defendant reads the plaintiff's complaint, the defendant reads the document. They don't load the plaintiff's reasoning into their head. They read what's written and respond to what's written. The plaintiff might have made an error in the complaint. If the defendant catches it, the error becomes a point in the response. It doesn't propagate. It gets caught, because the next reader has different incentives and no obligation to interpret the document charitably.

This is what makes the legal system durable across centuries of imperfect participants. Every step produces an artifact. Every subsequent step reads the artifact. Errors get exposed because someone who benefits from finding them is doing the reading.

The agent org runs on the same shape. Each agent task produces an artifact. The next agent reads the artifact. The handoff is the document, not a shared context. A reviewer agent writes a finding. The finding is a file. The implementer agent reads the file. If the finding is wrong, the implementer catches it, because the implementer has no investment in the finding being right.

Hallucinations become artifacts, not contexts.

That's the line to keep. A hallucination written down is something the next agent can inspect, dispute, and reject. A hallucination sitting in shared context becomes the foundation for everything the next agent does.

What's in the artifact

Each kind of work produces a specific kind of file, and the names of the files matter.

A spec gets written to a specs folder. The file name ties it to the work it describes. The file has a structured shape: what the work is, what the constraints are, what the acceptance criteria are.

A review gets written to a reviews folder. The file name ties it to the spec it reviews. The review has its own shape: what the spec is for, what the reviewer found, what the reviewer recommends, what the reviewer is blocking on.

An implementation gets written to a branch. The branch name ties it to the spec it implements. The commit messages reference the spec. The pull request body references the spec and the reviews. The implementation artifact isn't one document; it's the code, plus the commit log, plus the PR description. All of it readable, all of it on disk.

A back-review closes the loop in the audit record. The closure references the original finding, the spec that addressed it, and the implementation that shipped.

Every artifact has a path. Every path is human-readable. Anyone can walk the system by reading folders. The relationships between artifacts are explicit in file names, folder structure, and the lifecycle records that track them. There is no inferred context. There is no implicit shared state. The whole system is laid out on disk where any agent, any engineer, or any auditor can read it. That last audience matters more than people expect, and it gets its own paper in this library, Logs Are Not Audit. A log says the system did something. The artifact chain says why, on whose review, against which spec.

A discrete session, every time

The mechanical part of this is the discrete session.

When an agent gets called to do work, it gets called with a specific input artifact and a specific task. The briefing includes the artifact, the agent's role definition, the relevant parts of the constitution, and the task description. It does not include the previous twenty conversations the system had today. It does not include yesterday. It does not include the session another agent ran this morning.

The agent does its work, writes its artifact, and the session ends. The next time that role gets invoked, a new session starts with a new task and new input artifacts. The previous session's reasoning is gone.

This fights every intuition people bring to AI. The agent doesn't get smarter over the course of a workflow. It doesn't accumulate domain understanding across sessions. Each session is independent, and that independence is the point. Nothing carries forward except what was deliberately written down, and everything deliberately written down can be read by anyone.

The trade-off is real, so let's name it. A long-running conversation can produce richer output in some narrow cases. The architecture gives that up for inspectability. The bet is that discrete, inspectable sessions, each producing a document, beat a long-running conversation that produces richer output nobody can audit.

In practice the bet has been right, because of what the work actually is. Agents in a production org aren't writing novels. They're writing specs, code changes, reviews, findings, summaries. None of these benefit from the agent having a long memory. All of them benefit from the output being a document the next reader can attack.

The handoff is the artifact. The artifact is the audit trail.

When something goes wrong, the trail is already written. Read the spec. Read the review. Read the commits. Read the back-review. Each one is a discrete document produced by a discrete session. The chain of reasoning is on disk, not in anyone's head, human or otherwise.

Continuity or inspectability. Pick one.

Most agent frameworks are built on the opposite assumption: an agent is a long-running entity with state. The frameworks ship "agent memory," "agent learning," "conversation history." The marketing positions these as table stakes. Without memory, the argument goes, your agent is just an API call.

The argument is right, in a way it doesn't intend. The agents in this architecture are, at bottom, structured invocations with an artifact protocol around them. The structure is doing the work the framework's memory was supposed to do, and doing it where you can see it.

What a long-running agent with memory gives you is a thing that can hold a complicated workflow in its head. What it costs you is the ability to inspect what's in the head. Those come as a pair. You can have continuity, or you can have inspectability. Frameworks that choose continuity are making a real trade; they're just rarely honest that it is one.

And the trade tilts harder as the stakes rise. A chatbot answering product questions can have memory; the worst case is a wrong answer someone reads immediately. A workflow that ships code to production cannot, because the chain of reasoning has to be auditable, and a ninety-minute conversation is not auditable. A folder of files is.

What this lets you build

A few things become possible that weren't before.

You can review an agent's work after the fact, holding the exact artifact the next agent saw. The review is a real review, not a guess at what the agent was thinking.

You can replay a failure. Take the input artifact. Run a different agent against it. Compare the outputs. The disagreement points at where the system went off the rails.

You can change an agent's behavior without retraining anything. Update the role definition. Update the constitution. The next session starts with the new instructions, and the next artifact reflects them. The change is itself auditable, because the role definition lives in version control with everything else.

You can scale by adding agents in the same roles. Two implementers working different specs can't trample each other, because they share no context. Each reads its own inputs and writes its own outputs. The parallelism is free, which is not a word infrastructure engineers get to use often.

And you can debug. The artifacts are the debug log. When a fix doesn't work, you read the spec, the review, the commits, the back-review. Somewhere in that folder is the misstep, findable in an afternoon, because the trail is on disk in human-readable form instead of buried in a transcript of twelve agents talking to each other.

One more thing the protocol sets up. If agents communicate through documents, then some documents deserve harder protection than convention can provide, and the next paper in this library, The Code the Build Won't Let You Touch, is about the short list of files the build refuses to let anyone edit at all. The artifact protocol says the work moves through files. The registry says a few files don't move. Together they describe a system where structure does the supervising, every minute of every day.

The takeaway: Every agent invocation is a discrete session. The handoff between agents is an artifact, not a conversation. Hallucinations become inspectable documents instead of compounding contexts. The whole chain of reasoning lives on disk in human-readable form, which means it can be audited, replayed, parallelized, and debugged. The trade is continuity for inspectability. For production work, inspectability wins.

References

  1. SpeyAI agent org architecture. Live reference at speyai.com. Every agent invocation is a discrete session; specs, reviews, and implementation artifacts live as files on disk; the handoff between agents is the artifact, not a shared context.

  2. Ji, Lee, Frieske, Yu, Su, Xu, Ishii, Bang, Madotto, & Fung. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12). On error propagation across long generation contexts, the technical mechanism behind why discrete sessions outperform long-running conversations on production work.

  3. United States Federal Rules of Civil Procedure, Rules 8 and 12. The procedural backbone of adversarial, document-driven proceedings. Every filing is a discrete artifact; each party reads what the other wrote with no obligation to interpret it charitably. The legal system's century-old version of the artifact protocol.

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.

The missing layer

Architecture as governance. See how it runs.