AI Engineer World's Fair 2026
The Log Is The Agent
Read the talk
The Log Is the Agent
An agent’s durable identity belongs in its event history. Making that history primary changes how workers recover, sessions branch, providers change, and users retain control.
From a talk by Ishaan Sehgal
What survives when the PlayStation dies?
Think of a Skyrim character you have spent 100 hours playing. What is that character: the game engine, the PlayStation, the controller? Each helps run or interact with it, but the character is in the save file. If the PlayStation bursts into flames, replacement hardware can load the cloud save and resume the character. Its history and state survive the machine.
That is the distinction Ishaan Sehgal brings to agents: identity belongs to the durable data, independently of the machinery that executes it. A model and an execution environment matter, just as a game engine and console matter. But replacing them should not mean losing the agent’s accumulated history.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Durable history, disposable execution
The agent’s log is an append-only event history: user inputs, model outputs, tool calls, tool results, permissions, failures, and every state transition. Models, runtimes, and tools interpret that history and append new events. The architectural goal is for the recorded session to contain what another executor needs to continue.
The execution loop follows directly:
- Reconstruct the current state from the log.
- Pass that state to the model to determine the next step.
- Append the model’s response to the log.
- If the response requests a tool, execute it and append its result.
- Repeat from the updated history.
The model proposes an action; the tool runner performs it. Both contribute to the same durable record.
The important property is that the loop is disposable. A worker can claim a session, read its history, advance it one step, write the result, and disappear. Another worker can pick up the session later because continuity resides in the record rather than in the first worker’s memory.
The database analogy makes this inversion easier to see. Tables, indexes, and materialized views expose useful representations of data; the underlying sequence of changes supplies durable history. For an agent session, the log should similarly be primary, with several views derived from it:
| Projection | What it presents |
|---|---|
| Model context | Information for deciding the next action |
| User interface | The session as a person sees it |
| Debugging and traces | How execution unfolded |
| Audit view | A record for inspection |
| Compaction | A smaller representation of history |
These views can differ without becoming separate sources of agent identity. They are projections of the log, not replacements for it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Compaction loses information
A log can keep growing, but a model’s context window cannot. Eventually the model needs a smaller representation of the accumulated history. That necessity does not make the smaller representation equivalent to the original: compaction is lossy. A summary throws information away, just as a summary of a conversation is not the conversation itself.
Keeping the raw log preserves the option to generate different projections later. Keeping only the summary permanently removes some of that history. Sehgal therefore proposes treating compaction as a best-effort, lossy fork that can resume as a new log. The continuation can be useful without claiming to reproduce the original state perfectly. This resolves the context-window objection, but leaves another question: what about tools that change things outside the log?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A saved perspective is not a saved world
An agent can edit a file, create a GitHub issue, or send an email. Those effects exist outside its history. The log is not supposed to contain the whole world; it preserves the agent’s view of that world. A Skyrim save file likewise contains the player-specific state needed to return to the game, not the entire engine or every map asset.
Resuming history does not rewind external effects. Forking to a point before an email was sent cannot unsend it. If someone changes a file underneath the agent, the recorded observation may no longer match the file. The log records what the agent did, what it saw, what changed, and what it needs to continue. It preserves identity and observations without making the environment deterministic.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Recover the permission prompt, then replace the worker
A pending permission prompt makes the reliability requirement concrete. Sehgal reports a Claude Code failure in which a process dies while waiting for permission, then resumes with the prompt gone and the agent paused. This is a reported failure scenario, not a version-specific reproduction. The required behavior is straightforward: a replacement worker reconstructs the pending permission from durable history and presents it where it was. Restarting execution must not erase the decision the user still needs to make.
The same separation changes scheduling. In a process-per-agent design, each session is tied to a running process and its machine. Reconstructing state on each turn instead allows workers to advance different sessions as work becomes available. Sehgal proposes that one process can advance thousands of agents; this is an architectural claim, not a measured benchmark.
Adding workers can then expand execution capacity without moving each agent’s identity between machines. Sehgal describes the resulting failover as trivial and claims no sticky sessions, state migration, or coordination overhead. The concrete benefit is removal of worker affinity; the talk does not specify a claiming or duplicate-execution protocol that would establish zero coordination cost. Once history is independent of a worker, it also becomes natural to branch that history.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When history is only a side effect
This architecture sets a different standard for persistence than writing a transcript alongside execution. Sehgal characterizes Claude Code and Codex as writing local JSONL files, and Claude SDK writes as fire-and-forget: if a write fails, the corresponding history can be lost. These are his descriptions of the implementations discussed in the recording, not verified claims about every current version.
He also points to OpenCode’s local SQLite state and reports of corruption or data loss. The linked OpenCode issue narrows that concern to a user report involving concurrent local and Docker sessions sharing storage. That is a specific failure condition, not evidence that SQLite-backed sessions are generally unreliable.
For Durable Objects, his concern is history distributed across different shards, complicating reconstruction and queries across sessions. That is an application data-layout concern: per-object storage is documented as transactional and strongly consistent. Fragmentation depends on how the application distributes its history. The common design question is whether the system treats the log as authoritative session state or merely as something execution happens to leave behind.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The lock-in that outlasts the model
Models can be swapped, and APIs or tools can be wrapped with adapters. The log is harder to replace because it contains the continuity accumulated through use. That makes log lock-in the deeper ownership concern: if a provider controls the only usable history, changing the model or machine does not free the agent from that provider. The replaceable components execute the work; the persistent record carries its value forward.
Sehgal names Claude Managed Agents and Google’s Managed Agents in the Gemini API as examples of providers moving further into the stack. Hosted loops, managed memory, sandboxes, compaction, and background execution put more of the agent’s operation inside a provider’s infrastructure.
A useful agent accumulates personal data, company data, workflows, and decisions. Its log becomes a record of all of them. Sehgal’s warning concerns control over that record when it lives under another organization’s policies and is queryable by its systems. His ownership language is an argument about architectural dependence, not an established claim about contractual ownership or export restrictions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the session when execution fails
The architecture Sehgal describes for Omnara coordinates separate execution components around the session log:
- A worker advances the loop by calling a model provider.
- It records the model’s response in the log.
- If the response requests tools, it dispatches them to the appropriate execution environment.
- Tool completion adds results to the log.
- A worker—potentially a different one—reconstructs the updated state and continues.
The worker is the executor, and tool execution can finish elsewhere. Neither needs to remain the permanent home of the session.
This separation addresses an ordinary failure landscape: workers crash, machines restart, sandboxes disappear, tool calls time out, providers fail, and users disconnect. Those events still interrupt execution, but they need not erase the agent’s recorded identity. Durable history lets the system distinguish losing an executor from losing the work’s continuity.
Sehgal closes by announcing an open-source managed-agent platform built around a session log users can own, inspect, and control. At recording time, availability was conditional: the managed-platform destination might have a release by publication, or it might still show a waitlist. The announcement describes the intended platform rather than a deployment walkthrough.
A model call, prompt, loop, or sandbox describes only part of an agent’s operation. The durable history connects those parts across time. Making that history primary brings recovery, compaction, branching, migration, collaboration, scaling, and ownership into the same architectural frame. As Omnara prepares to open-source the platform in the recording, the central commitment is to treat the log as the system itself, rather than as exhaust from a process that happened to run.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Google's introduction to hosted agents with tools and isolated code execution.
Further reading
The speaker's companion post connecting agent ownership with inspectable and exportable history.
A bug report documenting corruption during concurrent local and Docker sessions sharing OpenCode storage.
Cloudflare's guide to persisting object state across eviction and restart.
Anthropic's examples of hosted agents with long-running sessions, scoped permissions and audit logs.
Updates since the talk
Open-source managed-agent platform with Postgres-backed state, model configuration and self-hosting instructions.
Read the complete timestamped transcript
- 0:00
Hey, everyone. I'm Ishaan, the CEO of Omnara, and today I'm gonna be talking about the log is the agent. The basic idea of the talk is simple, and that is most people think of an agent as the model or the execution environment that it's running in, and I think that that's the wrong abstraction.
- 0:17
I think that the thing that actually gives an agent its identity is its log, and that's what I'm gonna be arguing today. So think about a character you've spent 100 hours playing in your favorite video game, in this case, Skyrim.
- 0:32
What exactly is your character? Is it the game engine? Is it the PlayStation? Is it the controller? No, it's not. Those things matter, and those things are what we'll interact with, and they'll run the character, but none of those things are your character.
- 0:48
Your character is data. It's the save file. And this is important because if your PlayStation bursts into flames, your character isn't gone. You can buy another PlayStation, you can download your save file from the cloud, and you can resume exactly where they were.
- 1:06
And that's because the agent and its identity and history and its state is all captured in its data. The character lives in the data. And this is the framing that I want to bring to agents.
- 1:19
Today, when people talk about agents, they usually point at the wrong thing. They'll say that the agent is the model, or they'll say that it's the runtime. And again, as I mentioned earlier, those things matter, but they're not the agent.
- 1:32
The agent is its data. It's specifically the log. So what actually is the log? At the simplest level, the log is the append-only event history of the agent. It's every user input, every model output, every tool call, tool result, permission, failure.
- 1:52
And the idea is that every state transition that the agent takes is written to the log. This is important because it means that the identity of the agent isn't tied to the runtime or the model or the tools.
- 2:06
Those things are all just interpreting and appending to the log. They're reading the log, acting on it, and writing the next event back. And that's important because then just using the log on its own is enough to resume the agent.
- 2:22
Once you define the agent as the log, the rest of the system becomes a whole lot easier to reason about because every operation is either reading from or appending to the log.
- 2:33
The model is reading from the log and then determining the next action. The tool runner is then executing that action, and then it's appending that result. And this is all operating in a loop.
- 2:46
Everything coordinates itself around the log. In practice, a simplified loop can look something like this. You can reconstruct the state from the log. You can pass that state to the model.
- 2:56
The model can propose the next step and then append that response to the log. If the response asks for a tool, you can run that tool and also append that response to the log, and then you can repeat.
- 3:06
The important insight is not that this loop is complicated. The important insight is that the loop is disposable. A worker can claim the session, read the log, advance the agent one step, write the result, and then just completely disappear.
- 3:20
And then that means that any other worker can pick it up later. This pattern should feel familiar. Databases had to learn this first. For years, databases looked like these non-transparent systems that were hard to reason about with tables and indexes and materialized views, but underneath every serious database is a log, and that log is the durable
- 3:45
sequence of changes. Everything else is a view. I think agents need the same inversion. Today, agents are treated as, again, these complicated systems that are opaque, and they're filled with models and prompts and tool calls.
- 4:00
But for the durable session, the log should be primary. The context that gets fed into the model is a projection of that log. The UI that gets rendered on top is a projection of that log.
- 4:12
Debugging and traceability is a projection. Auditing is a projection. Compaction is also a projection, which we'll talk about. But the log itself is not a projection. The log is the durable history that all of these projections can come from.
- 4:27
Now, there are two objections to the log as the agent that are worth discussing, so I'm gonna talk about them now. Now let's start with compaction. A log can grow indefinitely, but a model's view of it can't.
- 4:39
Context windows are finite, so eventually you do need to compact the log into a smaller representation that the model can reason about. But the important point is that this compaction is not magic, and it doesn't break the claim that the log is the agent.
- 4:55
Compaction is lossy. A compacted summary is not gonna perfectly reproduce the state of the agent in a smaller form. It's actually gonna throw information away. The point is the full log is the record, and a compaction is just one projection of it, just like how a materialized view is not the database or a summary of a conversation
- 5:15
is not the conversation. If you keep the raw log, you can always generate new projections from it. But if you throw away the raw log y- and keep only the compaction, you've effectively lost part of the agent.
- 5:28
So it's cleanest to treat compaction as a best effort lossy fork, one that you can resume as a new log. The second objection is what about tools that change state outside of the log?
- 5:41
And that's true. An agent can edit a file, it can create a GitHub issue, it can send an email, so clearly there is state outside of the log. But the point is, is that the log is not supposed to contain the whole world.
- 5:54
The log is just the agent's view of the world. It's just like how in the video game i- in Skyrim, the Skyrim save file doesn't contain the entire game engine or every asset in the map.
- 6:04
It just contains the player's specific state, which is needed to drop you back into that world, and the same is true for the log and agents. The log can only faithfully resume or store that agent's identity and its view of the world, but it cannot make that world deterministic.
- 6:21
If the agent sent an email, forking back won't unsend it. If some file got changed underneath, the agent won't know about it. But the log's job is to record what the agent did, what it saw, what changed, and what it needs to continue.
- 6:37
It stores that identity, and that's its purpose, and much like that Skyrim character save file, it's not meant to store the entire world. It's just meant to store its view of it.
- 6:49
So once you start treating the log as a primitive, a whole bunch of system properties will fall out naturally. So the first property is reliability. Consider what happens today with Claude Code.
- 7:00
If you're using Claude Code and your agent reaches a permission prompt and the process dies for whatever reason, and then you resume it, the permission prompt will be gone, and the agent will be paused, and that is unacceptable in production.
- 7:17
The permission prompt should stay there. So this is just a sign of when you architect your agent in a way where the log isn't the agent. When the log is the agent, the executor is allowed to be fallible.
- 7:31
A new worker will pick up the session, it'll reconstruct the state, and it'll see that the permission prompt is there right where it was. So even though the process died, the agent didn't along with it.
- 7:44
The second property is scalability. Most harnesses will run one process per agent, which means that the agent is tied to the machine running it. When the log is the state, you flip that model.
- 7:55
One process can now advance thousands of agents. Each of them can reconstruct their state from the log on each turn, and they don't need to be tied to any single machine or worker.
- 8:06
This makes failover trivial, and it also makes scaling just a matter of adding more workers. There's no sticky sessions, there's no state migration, and there's no coordination overhead. Forking becomes a whole lot more natural too.
- 8:20
Instead of having to force, like, one linear path, you can easily branch the log. One branch can run on Claude, another branch can run on GPT, another can run on your favorite open source model.
- 8:32
Each of the branches can store some of the history up until the fork point, and then they can explore different strategies. Multiplayer is another property. Sharing an agent with someone should not mean having to copy some transcript and paste it into Slack.
- 8:47
If the log is the agent, sharing means you simply grant access to that history so that somebody else can view it and edit it. A teammate can open the session, they can see what happened, a manager can observe without taking over, and even another agent could consume the same session as context.
- 9:09
This is really important because it means that the value is not just what the agent produced, it's also the log which indicates how it got there. Migration follows the same pattern.
- 9:22
If an agent's identity is trapped in provider-specific threads and memories and formats and runtime assumptions, moving providers becomes really painful. But if the log is the agent, migration is just a adapter problem.
- 9:38
Different models may want different projections of the log, and different runtimes may need different schemas, uh, but those all become just engineering problems. They're not identity problems. The agent should then be able to start on Claude, continue on GPT, and finish on Qwen without losing itself.
- 9:58
The log serves as a source of continuity. Here's the problem with a lot of current agent infrastructure. Most agent harnesses today will treat the log as an afterthought. So Claude Code and Codex will write these messy JSONL files to local disk, and even in Claude SDK mode, those writes are fire and forget, which means that i- if
- 10:21
for whatever reason the write fails, the data is gone. OpenCode's another example. They store state in a SQLite file, and there's a lot of GitHub issues around how there's corrupt state and data loss.
- 10:32
Durable Objects often end up holding different shards. That makes reconstructing history difficult. It makes querying across sessions difficult. And in all of these scenarios, the log is just a side effect.
- 10:44
It's not the system. And that's a problem, because when you treat the log as a first-class citizen, it makes all of these properties become structural. You don't have to bolt them on, which is what it feels like is being done today.
- 10:58
They all just fall out. The next point is incredibly important. This brings us to ownership. The strongest form, now that we've established that the log is the agent, the strongest form of lock-in isn't model lock-in.
- 11:15
Models can be swapped. It's not API or tool lock-in either. Those can be wrapped, and those can be adapted. The deepest form of lock-in is actually log lock-in. If a provider owns your log, then the provider effectively owns your agent.
- 11:33
And long term, the log is the valuable part because the model is replaceable, the runtime's replaceable, the machine's replaceable. The log is the thing that persists.
- 11:43
I have another slide for this because I think it's really worth taking seriously right now. Anthropic has Claude Managed Agents. Google has Gemini Managed Agents. Every managed provider is gonna own more of the stack.
- 11:55
They're going to want to. They're gonna wanna have the hosted agent loop and managed memory and sandboxes and compaction and background agents. They're gonna want to own your agents, and agents are arguably the most intimate piece of technology you'll ever run.
- 12:11
For an agent to be useful, it needs to have your personal data, your company's data, your workflows, your decisions. The log is the record of all of that, and if it lives on someone else's infrastructure under their policies and queryable by their systems, they don't just host your agent, they own it.
- 12:32
This is the architecture we have been building towards at Omnara. We think of agent execution as this set of components that are coordinated around the log. The worker advances the loop, but the worker is not the agent, it's just the executor, and it will call out to the model provider.
- 12:51
It'll get its results. It'll write it back to the log. And then if the model provider requires tools, it will go ahead and dispatch those tools to the right execution environment to finish somewhere else.
- 13:03
The tools will complete, and then those results will get appended back to the log, and then a worker, most likely a different run, will then reconstruct the state, and it'll continue.
- 13:12
And this is very important because this is how real agent systems will have to survive real-world failure, because workers will crash, machines will restart, sandboxes disappear, tool calls will time out, providers will fail, users connect.
- 13:27
There's so many different things that can go wrong, and if an agent is a running process, that's extremely terrifying. But if the agent is the log, it's simply an execution detail.
- 13:38
And this is important because it's the core of what we're building. It's the core of the open source managed agents platform that we're debuting. Everything will be built around the session log, which we will make sure that you can fully own, fully inspect.
- 13:55
It's fully controlled by you, and that's something we believe in strongly. If you're interested, check it out at omnara.com/managed. It may be released by the time this recording comes out, or there may still be a waitlist there.
- 14:13
So in closing, the main thing I want to leave you with is this: An agent is not just a model call. It's not just a prompt or a loop or a sandbox.
- 14:23
It's not any of those things. The agent is the durable history of the work being done, and that history is the log. Once you start to see it this way, a whole lot of things fall into place: reliability, compaction, forking, migration, multiplayer, ownership, scalability, so many things, because you're gonna stop treating the log as this exhaust from
- 14:45
the system, and you're gonna treat it as the system itself. And that's super important. So if this was useful, stay tuned to what we're building at Omnara. We're getting ready to open source, as I mentioned, our managed agents platform, and you can join here.
- 14:59
The log as the agent is just one of several pieces that we think are gonna be making agents a whole lot more powerful in the future. So thanks for tuning in.