WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=UPwGaM2MKHY NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/UPwGaM2MKHY.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:00.320 --> 00:00:06.160 Hey everyone, I'm Ishaan the CEO of Amnara and today I'm going to be talking about the log is the agent. s2 00:00:06.160 --> 00:00:16.920 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. s3 00:00:16.920 --> 00:00:25.920 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. s4 00:00:25.920 --> 00:00:32.160 So think about a character you've spent a hundred hours playing in your favorite video game, in this case Skyrim. s5 00:00:32.160 --> 00:00:34.360 What exactly is your character? s6 00:00:34.360 --> 00:00:36.240 Is it the game engine? s7 00:00:36.240 --> 00:00:37.520 Is it the PlayStation? s8 00:00:37.520 --> 00:00:39.840 Is it the controller? s9 00:00:39.920 --> 00:00:41.240 No, it's not. s10 00:00:41.240 --> 00:00:48.080 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. s11 00:00:48.080 --> 00:00:49.160 Your character is data. s12 00:00:49.160 --> 00:00:52.040 It's the save file. s13 00:00:52.040 --> 00:00:58.520 And this is important because if your PlayStation bursts into flames, your character isn't gone. s14 00:00:58.520 --> 00:01:11.280 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 s15 00:01:11.280 --> 00:01:13.040 captured in its data. s16 00:01:13.040 --> 00:01:19.600 The character lives in the data and this is the framing that I want to bring to agents. s17 00:01:19.600 --> 00:01:24.560 Today when people talk about agents, they usually point at the wrong thing. s18 00:01:24.560 --> 00:01:32.760 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. s19 00:01:32.760 --> 00:01:34.160 The agent is its data. s20 00:01:34.160 --> 00:01:37.120 It's specifically the log. s21 00:01:37.120 --> 00:01:39.520 So what actually is the log? s22 00:01:39.520 --> 00:01:44.960 At the simplest level, the log is the append-only event history of the agent. s23 00:01:44.960 --> 00:01:58.240 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. s24 00:01:58.240 --> 00:02:06.440 This is important because it means that the identity of the agent isn't tied to the runtime or the model or the tools. s25 00:02:06.440 --> 00:02:09.720 Those things are all just interpreting and appending to the log. s26 00:02:09.720 --> 00:02:14.040 They're reading the log, acting on it, and writing the next event back. s27 00:02:14.040 --> 00:02:22.800 And that's important because then just using the log on its own is enough to resume the agent. s28 00:02:22.800 --> 00:02:31.760 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 s29 00:02:31.760 --> 00:02:33.640 to the log. s30 00:02:33.640 --> 00:02:38.400 The model is reading from the log and then determining the next action. s31 00:02:38.400 --> 00:02:43.720 The tool runner is then executing that action and then it's appending that result. s32 00:02:43.720 --> 00:02:46.400 And this is all operating in a loop. s33 00:02:46.400 --> 00:02:49.680 Everything coordinates itself around the log. s34 00:02:49.680 --> 00:02:52.680 In practice, a simplified loop can look something like this. s35 00:02:52.680 --> 00:02:54.760 You can reconstruct the state from the log. s36 00:02:54.760 --> 00:02:56.440 You can pass that state to the model. s37 00:02:56.440 --> 00:03:00.440 The model can propose the next step and then append that response to the log. s38 00:03:00.440 --> 00:03:06.720 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. s39 00:03:06.720 --> 00:03:10.640 The important insight is not that this loop is complicated. s40 00:03:10.640 --> 00:03:13.239 The important insight is that the loop is disposable. s41 00:03:13.239 --> 00:03:19.920 A worker can claim the session, read the log, advance the agent one step, write the result, and then just completely disappear. s42 00:03:19.920 --> 00:03:24.840 And then that means that any other worker can pick it up later. s43 00:03:24.840 --> 00:03:27.160 This pattern should feel familiar. s44 00:03:27.160 --> 00:03:29.360 Databases had to learn this first. s45 00:03:29.360 --> 00:03:41.519 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. s46 00:03:41.519 --> 00:03:47.040 And that log is the durable sequence of changes. s47 00:03:47.040 --> 00:03:49.880 Everything else is a view. s48 00:03:49.880 --> 00:03:52.520 I I agents need the same inversion. s49 00:03:52.520 --> 00:04:04.400 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. s50 00:04:04.400 --> 00:04:08.200 The context that gets fed into the model is a projection of that log. s51 00:04:08.200 --> 00:04:12.400 The UI that gets rendered on top is a projection of that log. s52 00:04:12.400 --> 00:04:15.040 Debugging and traceability is a projection. s53 00:04:15.040 --> 00:04:16.920 Auditing is a projection. s54 00:04:16.920 --> 00:04:20.359 Compaction is also projection, which we'll talk about. s55 00:04:20.359 --> 00:04:22.560 But the log itself is not a projection. s56 00:04:22.560 --> 00:04:27.400 The log is the durable history that all of these projections can come from. s57 00:04:27.400 --> 00:04:31.000 Now, there are two objections to the log as the agent that are worth discussing. s58 00:04:31.000 --> 00:04:32.720 So, I'm going to talk about them now. s59 00:04:32.720 --> 00:04:34.600 Now, let's start with compaction. s60 00:04:34.600 --> 00:04:39.800 A log can grow indefinitely, but a model's view of it can't. s61 00:04:39.800 --> 00:04:41.680 Context windows are finite. s62 00:04:41.680 --> 00:04:48.360 So, eventually, you do need to compact the log into a smaller representation that the model can reason about. s63 00:04:48.360 --> 00:04:54.960 But the important point is that this compaction is not magic and it doesn't break the claim that the log is the agent. s64 00:04:54.960 --> 00:04:57.000 Compaction is lossy. s65 00:04:57.000 --> 00:05:02.800 A compacted summary is not going to perfectly reproduce the state of the agent in a smaller form. s66 00:05:02.800 --> 00:05:05.240 It's actually going to throw information away. s67 00:05:05.240 --> 00:05:10.640 The point is the full log is the record and a compaction is just one projection of it. s68 00:05:10.640 --> 00:05:16.720 Just like how a materialized view is not the database or a summary of a conversation is not the conversation. s69 00:05:16.720 --> 00:05:21.320 If you keep the raw log, you can always generate new projections from it. s70 00:05:21.320 --> 00:05:27.880 But if you throw away the raw log and keep only the compaction, you've effectively lost part of the agent. s71 00:05:27.880 --> 00:05:36.360 So, it's cleanest to treat compaction as a best effort lossy fork, one that you can resume as a new log. s72 00:05:36.360 --> 00:05:41.080 The second objection is what about tools that change state outside of the log? s73 00:05:41.080 --> 00:05:42.440 And that's true. s74 00:05:42.440 --> 00:05:44.200 An agent can edit a file. s75 00:05:44.200 --> 00:05:45.520 It can create a GitHub issue. s76 00:05:45.520 --> 00:05:46.680 It can send an email. s77 00:05:46.680 --> 00:05:49.640 So, clearly, there is state outside of the log. s78 00:05:49.640 --> 00:05:54.040 But, the point is is that the log is not supposed to contain the whole world. s79 00:05:54.040 --> 00:05:56.840 The log is just the agent's view of the world. s80 00:05:56.840 --> 00:06:04.360 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. s81 00:06:04.360 --> 00:06:09.760 It just contains the player specific state, which is needed to drop you back into that world. s82 00:06:09.760 --> 00:06:13.360 And the same is true for the log and agents. s83 00:06:13.360 --> 00:06:21.800 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. s84 00:06:21.800 --> 00:06:25.760 If the agent sent an email, forking back won't unsend it. s85 00:06:25.760 --> 00:06:30.280 If some file got changed underneath, the agent won't know about it. s86 00:06:30.280 --> 00:06:37.760 But, the log's job is to record what the agent did, what it saw, what changed, and what it needs to continue. s87 00:06:37.760 --> 00:06:40.919 It stores that identity, and that's its purpose. s88 00:06:40.919 --> 00:06:46.240 And much like that Skyrim character save file, it's not meant to store the entire world. s89 00:06:46.240 --> 00:06:49.680 It's just meant to store its view of it. s90 00:06:49.680 --> 00:06:55.120 So, once you start treating the log as a primitive, a whole bunch of system properties will fall out naturally. s91 00:06:55.120 --> 00:06:58.080 So, the first property is reliability. s92 00:06:58.080 --> 00:07:00.720 Consider what happens today with Cloud Code. s93 00:07:00.720 --> 00:07:11.640 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, s94 00:07:11.640 --> 00:07:13.800 and the agent will be paused. s95 00:07:13.800 --> 00:07:16.919 And that is unacceptable in production. s96 00:07:16.919 --> 00:07:18.960 The permission prompt should stay there. s97 00:07:18.960 --> 00:07:26.720 So, this is just a sign of when you architect your agent in a way where the log isn't the agent. s98 00:07:26.720 --> 00:07:31.200 When the log is the agent, the executor is allowed to be fallible. s99 00:07:31.200 --> 00:07:33.360 A new worker will pick up the session. s100 00:07:33.360 --> 00:07:38.480 It'll reconstruct the state, and it'll see that the permission prompt is there right where it was. s101 00:07:38.480 --> 00:07:43.880 So, even though the process died, the agent didn't along with it. s102 00:07:43.880 --> 00:07:46.320 The second property is scalability. s103 00:07:46.320 --> 00:07:52.200 Most harnesses will run one process per agent, which means that the agent is tied to the machine running it. s104 00:07:52.200 --> 00:07:55.080 When the log is the state, you flip that model. s105 00:07:55.080 --> 00:07:58.520 One process can now advance thousands of agents. s106 00:07:58.520 --> 00:08:06.400 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. s107 00:08:06.400 --> 00:08:12.640 This makes failover trivial, and it also makes scaling just a matter of adding more workers. s108 00:08:12.640 --> 00:08:17.560 There's no sticky sessions, there's no state migration, and there's no coordination overhead. s109 00:08:17.560 --> 00:08:20.440 Forking becomes a whole lot more natural, too. s110 00:08:20.440 --> 00:08:25.919 Instead of having to force like one linear path, you can easily branch the log. s111 00:08:25.919 --> 00:08:31.840 One branch can run on Claude, another branch can run on GPT, another can run on your favorite open-source model. s112 00:08:31.840 --> 00:08:39.479 Each of the branches can store some of the history up until the fork point, and then they can explore different strategies. s113 00:08:39.479 --> 00:08:41.560 Multiplayer is another property. s114 00:08:41.560 --> 00:08:46.839 Sharing an agent with someone should not mean having to copy some transcript and paste it into Slack. s115 00:08:46.839 --> 00:08:57.400 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. s116 00:08:57.400 --> 00:09:09.280 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. s117 00:09:09.280 --> 00:09:20.040 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. s118 00:09:20.040 --> 00:09:22.520 Migration follows the same pattern. s119 00:09:22.520 --> 00:09:33.839 If an agent's identity is trapped in provider-specific threads and memories and formats and runtime assumptions, moving providers becomes really painful. s120 00:09:33.839 --> 00:09:38.560 But if the log is the agent, migration is just a adapter problem. s121 00:09:38.560 --> 00:09:49.000 Different models may want different projections of the log, and different runtimes may need different schemas, but those are all become just engineering problems. s122 00:09:49.000 --> 00:09:51.600 They're not identity problems. s123 00:09:51.600 --> 00:09:58.760 The agent should then be able to start on Claude, continue on GPT, and finish on Gwen without losing itself. s124 00:09:58.760 --> 00:10:03.320 The log serves as a source of continuity. s125 00:10:03.320 --> 00:10:06.760 Here's the problem with a lot of current agent infrastructure. s126 00:10:06.760 --> 00:10:10.840 Most agent harnesses today will treat the log as an afterthought. s127 00:10:10.840 --> 00:10:24.040 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. s128 00:10:24.040 --> 00:10:32.240 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. s129 00:10:32.240 --> 00:10:41.000 Durable objects often end up holding different shards, that makes reconstructing history difficult, it makes querying across sessions difficult. s130 00:10:41.000 --> 00:10:46.520 And in all of these scenarios, the log is just a side effect, it's not the system. s131 00:10:46.520 --> 00:10:54.320 And that's a problem, because when you treat the log as a first-class citizen, it makes all of these properties become structural. s132 00:10:54.320 --> 00:11:02.120 You don't have to bolt them on, which is what it feels like is being done today, they all just fall out. s133 00:11:02.120 --> 00:11:05.000 The next point is incredibly important. s134 00:11:05.000 --> 00:11:07.560 This brings us to ownership. s135 00:11:07.560 --> 00:11:15.520 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. s136 00:11:15.520 --> 00:11:17.080 Models can be swapped. s137 00:11:17.080 --> 00:11:20.120 It's not API or tool lock-in either. s138 00:11:20.120 --> 00:11:22.680 Those can be wrapped, and those can be adapted. s139 00:11:22.680 --> 00:11:27.400 The deepest form of lock-in is actually log lock-in. s140 00:11:27.400 --> 00:11:40.360 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, s141 00:11:40.360 --> 00:11:43.440 the log is the thing that persists. s142 00:11:43.440 --> 00:11:47.880 I have another slide for this because I think it's really worth taking seriously right now. s143 00:11:47.880 --> 00:11:55.600 Anthropic has Claude managed agents, Google has Gemini managed agents, every managed provider is going to own more of the stock. s144 00:11:55.600 --> 00:11:56.600 They're going to want to. s145 00:11:56.600 --> 00:12:03.400 They're going to want to have the hosted agent loop and manage memory and sand boxes and compaction and background agents. s146 00:12:03.400 --> 00:12:11.000 They're going to want to own your agents and agents are arguably the most intimate piece of technology you'll ever run. s147 00:12:11.000 --> 00:12:19.840 For an agent to be useful, it needs to have your personal data, your company's data, your workflows, your decisions. s148 00:12:19.840 --> 00:12:29.960 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. s149 00:12:29.960 --> 00:12:31.840 They own it. s150 00:12:31.840 --> 00:12:36.400 This is the architecture we have been building towards at Unara. s151 00:12:36.400 --> 00:12:41.960 We think of agent execution as the set of components that are coordinated around the log. s152 00:12:41.960 --> 00:12:54.480 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 s153 00:12:54.480 --> 00:13:03.000 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. s154 00:13:03.000 --> 00:13:12.320 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 s155 00:13:12.320 --> 00:13:26.880 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. s156 00:13:26.880 --> 00:13:29.640 There's so many different things that can go wrong. s157 00:13:29.640 --> 00:13:33.680 And if an agent is a running process, that's extremely terrifying. s158 00:13:33.680 --> 00:13:38.080 But if the agent is the log, it's simply an execution detail. s159 00:13:38.080 --> 00:13:44.520 And this is important because it's the core of what we're building. s160 00:13:44.520 --> 00:13:48.280 It's the core of the open-source managed agents platform that we're debuting. s161 00:13:48.280 --> 00:13:58.200 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. s162 00:13:58.200 --> 00:14:02.680 And that's something we believe in strongly. s163 00:14:02.680 --> 00:14:06.760 If you're interested, check it out at amnar.com/managed. s164 00:14:07.560 --> 00:14:13.240 It may be released by the time this recording comes out or there may still be a waitlist there. s165 00:14:13.240 --> 00:14:17.120 So, in closing, the main thing I want to leave you with is this. s166 00:14:17.120 --> 00:14:22.920 An agent is not just a model call, it's not just a prompt or a loop or a sandbox. s167 00:14:22.920 --> 00:14:24.120 It's not any of those things. s168 00:14:24.120 --> 00:14:28.920 The agent is the durable history of the work being done, and that history is the log. s169 00:14:28.920 --> 00:14:33.880 Once you start to see it this way, a whole lot of things fall into place. s170 00:14:33.880 --> 00:14:42.560 Reliability, compaction, forking, migration, multiplayer, ownership, scalability, so many things. s171 00:14:42.560 --> 00:14:48.600 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. s172 00:14:48.600 --> 00:14:50.440 And that's super important. s173 00:14:50.440 --> 00:14:54.200 So, if this was useful, stay tuned to what we're building at Amnara. s174 00:14:54.200 --> 00:14:59.720 We're getting ready to open source, as I mentioned, our managed agents platform, and you can join here. s175 00:14:59.720 --> 00:15:07.880 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. s176 00:15:07.880 --> 00:15:11.160 So, thanks for tuning in.