The Log Is The Agent

Think of a Skyrim character you have spent 100 hours playing. What is that character: the game engine, the PlayStation, the controller? Each helps run or interact with it, but the character is in the save file. If the PlayStation bursts into flames, replacement hardware can load the cloud save and resume the character. Its history and state survive the machine.

That is the distinction Ishaan Sehgal brings to agents: identity belongs to the durable data, independently of the machinery that executes it. A model and an execution environment matter, just as a game engine and console matter. But replacing them should not mean losing the agent’s accumulated history.

The agent’s log is an append-only event history: user inputs, model outputs, tool calls, tool results, permissions, failures, and every state transition. Models, runtimes, and tools interpret that history and append new events. The architectural goal is for the recorded session to contain what another executor needs to continue.

The execution loop follows directly:

1. Reconstruct the current state from the log.
2. Pass that state to the model to determine the next step.
3. Append the model’s response to the log.
4. If the response requests a tool, execute it and append its result.
5. Repeat from the updated history.

The model proposes an action; the tool runner performs it. Both contribute to the same durable record.

The important property is that the loop is disposable. A worker can claim a session, read its history, advance it one step, write the result, and disappear. Another worker can pick up the session later because continuity resides in the record rather than in the first worker’s memory.

The database analogy makes this inversion easier to see. Tables, indexes, and materialized views expose useful representations of data; the underlying sequence of changes supplies durable history. For an agent session, the log should similarly be primary, with several views derived from it:

These views can differ without becoming separate sources of agent identity. They are projections of the log, not replacements for it.

A log can keep growing, but a model’s context window cannot. Eventually the model needs a smaller representation of the accumulated history. That necessity does not make the smaller representation equivalent to the original: compaction is lossy. A summary throws information away, just as a summary of a conversation is not the conversation itself.

Keeping the raw log preserves the option to generate different projections later. Keeping only the summary permanently removes some of that history. Sehgal therefore proposes treating compaction as a best-effort, lossy fork that can resume as a new log. The continuation can be useful without claiming to reproduce the original state perfectly. This resolves the context-window objection, but leaves another question: what about tools that change things outside the log?

An agent can edit a file, create a GitHub issue, or send an email. Those effects exist outside its history. The log is not supposed to contain the whole world; it preserves the agent’s view of that world. A Skyrim save file likewise contains the player-specific state needed to return to the game, not the entire engine or every map asset.

Resuming history does not rewind external effects. Forking to a point before an email was sent cannot unsend it. If someone changes a file underneath the agent, the recorded observation may no longer match the file. The log records what the agent did, what it saw, what changed, and what it needs to continue. It preserves identity and observations without making the environment deterministic.

A pending permission prompt makes the reliability requirement concrete. Sehgal reports a Claude Code failure in which a process dies while waiting for permission, then resumes with the prompt gone and the agent paused. This is a reported failure scenario, not a version-specific reproduction. The required behavior is straightforward: a replacement worker reconstructs the pending permission from durable history and presents it where it was. Restarting execution must not erase the decision the user still needs to make.

The same separation changes scheduling. In a process-per-agent design, each session is tied to a running process and its machine. Reconstructing state on each turn instead allows workers to advance different sessions as work becomes available. Sehgal proposes that one process can advance thousands of agents; this is an architectural claim, not a measured benchmark.

Adding workers can then expand execution capacity without moving each agent’s identity between machines. Sehgal describes the resulting failover as trivial and claims no sticky sessions, state migration, or coordination overhead. The concrete benefit is removal of worker affinity; the talk does not specify a claiming or duplicate-execution protocol that would establish zero coordination cost. Once history is independent of a worker, it also becomes natural to branch that history.

A fork retains history up to a chosen point, then lets subsequent events diverge. One branch could use Claude, another GPT, and another an open-source model. Each begins with shared history and explores a different strategy; there is no need to force every experiment into one linear continuation.

Collaboration becomes access to the session itself rather than copying a transcript into Slack. The same history supports several roles:

• Teammate: Open the session, inspect what happened, and participate in it.
• Manager: Observe progress without taking over execution.
• Another agent: Consume the session as context for its own work.

The useful artifact is both the output and the history explaining how that output was produced.

Migration extends the same principle across providers. Provider-specific threads, memories, formats, and runtime assumptions can trap a session inside one stack. An independently retained log makes the problem one of adapters: different models need different context projections, and different runtimes may need different schemas. Sehgal’s illustrative sequence starts on Claude, continues on GPT, and finishes on Qwen. The representation changes at each boundary while the history supplies continuity.

This architecture sets a different standard for persistence than writing a transcript alongside execution. Sehgal characterizes Claude Code and Codex as writing local JSONL files, and Claude SDK writes as fire-and-forget: if a write fails, the corresponding history can be lost. These are his descriptions of the implementations discussed in the recording, not verified claims about every current version.

He also points to OpenCode’s local SQLite state and reports of corruption or data loss. The linked OpenCode issue narrows that concern to a user report involving concurrent local and Docker sessions sharing storage. That is a specific failure condition, not evidence that SQLite-backed sessions are generally unreliable.

For Durable Objects, his concern is history distributed across different shards, complicating reconstruction and queries across sessions. That is an application data-layout concern: per-object storage is documented as transactional and strongly consistent. Fragmentation depends on how the application distributes its history. The common design question is whether the system treats the log as authoritative session state or merely as something execution happens to leave behind.

Models can be swapped, and APIs or tools can be wrapped with adapters. The log is harder to replace because it contains the continuity accumulated through use. That makes log lock-in the deeper ownership concern: if a provider controls the only usable history, changing the model or machine does not free the agent from that provider. The replaceable components execute the work; the persistent record carries its value forward.

Sehgal names Claude Managed Agents and Google’s Managed Agents in the Gemini API as examples of providers moving further into the stack. Hosted loops, managed memory, sandboxes, compaction, and background execution put more of the agent’s operation inside a provider’s infrastructure.

A useful agent accumulates personal data, company data, workflows, and decisions. Its log becomes a record of all of them. Sehgal’s warning concerns control over that record when it lives under another organization’s policies and is queryable by its systems. His ownership language is an argument about architectural dependence, not an established claim about contractual ownership or export restrictions.

The architecture Sehgal describes for Omnara coordinates separate execution components around the session log:

1. A worker advances the loop by calling a model provider.
2. It records the model’s response in the log.
3. If the response requests tools, it dispatches them to the appropriate execution environment.
4. Tool completion adds results to the log.
5. A worker—potentially a different one—reconstructs the updated state and continues.

The worker is the executor, and tool execution can finish elsewhere. Neither needs to remain the permanent home of the session.

This separation addresses an ordinary failure landscape: workers crash, machines restart, sandboxes disappear, tool calls time out, providers fail, and users disconnect. Those events still interrupt execution, but they need not erase the agent’s recorded identity. Durable history lets the system distinguish losing an executor from losing the work’s continuity.

Sehgal closes by announcing an open-source managed-agent platform built around a session log users can own, inspect, and control. At recording time, availability was conditional: the managed-platform destination might have a release by publication, or it might still show a waitlist. The announcement describes the intended platform rather than a deployment walkthrough.

A model call, prompt, loop, or sandbox describes only part of an agent’s operation. The durable history connects those parts across time. Making that history primary brings recovery, compaction, branching, migration, collaboration, scaling, and ownership into the same architectural frame. As Omnara prepares to open-source the platform in the recording, the central commitment is to treat the log as the system itself, rather than as exhaust from a process that happened to run.