AI Engineer

The Log Is The Agent - Ishaan Sehgal, Omnara

3372 summary words 15 min summary Watch video

Start with the signal

15 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: An agent's identity is its append-only event log, not the model/runtime—making the log the primary durable artifact enables reliability, portability, ownership, and prevents vendor lock-in.
  • Why it matters: This architectural pattern solves production reliability, migration, forking, and vendor lock-in challenges in agent systems by treating the log as the system rather than exhaust.
  • Best use: Watch for architectural insight if building agent systems; note the ownership/lock-in warning if evaluating managed agent platforms; review for patterns applicable to Ken's own agent/workflow automation projects.

Executive Summary

Ishaan Sehgal (CEO, Omnara) argues that the agent industry has misidentified what an agent actually is. Most people point to the model, runtime, or execution environment, but Sehgal claims the agent is its log—the append-only event history capturing every user input, model output, tool call, permission prompt, and state transition. Using a video game save file analogy (Skyrim), he explains that just as a character's identity persists in its save data across different PlayStations, an agent's identity persists in its log across different models, runtimes, and workers. This framing makes the execution environment disposable: any worker can read the log, advance the agent one step, write the result, and disappear, with another worker picking up later.

The log-first architecture delivers structural properties that current agent harnesses bolt on as afterthoughts: reliability (permission prompts survive process crashes), scalability (one process can advance thousands of agents), forking (branch logs to run Claude/GPT/open-source in parallel), migration (move between providers without losing identity), and multiplayer/sharing (the log shows how the agent reached its output). Sehgal addresses two objections: compaction (lossy projection of the log, not the agent itself) and external state changes (the log captures the agent's view of the world, not the entire world, just like a game save file). He critiques existing tools—Claude Code, Codex, OpenCode—for treating logs as fire-and-forget side effects, leading to data loss and corruption.

The talk's critical insight is about ownership and lock-in. Sehgal warns that the deepest form of lock-in is log lock-in, not model or API lock-in. If Anthropic, Google, or another managed provider owns your agent's log, they own your agent's entire history—your personal data, company data, workflows, and decisions. Since agents are the most intimate technology you'll run, losing control of the log means losing control of the agent. He positions Omnara's architecture (debuting an open-source managed agent platform) around user-owned, fully inspectable session logs, with workers, models, and tools all coordinating around the log rather than containing the agent's state.

This is a pitch for a specific architectural philosophy and a product (Omnara's managed agents platform at omnara.com/managed), but the conceptual framework is valuable independent of the vendor. The analogy to database design (logs as the durable primitive, everything else as projections/views) makes the argument legible to engineers. For Ken, the key takeaway is the ownership risk in managed agent platforms and the architectural pattern of log-as-identity for building reliable, portable agent systems.

Key Takeaways

  • Claim: An agent's identity is its log (the append-only event history), not the model or runtime executing it. | Evidence: Uses Skyrim save file analogy: if your PlayStation explodes, the character isn't gone because it lives in the save data; similarly, if a worker dies, the agent persists in the log. Every state transition (user input, model output, tool call, result, permission, failure) is written to the log. | Caveat: The log doesn't contain the entire world (e.g., forking won't unsend an email the agent sent), only the agent's view of the world and its actions—analogous to how a game save doesn't contain the entire game engine. | Implication: This framing makes the execution environment disposable and enables any worker to resume an agent from its log, solving reliability and portability problems in production agent systems. | Timestamp: 00:00-03:30
  • Claim: Treating the log as the primary system enables structural properties (reliability, scalability, forking, migration, ownership) rather than requiring them to be bolted on. | Evidence: Reliability: permission prompts survive process crashes because they're in the log. Scalability: one process can advance thousands of agents by reconstructing state from logs on each turn. Forking: branch logs to run different models (Claude, GPT, open-source) in parallel. Migration: move between providers without losing identity since the log is the continuity. | Caveat: Compaction (summarizing the log for finite context windows) is lossy and creates a projection, not a perfect reproduction; if you discard the raw log, you've lost part of the agent. | Implication: For Ken's agent systems, this architectural pattern solves failover, scaling, A/B testing (forking), and vendor switching without rewriting the agent's entire history. | Timestamp: 04:45-07:30
  • Claim: The deepest form of lock-in is log lock-in, not model or API lock-in, because if a provider owns your log, they own your agent. | Evidence: Anthropic and Google have cloud-managed agents; managed providers want to own the hosted loop, memory, sandboxes, compaction. Agents require personal data, company data, workflows, decisions—all recorded in the log. If the log lives on someone else's infrastructure under their policies, queryable by their systems, they don't just host your agent, they own it. | Caveat: No explicit caveat provided; assumes managed providers will assert control over logs rather than offering export/ownership guarantees. | Implication: Ken should evaluate any managed agent platform (Anthropic, Google, or others) by asking who owns and controls the log; losing log control means losing the agent's durable identity and history, which is a strategic risk for proprietary workflows. | Timestamp: 10:30-12:00
  • Claim: Current agent harnesses treat the log as an afterthought, leading to data loss and corruption. | Evidence: Claude Code/Codex write messy JSON-L files to local disk with fire-and-forget semantics (if write fails, data is gone). OpenCode stores state in SQLite with GitHub issues reporting corrupt state and data loss. Durable objects hold different shards, making cross-session querying difficult. | Caveat: No mention of whether these tools have improved or whether the issues are inherent to their architecture versus implementation bugs. | Implication: When evaluating or building agent infrastructure, Ken should check whether the log is a first-class durable primitive or a side effect; the latter is a production reliability and data integrity risk. | Timestamp: 09:00-10:30
  • Claim: Omnara's architecture coordinates workers, models, and tools around a user-owned session log, making the worker disposable and enabling survival of real-world failures (crashes, restarts, timeouts, provider failures). | Evidence: Workers read the log, advance the loop one step, write results, and disappear; a different worker reconstructs state from the log and continues. Omnara is debuting an open-source managed agent platform (omnara.com/managed) with fully user-owned, inspectable logs. | Caveat: This is a product pitch; the open-source platform may not be released yet (speaker says 'may be released by the time this recording comes out, or there may still be a waitlist'). No pricing, technical details, or production case studies provided. | Implication: For Ken, this is worth tracking as a potential open-source alternative to managed agent platforms; the log-as-identity pattern is valuable even if Omnara itself isn't the right fit. | Timestamp: 12:00-14:30

Detailed Brief

Core Thesis: The Agent Is The Log, Not The Model or Runtime

  • Claims: Most people incorrectly define an agent as the model or execution environment; the agent is actually its log (the append-only event history).; The log captures every state transition: user inputs, model outputs, tool calls, tool results, permissions, failures.; The model, runtime, and tools are interpreters and appenders to the log; they read, act, and write the next event back.; The execution loop is disposable: a worker claims the session, reads the log, advances one step, writes the result, and disappears; any other worker can pick up later.
  • Evidence: Skyrim save file analogy: if your PlayStation explodes, your character (save data) survives because it's data, not hardware; same for agents.; Database analogy: serious databases are built on logs (the durable sequence of changes); tables/indexes/views are projections. Agents need the same inversion.; Simplified loop: reconstruct state from log → pass to model → model proposes next step → append to log → if tool call, execute and append → repeat.
  • Caveats: The log doesn't contain the entire world (e.g., won't unsend an email or make file changes deterministic); it only captures the agent's view of the world.; Compaction (summarizing the log for finite context windows) is lossy; a summary is a projection, not the agent itself. Keeping the raw log allows regenerating projections; discarding it loses part of the agent.; No discussion of log storage costs, query performance, or how large logs scale in practice.
  • Implications: For Ken's agent systems, this pattern decouples agent identity from infrastructure, enabling reliability (survive crashes), portability (move between providers), and A/B testing (fork logs).; The log becomes the durable primitive; everything else (context fed to model, UI rendering, debugging, auditing) is a projection.; Agent builders should treat the log as the system, not as exhaust or a side effect.

Structural Properties Enabled by Log-First Architecture

  • Claims: Reliability: permission prompts survive process crashes because they're in the log; a new worker reconstructs state and sees the prompt.; Scalability: one process can advance thousands of agents by reconstructing state from logs on each turn; no sticky sessions, no state migration, no coordination overhead.; Forking: branch the log to run different models (Claude, GPT, open-source) in parallel, each storing history up to the fork point and exploring different strategies.; Migration: moving between providers becomes an adapter problem (different models want different projections, different runtimes need different schemas) rather than an identity problem; agent can start on Claude, continue on GPT, finish on Quen without losing itself.; Multiplayer and sharing: the value isn't just the output but the log showing how the agent got there.
  • Evidence: Reliability example: 'If you're using Cloud Code and your agent reaches a permission prompt and the process dies, and then you resume it, the permission prompt will be gone and the agent will be paused. That is unacceptable in production. The permission prompt should stay there.'; Scalability: '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.'; Forking: 'One branch can run on Claude, another branch can run on GPT, another can run on your favorite open source model.'; Migration: 'The agent should then be able to start on Claude, continue on GPT, and finish on Quen without losing itself. The log serves as a source of continuity.'
  • Caveats: No quantitative evidence (e.g., how many agents per process, latency, cost trade-offs).; Forking and migration assume models/runtimes can meaningfully interpret each other's log projections; interoperability isn't guaranteed.; Sharing the log raises privacy/security concerns if it contains sensitive data; no discussion of redaction or access control.
  • Implications: For Ken's operational systems, this pattern solves production reliability (no lost prompts/state), enables horizontal scaling (just add workers), and supports A/B testing (fork logs for different models).; For investing/analysis, this is a useful lens for evaluating agent infrastructure: does the vendor treat the log as a first-class primitive or as exhaust?; Migration capability is strategically valuable if Ken wants to avoid model/provider lock-in in agent workflows.

Ownership and Lock-In: The Critical Warning

  • Claims: The strongest form of lock-in is log lock-in, not model or API lock-in, because the log is the durable identity of the agent.; If a provider (Anthropic, Google, or others) owns your log, they own your agent and all its history.; Managed providers will want to own the stack (hosted loop, managed memory, sandboxes, compaction, background agents).; Agents are the most intimate technology you'll run, requiring personal data, company data, workflows, decisions—all recorded in the log.; If the log lives on someone else's infrastructure under their policies and queryable by their systems, they don't just host your agent, they own it.
  • Evidence: 'Anthropic has cloud-managed agents. Google has Gemini-managed agents. Every managed provider is going to own more of the stack.'; '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.'; 'The model is replaceable, the runtime is replaceable, the machine is replaceable. The log is a thing that persists.'
  • Caveats: No evidence that Anthropic/Google explicitly claim ownership of logs or prevent export; this is a forward-looking concern, not a documented current issue.; Some managed providers may offer export/ownership guarantees; the talk doesn't distinguish providers.; No discussion of whether log ownership matters differently for consumer vs. enterprise use cases.
  • Implications: Ken should evaluate any managed agent platform by asking: Who owns the log? Can I export it? Is it queryable only by me or also by the provider?; For proprietary workflows, losing log control means losing the durable record of the agent's decisions, which is a strategic risk.; This is an argument for open-source or self-hosted agent platforms where the log is user-controlled; Omnara is positioning itself here.; For Ken's content/business workflows, consider whether the log contains IP or strategy worth protecting from vendor access.

Critique of Current Agent Infrastructure and Omnara's Pitch

  • Claims: Most agent harnesses treat the log as an afterthought, leading to data loss and corruption.; Claude Code/Codex write messy JSON-L files to local disk with fire-and-forget writes (if write fails, data is gone).; OpenCode stores state in SQLite; GitHub issues report corrupt state and data loss.; Durable objects hold different shards, making history reconstruction and cross-session querying difficult.; Omnara's architecture coordinates workers, models, and tools around a user-owned, fully inspectable session log; workers are disposable, and the log is the durable primitive.; Omnara is debuting an open-source managed agent platform (omnara.com/managed) where users fully own and control the log.
  • Evidence: 'Claude Code and Codex will write these messy JSON-L 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.'; '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.'; '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.'; '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.'
  • Caveats: No timestamps, technical specs, or production case studies for Omnara's platform.; The platform may not be released yet ('may be released by the time this recording comes out, or there may still be a waitlist').; No pricing model mentioned; unclear if free/open-source or paid managed service.; Critique of competitors (Claude Code, OpenCode) doesn't provide version numbers or whether issues have been fixed.
  • Implications: For Ken, this is worth tracking as a potential alternative to managed platforms; the open-source aspect is appealing if it delivers on log ownership.; The architectural pattern (log-as-identity, disposable workers) is valuable even if Omnara itself isn't the right tool; Ken could apply this to custom agent systems.; If evaluating agent infrastructure, check whether logs are durable, first-class, and exportable; fire-and-forget writes are a red flag.

Notable Concepts & Terms

  • Log-as-agent: The philosophical/architectural claim that an agent's identity is its append-only event history (log), not the model or runtime executing it; makes the execution environment disposable and the log the durable primitive.
  • Compaction: Summarizing the log into a smaller representation for finite context windows; explicitly lossy (throws away information), treated as a projection of the log, not the agent itself. If you discard the raw log, you've lost part of the agent.
  • Log lock-in: The deepest form of vendor lock-in: if a provider owns your agent's log, they own the durable record of your agent's history, decisions, and data. Contrasted with model/API lock-in, which is swappable.
  • Disposable worker: In Omnara's architecture, a worker claims a session, reads the log, advances the agent one step, writes the result, and disappears. Any other worker can pick up later. The worker is not the agent; it's just the executor.
  • Projection: A view or transformation of the log (e.g., context fed to model, UI rendering, debugging traces, audits, compacted summaries). The log is the source of truth; projections are derived. Borrowed from database terminology.
  • Fire-and-forget writes: A pattern critiqued in Claude Code/Codex where log writes are not confirmed/durable; if the write fails, data is lost. Contrasted with treating the log as a first-class durable primitive.

Operator Notes / Why Ken Should Care

  • For Ken's agent systems: The log-as-identity pattern solves production reliability (survive crashes, permission prompts persist), horizontal scaling (one process advances thousands of agents), and vendor portability (move between Claude/GPT/open-source). Consider adopting this architecture for custom agents or evaluating it in third-party tools.
  • For vendor evaluation: When assessing managed agent platforms (Anthropic, Google, Omnara, or others), ask: Who owns the log? Is it exportable? Is it queryable only by me or also by the provider? Log lock-in is the deepest form of lock-in because it controls the durable history of your agent's decisions and data.
  • For workflows with sensitive data: If Ken's agents handle proprietary IP, company data, or personal workflows, log ownership is a strategic risk. Managed platforms that own the log effectively own the agent's history. Self-hosted or open-source platforms (like Omnara's pitch) may be preferable.
  • For A/B testing/experimentation: The forking capability (branch logs to run different models in parallel) is valuable for testing agent strategies without committing to one path. This is useful for Ken's content/business experiments or investment analysis.
  • For reliability in production: Current agent harnesses (Claude Code, OpenCode) have data loss/corruption issues because they treat logs as side effects. If Ken builds or buys agent infrastructure, prioritize tools where the log is a first-class durable primitive with confirmed writes.
  • For open-source tracking: Omnara's managed agents platform (omnara.com/managed) is debuting with user-owned logs; worth checking if released or joining waitlist. The architectural pattern is valuable independent of the vendor.
  • For investing/analysis: The log-as-identity framing is a useful lens for evaluating agent infrastructure startups. Ask: Is the log treated as the system or as exhaust? Does the product solve vendor lock-in or create it?

Watch Map

  • 00:00-01:30: Introduction and thesis: the agent is the log, not the model or runtime; Skyrim save file analogy.
  • 01:30-03:30: Defining the log: append-only event history (inputs, outputs, tool calls, results, permissions, failures); every state transition is written.
  • 03:30-04:45: Simplified execution loop: reconstruct state from log → model proposes next step → append → tool execution → append → repeat. The loop is disposable.
  • 04:45-06:00: Database analogy: logs are the durable primitive, tables/indexes/views are projections. Agents need the same inversion.
  • 06:00-07:30: Objections: compaction (lossy projection, not the agent itself) and external state (log captures agent's view of the world, not the entire world).
  • 07:30-09:00: Structural properties: reliability (permission prompts survive crashes), scalability (one process advances thousands of agents), forking (branch logs for different models), migration (move between providers without losing identity).
  • 09:00-10:30: Critique of current infrastructure: Claude Code, Codex, OpenCode treat logs as afterthoughts with fire-and-forget writes, leading to data loss and corruption.
  • 10:30-12:00: Ownership and lock-in: log lock-in is the deepest form; if a provider (Anthropic, Google) owns your log, they own your agent. Agents are intimate technology requiring personal/company data.
  • 12:00-14:30: Omnara's architecture: workers coordinate around user-owned session logs; workers are disposable, enabling survival of real-world failures. Open-source managed platform pitch (omnara.com/managed).
  • 14:30-15:11: Closing: the agent is the durable history (the log). Once you see it this way, reliability, compaction, forking, migration, ownership, scalability fall into place. Treat the log as the system, not exhaust.

Source/Metadata

  • Title: The Log Is The Agent - Ishaan Sehgal, Omnara
  • Transcript words: 3753
  • Duration seconds: 911
  • Timestamp note: Timestamps generated based on transcript structure and video duration (911 seconds / ~15 minutes). Timestamps are approximate.
Search this video Resume transcript at 0%
Full transcript 2479 words · 17 min read
0:00

SPEAKER_00

Hey everyone, I'm Ishan, 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 100 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.

0:08

SPEAKER_00

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. 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.

0:16

SPEAKER_00

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 call, tool result, permission, failure.

0:25

SPEAKER_00

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 the log, the rest of the system becomes a lot easier to reason about because every operation is either reading from or appending to the log.

0:35

SPEAKER_00

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.

0:42

SPEAKER_00

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.

0:54

SPEAKER_00

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. 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 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.

1:05

SPEAKER_00

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.

1:22

SPEAKER_00

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.

1:32

SPEAKER_00

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. 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.

2:02

SPEAKER_00

But the point 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 Skyrim, the Skyrim save file doesn't contain the entire game engine or every asset in the map. 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. 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.

2:24

SPEAKER_00

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.

2:43

SPEAKER_00

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 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.

3:00

SPEAKER_00

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 one linear path, you can easily branch the log.

3:19

SPEAKER_00

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. And then sharing is something that 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 an adapter problem.

3:36

SPEAKER_00

Different models may want different projections of the log, and different runtimes may need different schemas, 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 Quen 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 JSON-L files to local disk.

3:59

SPEAKER_00

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. 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. 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.

4:29

SPEAKER_00

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 runtime is replaceable, the machine is replaceable.

5:00

SPEAKER_00

The log is a thing that persists. I have another slide for this because I think it's really worth taking seriously right now. Anthropic has cloud-managed agents. Google has Gemini-managed agents. Every managed provider is going to own more of the stack. They're going to want to. They're going to want to have the hosted agent loop and managed memory and sandboxes 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.

5:36

SPEAKER_00

I have another slide for this because I think it's really worth taking seriously right now. Anthropic has cloud-managed agents. Google has Gemini-managed agents. Every managed provider is going to own more of the stack. They're going to want to have the hosted agent loop and managed memory and sandboxes 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.

5:59

SPEAKER_00

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 Amnara. 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. It'll get its results. It'll write it back to the log. And then if the model provider requires tools, it will dispatch those tools to the right execution environment to finish somewhere else.

6:30

SPEAKER_00

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 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.

6:54

SPEAKER_00

It's the core of the open source managed agent 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 amnara.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.

7:38

SPEAKER_00

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.

8:12

SPEAKER_00

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 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.

8:55

SPEAKER_00

And then sharing is something that is something that is something that is something that is 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 an adapter problem. Different models may want different projections of the log, and different runtimes may need different schemas, but those all become just engineering problems. They're not identity problems.

9:51

SPEAKER_00

The agent should then be able to start on Claude, continue on GPT, and finish on Quen 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 JSON-L 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. 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:31

SPEAKER_00

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.

11:16

SPEAKER_00

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 runtime is replaceable, the machine is replaceable. The log is a thing that persists. I have another slide for this because I think it's really worth taking seriously right now. Anthropic has cloud-managed agents. Google has Gemini-managed agents. Every managed provider is going to own more of the stack. They're going to want to.

11:56

SPEAKER_00

They're going to want to have the hosted agent loop and managed memory and sandboxes 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 Umnara.

12:36

SPEAKER_00

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. 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.

13:11

SPEAKER_00

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 agent 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

SPEAKER_00

It's fully controlled by you. And that's something we believe in strongly. If you're interested, check it out at amnara.com slash 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.

14:42

SPEAKER_00

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.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note