The Log Is The Agent - Ishaan Sehgal, Omnara

Hey everyone, I'm Ishaan the CEO of Amnara and today I'm going to 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. I think that the thing that actually gives an agent its identity is its log and that's what I'm going to be arguing today. So think about a character you've spent a hundred hours playing in your favorite video game, in this case Skyrim. 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 will interact with and they'll run the character but none of those things are your character. 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 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. 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. 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 called, tool result, permission, failure 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. 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. Once you define the agent as a 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. 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. 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. 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. 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. 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 sequence of changes. Everything else is a view. I I 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, 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. Debugging and traceability is a projection. Auditing is a projection. Compaction is also 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. Now, there are two objections to the log as the agent that are worth discussing. So, I'm going to talk about them now. Now, let's start with compaction. A log can grow indefinitely, but a model's view of it can't. 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. Compaction is lossy. A compacted summary is not going to perfectly reproduce the state of the agent in a smaller form. It's actually going to 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 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 and keep only the compaction, you've effectively lost part of the agent. 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? 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. The log is just the agent's view of the world. It's just like how in the video game in in Skyrim, the Skyrim save file doesn't contain the entire game engine or every asset in the map. It just contains the player 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. 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. 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. 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 Cloud Code. If you're using Cloud 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Different models may want different projections of the log, and different runtimes may need different schemas, but those are 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 Gwen without losing itself. 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 if for whatever reason the write fails, the data is gone. Open code'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. 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, 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, 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. 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 and long-term the log is the valuable part because the model is replaceable, the runtimes replaceable, the machines are replaceable, the log is the thing that persists. 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 going to own more of the stock. They're going to want to. They're going to want to have the hosted agent loop and manage memory and sand boxes and compaction and background agents. They're going to 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 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. This is the architecture we have been building towards at Unara. We think of agent execution as the 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, 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. The tools will complete and then those results will get appended back to the log and then a worker, most likely a different one, will then reconstruct the state and it'll continue 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. 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. 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, it's fully controlled by you. And that's something we believe in strongly. If you're interested, check it out at amnar.com/managed. It may be released by the time this recording comes out or there may still be a waitlist there. 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. 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 going to stop treating the log as this exhaust from the system, and you're going to treat it as the system itself. And that's super important. So, if this was useful, stay tuned to what we're building at Amnara. We're getting ready to open source, as I mentioned, our managed agents platform, and you can join here. The log as the agent is just one of several pieces that we think are going to be making agents a whole lot more powerful in the future. So, thanks for tuning in.