The Log Is the Agent

Type: kb/sources/types/snapshot.md · Tags: x-article

Author: @ishaansehgal Post: https://x.com/ishaansehgal/status/2065129901427130678 Created: 2026-06-11T17:51:51.000Z

Think about a character you have spent 100 hours playing in Skyrim or Elden Ring. What exactly is your character? Is it the game engine? No. Is it the PlayStation? No. Is it the controller? No. Your character is the save file. If your PlayStation bursts into flames, your character is not dead. You buy another PlayStation, download your save file from the cloud, and your character is exactly where they were, mid-swing. 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. (diagram below adapted from @dexhorthy excellent 12-factor agents; worth a read if you haven't.)

In practice, a simplified loop can look like this: while session_has_work: take_temporary_lease(session_id) state = reconstruct_from_log(session_id) response = model.next(state) append(response, to=session_log)

if response.requests_tool:
    append(tool_call_started, to=session_log)
    result = run_tool(response.tool_call)
    append(result, to=session_log)
    continue

finish_turn(session_id)

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 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. The log as a second-class citizen Most agent harnesses today treat the log as an afterthought. Claude Code and Codex write transcripts as messy JSONL files to local disk — in Claude SDK mode, those writes are fire-and-forget, meaning if anything goes wrong before the write completes, that data is gone. OpenCode stores state in a local SQLite file; GitHub issues report corruption and data loss. Durable objects often end up holding different shards, making reconstructing history difficult. The log is a side effect, not the system. When you treat the log as a first-class citizen — durable, structured, replayable, and independent of the machine running the agent — all of these properties become structural. You don't bolt them on. They fall out. Owning the log One last point I'd want you to leave with: owning the log matters enormously. If the log is the agent, then whoever owns the log owns the agent. Long-term, the strongest form of lock-in isn't model lock-in: models can be swapped. It isn't API or tool lock-in either; those can be wrapped and adapted. The deepest lock-in is log lock-in. If a provider owns the only durable record of your agent, then that provider owns your agent. You can export a projection — a transcript, say — and still lose the agent, because the agent isn't its final output; it's the path-dependent history that produced it. This is worth taking seriously right now. Anthropic has Claude Managed Agents. Google has Gemini managed agents. Every major provider is moving to own more of the stack: hosted agent loop, managed memory, sandboxes, compaction, background execution. They want to own your agents, and agents are arguably the most intimate piece of technology you'll ever run. For an agent to be useful, it needs access to your personal information, your company's data, your workflows, your decisions. The log is a record of all of that. If it lives on someone else's infrastructure, under their retention policies, queryable by their systems, then they don't just host your agent. They own it. That's not an argument against managed infrastructure; it's useful and probably inevitable for most teams. But you should know where your log lives, who can inspect it, and whether it can be replayed, forked, migrated, or exported. Once the session log is the primitive, log ownership is agent ownership. How we handle this in practice at Omnara At Omnara we think about agent execution as a set of components coordinated around a durable session log. A worker advances the loop, but the worker isn't the agent; it's just the current executor. When an agent calls a tool, the worker doesn't have to sit there holding all the state in memory. It writes to the log that a tool call started, dispatches the tool to whatever execution environment it belongs in, and lets it finish elsewhere. When the tool completes, its result gets appended back to the log, and a worker (maybe a different one) reconstructs the state and continues. This matters because agent systems have to survive real-world failure: workers crash, machines restart, sandboxes vanish, tool calls run long, providers fail, users disconnect. If the agent is the running process, all of that is terrifying. If the agent is the log, it's just execution detail. The session keeps going because the agent's state was never trapped inside the thing executing it. Treating the log as the system — durable, structured, and independent of any single machine — is the core of how we've built Omnara. Conclusion The point of this piece was to get you reasoning about agents from first principles. An agent is the durable history of the work being done, and that history is the log. Once you see it this way, a lot falls into place: reliability, scalability, compaction, forking, migration, multiplayer, ownership. It also changes how you build. You stop treating the log as exhaust the system gives off and start treating it as the system itself. The loop becomes an executor over the log. It's the same inversion databases went through years ago: the durable history is primary, and everything else is a projection. If this was useful, stay tuned to what we're building at Omnara. We're getting ready to open-source our managed agent platform, and you can join the waitlist here. "The log is the agent" is just one of several pieces we think will make agents far more powerful in the future.