AI agents are hitting the same inflection point.
Most people think an agent is the model, the runtime, or the loop currently executing the task. Those things matter. But they aren't the agent.
In this piece I'll argue that an agent is its data: specifically its history of events, which we'll call the log. When the log is constructed correctly, an agent can be resumed from it alone. And that single property unlocks a whole set of capabilities that make even advanced agent use cases easier to reason about and build into everyday applications.
Defining the Agent
So what is the log? Defining the agent means defining the log. At its core, the log is the event history: every user input, model output, tool call, and tool result that accumulates as the agent works — an append-only record of everything that happened.
The log also carries a reference to the session definition: the system prompt, tool descriptions, and skills the agent is running under. This doesn't change from turn to turn, so it's more a versioned constant than an active part of the stream.
Together they form the agent's full state. Nothing the agent is lives in the runtime, the model, or the tools; they're just interpreters and appenders. They read the durable state, act on it, and write the next event back. So you can hand a fresh executor the same log, and it will reconstruct exactly where the agent was and continue from there. The log is enough, on its own, to resume the agent.
The Log in Practice
Once you define the agent as the log, the rest of the system gets easier to reason about. Every operation on the agent either reads the log, appends to it, or renders a view of it. The model reads a view and produces the next action. The tool runner executes a tool call and appends the result. The UI reads the log and renders a timeline; the tracing system reads it and renders traces; an auditor reads it to reconstruct what happened. It's the same pattern databases settled on years ago: The tables, indexes, and caches are all projections over an underlying log of changes. See the diagram adapted from @dexhorthy's excellent 12-factor agents exploration in the online version of this piece – it’s worth a read.
In practice, a simplified loop can look like this:
It looks simple, but the insight is that each pass claims a temporary lease, reads the log, advances one step, and writes the result back. The loop is idempotent and fault-tolerant: As long as every meaningful state transition is durably written, any executor can pick up the session and carry on.
Compaction Is Not the Log
While the log can grow indefinitely, a model's view of it can't: Context windows are finite. You can't hand the model the entire raw history on every call. This is where compaction comes in. And since compaction replaces everything before it with a summary, doesn't that destroy the claim that the log is the agent?
No, it doesn't. Remember, compaction is lossy. A compacted summary doesn't reproduce the agent's state in a smaller form; it throws information away.
That actually reinforces the claim. The full log is the record; a compaction is just one projection of it, the way a materialized view isn't the database and a summary isn't the conversation. Keep the raw log, and you can always generate new projections from it. Throw the raw log away and keep only the compaction, and you've lost part of the agent. So it's cleanest to treat compaction as a best-effort, lossy fork, one you resume as a new log.
The full session log streams into a smaller compacted cube, shedding detail along the way.
The Log Isn't the Whole World
There's an obvious objection, worth taking seriously: What about tools that change state outside the log? An agent edits a file, opens a GitHub issue, sends an email. Now there's state living somewhere other than the log. Doesn't that sink the claim?
No, it doesn't. You re-derive the agent's state from the log, not the world: If it already sent the email, forking back won't un-send it, and a file it edited may have changed underneath it. The log doesn't make the world deterministic or reversible. It keeps a faithful, resumable record of what the agent did and saw, which is exactly the thing you can't afford to lose. The save file makes the same move: It doesn't contain the Skyrim engine or the map, just the player-specific state needed to drop you back in. And if the world has changed since the agent last ran, the agent, much like the character, updates its worldview as it re-engages with what's around it.
Properties That Fall Out
Reasoning about agents this way gives you a set of nice system properties. They aren't independent; they all fall out of the same assumption that the log is the agent.
Reliability. Consider what happens today with Claude Code: If the agent reaches a permission prompt and the process dies, and you resume it, the permission prompt is gone and the agent has paused. That's unacceptable in production. When the log is the agent, the executor is allowed to be fallible: A new worker picks up the session, reconstructs the state, and the permission prompt is right where it was. The process died; the agent didn't.
Scalability. Most harnesses run one process per agent, which means the agent is tied to the machine running it. When the log is the state, you flip that model: One process can advance thousands of agents, each reconstructing its state from the log on each turn. The agent isn't tied to any single machine or worker, making failover trivial. And scaling out is just adding more workers: no sticky sessions, no state migration, no coordination overhead.
Forking. Instead of one linear path, you can branch the log. One branch runs on Claude, another on GPT, another on a local Qwen, each exploring a different strategy, in a different sandbox, with different tools. Exploring different approaches becomes a lot simpler to architect.
Multiplayer. Sharing an agent shouldn't mean copying a transcript into Slack. That's like sharing a screenshot of a database and calling it replication. If the log is the agent, sharing means granting access to a durable history someone else can inspect, resume, or extend.
Migration. If the agent's identity is trapped inside provider-specific assumptions, moving providers is painful. If the log is the agent, migration becomes an adapter problem. Different models may want different projections, but those are engineering problems, not identity problems. The log is the continuity, and the agent should be able to pick up and resume interchangeably with any model provider.
These are only a few examples. Once you start thinking of agents this way, they become pieces of data, and many of the things you can do with data become possible with agents too. Read the rest of this article at omnara.com/blog/the-log-is-the-agent.
