The Log Is The Agent - Ishaan Sehgal, Omnara

AI Engineer · 15 min · 176 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:00Hey everyone, I'm Ishaan the CEO of Amnara and today I'm going to be talking about the log is the agent.
00:06The 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.
00:16I 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.
00:25So think about a character you've spent a hundred hours playing in your favorite video game, in this case Skyrim.
00:32What exactly is your character?
00:34Is it the game engine?
00:36Is it the PlayStation?
00:37Is it the controller?
00:39No, it's not.
00:41Those things matter and those things are what will interact with and they'll run the character but none of those things are your character.
00:48Your character is data.
00:49It's the save file.
00:52And this is important because if your PlayStation bursts into flames, your character isn't gone.
00:58You 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
01:11captured in its data.
01:13The character lives in the data and this is the framing that I want to bring to agents.
01:19Today when people talk about agents, they usually point at the wrong thing.
01:24They'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.
01:32The agent is its data.
01:34It's specifically the log.
01:37So what actually is the log?
01:39At the simplest level, the log is the append-only event history of the agent.
01:44It'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.
01:58This is important because it means that the identity of the agent isn't tied to the runtime or the model or the tools.
02:06Those things are all just interpreting and appending to the log.
02:09They're reading the log, acting on it, and writing the next event back.
02:14And that's important because then just using the log on its own is enough to resume the agent.
02:22Once 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
02:31to the log.
02:33The model is reading from the log and then determining the next action.
02:38The tool runner is then executing that action and then it's appending that result.
02:43And this is all operating in a loop.
02:46Everything coordinates itself around the log.
02:49In practice, a simplified loop can look something like this.
02:52You can reconstruct the state from the log.
02:54You can pass that state to the model.
02:56The model can propose the next step and then append that response to the log.
03:00If the response asks for a tool, you can run that tool and also append that response to the log and then you can repeat.
03:06The important insight is not that this loop is complicated.
03:10The important insight is that the loop is disposable.
03:13A worker can claim the session, read the log, advance the agent one step, write the result, and then just completely disappear.
03:19And then that means that any other worker can pick it up later.
03:24This pattern should feel familiar.
03:27Databases had to learn this first.
03:29For 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.
03:41And that log is the durable sequence of changes.
03:47Everything else is a view.
03:49I I agents need the same inversion.
03:52Today, 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.
04:04The context that gets fed into the model is a projection of that log.
04:08The UI that gets rendered on top is a projection of that log.
04:12Debugging and traceability is a projection.
04:15Auditing is a projection.
04:16Compaction is also projection, which we'll talk about.
04:20But the log itself is not a projection.
04:22The log is the durable history that all of these projections can come from.
04:27Now, there are two objections to the log as the agent that are worth discussing.
04:31So, I'm going to talk about them now.
04:32Now, let's start with compaction.
04:34A log can grow indefinitely, but a model's view of it can't.
04:39Context windows are finite.
04:41So, eventually, you do need to compact the log into a smaller representation that the model can reason about.
04:48But the important point is that this compaction is not magic and it doesn't break the claim that the log is the agent.
04:54Compaction is lossy.
04:57A compacted summary is not going to perfectly reproduce the state of the agent in a smaller form.
05:02It's actually going to throw information away.
05:05The point is the full log is the record and a compaction is just one projection of it.
05:10Just like how a materialized view is not the database or a summary of a conversation is not the conversation.
05:16If you keep the raw log, you can always generate new projections from it.
05:21But if you throw away the raw log and keep only the compaction, you've effectively lost part of the agent.
05:27So, it's cleanest to treat compaction as a best effort lossy fork, one that you can resume as a new log.
05:36The second objection is what about tools that change state outside of the log?
05:41And that's true.
05:42An agent can edit a file.
05:44It can create a GitHub issue.
05:45It can send an email.
05:46So, clearly, there is state outside of the log.
05:49But, the point is is that the log is not supposed to contain the whole world.
05:54The log is just the agent's view of the world.
05:56It'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.
06:04It just contains the player specific state, which is needed to drop you back into that world.
06:09And the same is true for the log and agents.
06:13The log can only faithfully resume or store that agent's identity and its view of the world, but it cannot make that world deterministic.
06:21If the agent sent an email, forking back won't unsend it.
06:25If some file got changed underneath, the agent won't know about it.
06:30But, the log's job is to record what the agent did, what it saw, what changed, and what it needs to continue.
06:37It stores that identity, and that's its purpose.
06:40And much like that Skyrim character save file, it's not meant to store the entire world.
06:46It's just meant to store its view of it.
06:49So, once you start treating the log as a primitive, a whole bunch of system properties will fall out naturally.
06:55So, the first property is reliability.
06:58Consider what happens today with Cloud Code.
07:00If 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,
07:11and the agent will be paused.
07:13And that is unacceptable in production.
07:16The permission prompt should stay there.
07:18So, this is just a sign of when you architect your agent in a way where the log isn't the agent.
07:26When the log is the agent, the executor is allowed to be fallible.
07:31A new worker will pick up the session.
07:33It'll reconstruct the state, and it'll see that the permission prompt is there right where it was.
07:38So, even though the process died, the agent didn't along with it.
07:43The second property is scalability.
07:46Most harnesses will run one process per agent, which means that the agent is tied to the machine running it.
07:52When the log is the state, you flip that model.
07:55One process can now advance thousands of agents.
07:58Each 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.
08:06This makes failover trivial, and it also makes scaling just a matter of adding more workers.
08:12There's no sticky sessions, there's no state migration, and there's no coordination overhead.
08:17Forking becomes a whole lot more natural, too.
08:20Instead of having to force like one linear path, you can easily branch the log.
08:25One branch can run on Claude, another branch can run on GPT, another can run on your favorite open-source model.
08:31Each of the branches can store some of the history up until the fork point, and then they can explore different strategies.
08:39Multiplayer is another property.
08:41Sharing an agent with someone should not mean having to copy some transcript and paste it into Slack.
08:46If the log is the agent, sharing means you simply grant access to that history, so that somebody else can view it and edit it.
08:57A 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.
09:09This 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.
09:20Migration follows the same pattern.
09:22If an agent's identity is trapped in provider-specific threads and memories and formats and runtime assumptions, moving providers becomes really painful.
09:33But if the log is the agent, migration is just a adapter problem.
09:38Different models may want different projections of the log, and different runtimes may need different schemas, but those are all become just engineering problems.
09:49They're not identity problems.
09:51The agent should then be able to start on Claude, continue on GPT, and finish on Gwen without losing itself.
09:58The log serves as a source of continuity.
10:03Here's the problem with a lot of current agent infrastructure.
10:06Most agent harnesses today will treat the log as an afterthought.
10:10So, 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.
10:24Open 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.
10:32Durable objects often end up holding different shards, that makes reconstructing history difficult, it makes querying across sessions difficult.
10:41And in all of these scenarios, the log is just a side effect, it's not the system.
10:46And that's a problem, because when you treat the log as a first-class citizen, it makes all of these properties become structural.
10:54You don't have to bolt them on, which is what it feels like is being done today, they all just fall out.
11:02The next point is incredibly important.
11:05This brings us to ownership.
11:07The 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:15Models can be swapped.
11:17It's not API or tool lock-in either.
11:20Those can be wrapped, and those can be adapted.
11:22The deepest form of lock-in is actually log lock-in.
11:27If 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,
11:40the log is the thing that persists.
11:43I have another slide for this because I think it's really worth taking seriously right now.
11:47Anthropic has Claude managed agents, Google has Gemini managed agents, every managed provider is going to own more of the stock.
11:55They're going to want to.
11:56They're going to want to have the hosted agent loop and manage memory and sand boxes and compaction and background agents.
12:03They're going to want to own your agents and agents are arguably the most intimate piece of technology you'll ever run.
12:11For an agent to be useful, it needs to have your personal data, your company's data, your workflows, your decisions.
12:19The 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.
12:29They own it.
12:31This is the architecture we have been building towards at Unara.
12:36We think of agent execution as the set of components that are coordinated around the log.
12:41The 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
12:54and 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:03The 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
13:12and 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:26There's so many different things that can go wrong.
13:29And if an agent is a running process, that's extremely terrifying.
13:33But if the agent is the log, it's simply an execution detail.
13:38And this is important because it's the core of what we're building.
13:44It's the core of the open-source managed agents platform that we're debuting.
13:48Everything 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.
13:58And that's something we believe in strongly.
14:02If you're interested, check it out at amnar.com/managed.
14:07It may be released by the time this recording comes out or there may still be a waitlist there.
14:13So, in closing, the main thing I want to leave you with is this.
14:17An agent is not just a model call, it's not just a prompt or a loop or a sandbox.
14:22It's not any of those things.
14:24The agent is the durable history of the work being done, and that history is the log.
14:28Once you start to see it this way, a whole lot of things fall into place.
14:33Reliability, compaction, forking, migration, multiplayer, ownership, scalability, so many things.
14:42Because 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.
14:48And that's super important.
14:50So, if this was useful, stay tuned to what we're building at Amnara.
14:54We're getting ready to open source, as I mentioned, our managed agents platform, and you can join here.
14:59The 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.
15:07So, thanks for tuning in.