# The Log Is The Agent Ishaan Sehgal, Omnara | AI Engineer World's Fair 2026 | 15:11 Source: https://www.youtube.com/watch?v=UPwGaM2MKHY Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/the-log-is-the-agent Published: 2026-06-25 Tags: long-context, memory, reliability ## TL;DR - An agent's identity and state live in its append-only session log, while models, tools, and workers read from it and append new events. - Keeping the raw log lets systems resume after crashes, switch workers or models, fork sessions, share access, and migrate between providers. - The log is also the main ownership boundary, so giving a provider control of it can give that provider control of the agent. ## Summary Ishaan Sehgal argues that an agent should be understood as its durable session log rather than its model, runtime, tools, or worker process. The log records inputs, outputs, tool calls, results, permissions, failures, and other state transitions. Workers reconstruct state from it, advance the agent, append new events, and can then disappear. This design lets another worker resume the session after a crash. Sehgal applies the same idea to compaction, forking, multiplayer access, migration, and scaling. A compacted context is only a lossy projection, so the raw log must be retained. External systems still hold world state, but the log records the agent's view of that world. He also argues that log ownership is a deeper form of lock-in than model or tool ownership. Omnara's managed agents platform is built around user-owned, inspectable session logs. ## Key ideas ### The agent's identity lives in its save file [00:17](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=17s) Sehgal compares an agent with a Skyrim character. The character is not the game engine, PlayStation, or controller. It is the save file, which preserves identity, history, and current state. If the console breaks, a new console can download the save file and resume the character where it stopped. Sehgal says agents should be understood in the same way. The model and runtime interact with the agent, but the agent itself is the data that can be carried across machines and execution environments. ### The session log records every state transition [01:24](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=84s) The log is an append-only event history. It contains user inputs, model outputs, tool calls, tool results, permissions, failures, and each state transition the agent takes. The model reads the log and proposes the next action. A tool runner executes that action and appends the result. Because the system coordinates around this shared history, the log alone is enough to reconstruct and resume the agent. ### Workers are disposable interpreters of the log [03:07](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=187s) A worker can claim a session, read its log, advance the agent one step, write the result, and disappear. Another worker can later repeat the process. Sehgal connects this design to how databases use an append-only log beneath tables, indexes, and materialized views. For agents, context, user interfaces, debugging, auditing, and compaction should all be projections of the durable log. The execution loop is replaceable, while the history persists. ### Compaction must not replace the raw history [04:31](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=271s) Model context windows are finite, so an agent eventually needs a smaller representation of its history. Sehgal says compaction is lossy and cannot reproduce the full agent state perfectly. It should be treated as a projection, or as a best-effort fork that can continue as a new log. The original log must remain available. If only the compacted summary is kept, part of the agent has been discarded and new projections can no longer be generated from the complete record. ### The log stores the agent's view, not the whole external world [05:32](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=332s) Tools can change state outside the log by editing files, creating GitHub issues, or sending email. Sehgal accepts that the log cannot make the external world deterministic. Forking a session will not unsend an email, and the agent may not know about a file changed elsewhere. The log has a narrower job: record what the agent did, what it saw, what changed, and what it needs in order to continue. It preserves the agent's identity and view of the world. ### A durable log lets agents survive failure and scale [06:53](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=413s) If a process dies while an agent is waiting for permission, a log-centered system preserves that prompt for the next worker. The executor can fail without killing the agent. Sehgal also says one process can advance thousands of agents because each session reconstructs its state from its own log. Agents do not need to stay tied to one machine or worker, so failover and scaling become simpler without sticky sessions or state migration. ### Forking, sharing, and migration become log operations [08:16](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=496s) A session can branch at a point in its history and run different strategies on Claude, GPT, or an open-source model. Sharing an agent means granting access to its history, so a teammate can view or edit it, a manager can observe it, or another agent can use it as context. Migration also becomes an adapter problem. Models and runtimes may require different projections or schemas, but the agent's identity remains in the portable log. ### Log ownership is deeper than model lock-in [11:09](https://www.youtube.com/watch?v=UPwGaM2MKHY&t=669s) Sehgal argues that models, APIs, tools, runtimes, and machines can be replaced or adapted. The durable log is what persists, so a provider that owns it effectively owns the agent. Managed providers may host the loop, memory, sandboxes, compaction, and background agents, while also holding personal data, company data, workflows, and decisions. Omnara's proposed platform therefore centers on a session log that users can own, inspect, and control. ## Notable quotes - "The agent is data. It's the save file." (00:39) - "The important insight is that the loop is disposable." (03:07) - "If you throw away the raw log and keep only the compaction, you've effectively lost part of the agent." (05:13) - "The deepest form of lock-in is actually log lock-in." (11:29) - "The agent is the durable history of the work being done, and that history is the log." (14:19) ## Tools & references mentioned - Skyrim - Elden Ring - Martin Kleppmann - Claude - GPT - Claude Code - Codex - Open Code - SQLite - GitHub - Anthropic - Google - Gemini - Omnara ## Who should watch - You are building agents that need to resume after worker, machine, sandbox, or provider failures. - Your system depends on long-lived sessions, model switching, branching, shared access, or migration between runtimes. - You are deciding who should own agent history and whether a provider-controlled memory format creates lock-in.