A conference talk by Ishaan Sehgal (CEO and cofounder of Omnara, YC S25) arguing that the core identity of an AI agent is not the framework, model, or tools, but the append-only session log. Using an analogy of video game save files, it claims the session log is where an agent's state, continuity, and history live, and that treating the log as the primitive yields properties such as durability, resumable continuity, forkability, addressability, observability, and portability across models, runtimes, and machines. It also raises the governance question of agent ownership when the model provider controls the log. # Observation Document: "The Log Is The Agent - Ishaan Sehgal, Omnara" ## Explicit Self-Description Evidence - **Role claim**: Speaker opens with <blockquote>"Hey everyone, I'm Ishaan the CEO of Amnara"</blockquote> — identifies himself as a company CEO giving a technical talk. - **Company/product claim**: He states the talk's architecture is <blockquote>"the core of the open-source managed agents platform that we're debuting"</blockquote> at "Unara" (transcript spelling varies: "Amnara"/"Omnara"/"Unara"; title metadata says "Omnara"). - **Call to action**: Directs viewers to <blockquote>"check it out at amnar.com/managed"</blockquote> and to a waitlist/open-source launch. - **Positioning claim**: Frames the company's belief: the session log will be <blockquote>"fully own, fully inspect, it's fully controlled by you."</blockquote> ## Observable Presentation Patterns ### Intended Audience - **AI engineers and agent-infrastructure builders**: The talk presumes familiarity with concepts like context windows, compaction, JSONL logs, SQLite state, durable objects, sandboxing, and provider SDKs. - **Technologists evaluating agent platforms**: It critiques specific tools by name — Claude Code, Codex, OpenCode, Anthropic and Google managed agents — suggesting an audience actively choosing agent infrastructure. - **Open-source-interested practitioners**: The closing emphasizes an upcoming open-source release and invite to "join here." ### Claimed Scope of Content - A **conceptual thesis talk**, not a tutorial: the central argument is <blockquote>"the thing that actually gives an agent its identity is its log."</blockquote> - Uses an extended **analogy** (Skyrim save files vs. game engine) to argue the agent is data, not runtime. - Covers **system design consequences**: reliability, scalability, forking across models (Claude/GPT/open-source), multiplayer, migration, and ownership. - Includes a **competitive critique** of existing harnesses (e.g., "fire and forget" log writes in Claude SDK mode; OpenCode SQLite corruption reports). ### Presentation Format - Solo speaker, structured argument format: thesis → analogy → objections (compaction, external state) → derived properties → product tie-in → closing summary. - Technical argumentation style with first-person framing throughout ("I think," "we believe," "we've been building towards"). ## Claim vs. Demonstration Distinction - **Creator claims (about self/channel)**: CEO role; company building a log-centric, open-source managed agents platform with user ownership of logs. These are asserted, not demonstrated in the video. - **Demonstrated patterns**: Deep technical fluency in agent architecture and database design (write-ahead log analogy); willingness to name and criticize competitors; use of the talk to funnel interest toward a product launch — evidenced by two direct product references and the closing <blockquote>"stay tuned to what we're building at Amnara."</blockquote> ## Notes on Source Quality - Transcript appears auto-generated: inconsistent company-name spellings ("Amnara," "Unara" vs. title "Omnara"); one probable transcription error ("Cloud Code" for "Claude Code" in the reliability section). # Delivery Observation: "The Log Is The Agent" — Ishaan Sehgal, Omnara ## Overall Tone - **Conversational and thesis-driven**: the talk opens with a plainly stated thesis and repeats it like a refrain — *"the thing that actually gives an agent its identity is its log."* - **Convincing, not lecturing**: uses argumentative framing such as *"Now, there are two objections to the log as the agent that are worth discussing. So, I'm going to talk about them now."* - Ends with a light **promotional pivot** to his company: *"check it out at amnar.com/managed"* (transcript renders the company name variously as "Amnara"/"Unara" — uncertainty noted). ## Recurring Phrases - **"The log is the agent"** — repeated throughout as the central mantra. - **"This is important because…"** — used repeatedly to flag significance: *"This is important because it means that the identity of the agent isn't tied to the runtime…"* - **"that's important"** / *"it's very important"* / *"incredibly important"* — frequent importance markers. - **"a whole lot"** — recurring intensifier: *"a whole bunch of system properties,"* *"a whole lot easier to reason about,"* *"a whole lot more natural."* - **"projection of that log"** — anaphora-style repetition: *"The context… is a projection. The UI… is a projection. Debugging and traceability is a projection. Auditing is a projection. Compaction is also projection."* ## Analogies & Teaching Habits - **Extended concrete analogy**: the Skyrim save file is the anchor metaphor, introduced early and deliberately **recalled later**: *"It's just like how in the video game in in Skyrim, the Skyrim save file doesn't contain the entire game engine."* - **Historical precedent pattern**: grounds the new idea in a known one — *"Databases had to learn this first… underneath every serious database is a log."* - **Rhetorical question sequences**: *"Is it the game engine? Is it the PlayStation? Is it the controller? No, it's not."* - **Enumeration of benefits**: properties listed one by one — reliability, scalability, forking, multiplayer, migration, ownership — each with a short illustrative scenario. - **Preemptive objection handling**: names counterarguments explicitly (compaction, external state) and answers each with the analogy. ## Vocabulary & Style - Technical, systems-engineering vocabulary: *append-only, durable, state transition, failover, sticky sessions, materialized view, lossy, fire and forget.* - Named real-world examples for critique: *"Claude code and Codex will write these messy JSONL files,"* *"Open code's another example, they store state in a SQLite file."* - Contrasts as a structuring device: *"the loop is not complicated. The important insight is that the loop is disposable,"* *"You don't have to bolt them on… they all just fall out."* ## Disfluencies & Delivery Notes - Minor stumbles/restarts appear in the transcript: *"I I agents need the same inversion,"* *"in in Skyrim"* — suggesting spontaneous, spoken delivery rather than tight scripting. - Occasional trailing grammar: *"agents are arguably the most intimate piece of technology you'll ever run"* (word "technology"/"software" choice slightly loose). ## Uncertainty - No timestamps or audio available; pacing, pauses, and emphasis beyond the transcript cannot be observed. - Company-name inconsistency ("Amnara"/"Unara"/"amnar.com") is a transcript artifact; actual pronunciation is unverified. # Observation Document: "The Log Is The Agent" — Ishaan Sehgal, Omnara ## Speaker - **Ishaan Sehgal**, CEO of Omnara (identified via transcript self-introduction; company name appears as "Amnara"/"Unara" in transcript variants). ## Core Thesis - Most people mistakenly think of an agent as **the model or execution environment**. - Sehgal argues the correct abstraction: **the agent's identity is its log** — the append-only event history. - Analogy: a Skyrim character is not the game engine or PlayStation; it is the **save file**. If the console dies, the character persists in the data and can be resumed. ## What the Log Is - **Append-only event history**: every user input, model output, tool call, tool result, permission, failure. - Every state transition is written to the log; model, runtime, and tools merely **read from and append to** the log. - The log alone is **sufficient to resume** the agent. - Analogous to databases: tables/indexes/views are projections; the underlying **write-ahead log is the durable truth**. Context window, UI, debugging, auditing, and compaction are all **projections of the log**. ## Stated Objections and Responses ### 1. Compaction - Context windows are finite, so logs must be compacted. - Sehgal's qualification: compaction is **lossy** — "a compacted summary is not going to perfectly reproduce the state." The full log remains the record; compaction is one projection. Discarding the raw log means "you've effectively lost part of the agent." Cleanest treatment: compaction as a **best-effort lossy fork** resumable as a new log. ### 2. External state - Agents change state outside the log (files, GitHub issues, emails). - Response: the log is **the agent's view of the world**, not the whole world. Forking won't unsend emails or detect changed files. The log records identity and what the agent saw/did — it "cannot make that world deterministic." ## Claimed System Properties (from log-as-primitive) - **Reliability**: contrasts with Claude Code, where a process death loses permission prompts; with log-as-agent, executors are fallible and any worker resumes state. - **Scalability**: no one-process-per-agent; one process can advance thousands of agents; failover trivial, no sticky sessions or state migration. - **Forking**: branch the log; different branches can run on different models (Claude, GPT, open-source). - **Multiplayer**: sharing = granting access to log history; teammates/managers/other agents can view or consume it. - **Migration**: switching providers becomes an adapter/engineering problem, not an identity problem — "start on Claude, continue on GPT, and finish on Gwen." - **Ownership / lock-in**: the deepest lock-in is **log lock-in**, not model or API lock-in. Managed providers (Anthropic's Claude managed agents, Google's Gemini managed agents) will want to own hosted loops, memory, compaction — and thereby own your agent. Agents are "the most intimate piece of technology"; if the log lives on provider infrastructure, "they own it." ## Critique of Current Infrastructure - **Claude Code and Codex**: messy JSONL files to local disk; SDK-mode writes are "fire and forget" — failed writes mean data loss. - **OpenCode**: SQLite storage with reported corrupt state and data loss (per GitHub issues). - **Durable objects**: sharded state makes history reconstruction and cross-session querying difficult. - In all cases, "the log is just a side effect, not the system." ## Omnara's Product Positioning - Omnara's architecture: workers, model providers, and tool execution environments coordinated around the log; workers are executors, not the agent. - Framed as necessary for real-world failure (crashes, timeouts, provider failures). - Debuting an **open-source managed agents platform** built around a session log the user "fully owns, inspects, and controls." URL: amnar.com/managed (may be waitlisted at time of recording). ## Closing Claim - The agent is "the durable history of the work being done." Once the log is treated as the system itself rather than exhaust, reliability, compaction, forking, migration, multiplayer, ownership, and scalability "fall out" naturally. ## Notes on Qualifications and Bias - Claims about competitor products (Claude Code, Codex, OpenCode) are Sehgal's characterizations presented without cited evidence beyond references to GitHub issues. - The talk doubles as promotion for Omnara's platform; the architectural argument and product pitch are intertwined, as the speaker states explicitly. # Speaker & Role Attribution Record ## Video - **Title:** The Log Is The Agent - Ishaan Sehgal, Omnara - **Video ID:** `01a15ca8-e5fe-7ff8-923a-c63aa5da90a6` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Ishaan (self-introduced) | **Creator / Presenter / CEO of Omnara** | *"I'm Ishaan the CEO of Amnara [Omnara]"* — sole speaker throughout | - **Single-speaker talk**; no guests, narrators, or other identified roles appear in the transcript. ## Provenance & Referenced Entities ### Products / companies referenced (third-party claims, not endorsements) - **Claude Code / Claude SDK mode** — claimed to write "messy JSONL files to local disk" with fire-and-forget writes. - **Codex** — claimed to write messy JSONL files. - **Open Code** — claimed to store state in SQLite; speaker cites "GitHub issues" alleging corrupt state and data loss (no specific issue links given). - **Anthropic (Claude managed agents), Google (Gemini managed agents)** — cited as examples of managed providers the speaker claims will "own your agents." - **Models named:** Claude, GPT, Gwen (as migration examples). ### Analogies used (speaker's framing, not external sources) - Skyrim save file / PlayStation analogy. - Database write-ahead log / materialized views analogy. ## Promotional Segments — Flagged - **Omnara product pitch:** Speaker describes Omnara's architecture and announces an **open-source managed agents platform** ("this is the architecture we have been building towards at Unara [Omnara]"). - **Call to action:** *"check it out at amnar.com/managed"* — notes possible waitlist or release. - **Closing promotion:** *"stay tuned to what we're building at Amnara... you can join here."* ## Availability & Uncertainty - **Comments availability:** Not stated in transcript or metadata. - **Curated metadata:** None supplied beyond title. - **Name spelling ambiguity:** Speaker's company rendered variously as "Amnara," "Unara," "Amnara" in transcript (likely ASR variance of "Omnara" per title). 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.