Reclassify the log from system exhaust to the agent itself, and reliability, scale and lock-in all come loose at once
The Log Is The Agent - Ishaan Sehgal, Omnara · Ishaan Sehgal
15 min total·Actually worth watching closely: ~3 min·2 must-watch clips
- 0:00 – 2:10Watch
Opening: where an agent's identity actually lives
Straight to the claim: most people think the agent is the model or the execution environment it runs in, and that's the wrong abstraction. What gives an agent its identity is its log — the append-only event history of user inputs, model outputs, tool calls, state transitions, all written down. Then the video-game save file turns that into common sense.
As long as that history survives, the agent comes back exactly as it was on any new machine — identity lives in the data, not in the compute.
The save-file stretch has a visual putting the console, the controller and the save file side by side; one glance is enough, whereas audio alone takes the long way round.▶ Jump to 0:00Speaker · Ishaan Sehgal - 2:10 – 5:00Listen
Databases already walked this road
Databases as precedent: for years they looked like opaque systems full of tables and indexes and materialized views, but underneath every serious one is a log — the durable sequence of changes — and everything else is a view. He borrows an architecture that's been proven for decades to show that putting history at the center isn't a new idea, it just hasn't been carried into agents yet.
Tables and indexes are views, the history is the thing itself — a proven layering that transfers wholesale to agents.
Pure analogy; the screen barely moves off the title, so you can listen through this one while doing something else.▶ Jump to 2:10Speaker · Ishaan Sehgal - 5:00 – 7:00Listen
Context, UI and auditing are all projections
Following on: the context fed to the model, the UI rendered for humans, debugging and traceability, auditing, and the compacted summary are all different views projected from the same history. The weight lands on compaction — it's lossy, and a summary is not the state itself.
Throw away the raw history and keep only the compaction and you've effectively lost part of the agent; keep the original and you can always generate new projections from it.
All verbal reasoning, nothing to look at — but pay attention to the compaction point, because plenty of people are walking straight into it.▶ Jump to 5:00Speaker · Ishaan Sehgal - 7:00 – 9:20Listen
The execution process becomes disposable
First dividend: once the history is authoritative, the process running the loop is cheap. It claims a session, reads the log, advances the agent one step, writes the result, and can then completely disappear — any other worker picks it up later. One process can now advance thousands of agents, failover becomes trivial, and scaling is just a matter of adding more workers.
Demote the executor to a disposable worker and reliability and scalability stop having to be designed separately — no sticky sessions, no state migration.
Dense with conclusions but all spoken, with no diagram to lean on — worth following this causal chain closely.▶ Jump to 7:00Speaker · Ishaan Sehgal - 9:20 – 11:40Listen
A symptom list for today's tools
The counter-evidence: most agent harnesses today treat the log as an afterthought, and the symptoms are everywhere — Claude Code's permission prompt is gone when you resume after the process dies, SDK-mode writes to those messy JSONL files are fire and forget, and OpenCode's SQLite state has a pile of GitHub issues about corruption and data loss.
These aren't independent bugs, they're the shared consequence of one architectural decision — change the premise and they disappear together.
Specific products and specific failures get named; catching the names is enough, and if you're using one of them this stretch is worth rewinding.▶ Jump to 9:20Speaker · Ishaan Sehgal - 11:40 – 13:10Listen
Forking, switching models, and working together
Second dividend: the history can be forked, so one starting point branches into lines handed to different models trying different strategies; and switching providers drops from "is my agent still my agent" to writing an adapter and lining up schemas — start on Claude, continue on GPT, finish on Qwen without losing yourself. Collaboration, meanwhile, should mean handing out access, not pasting a transcript into a group chat.
A colleague can open the session and view and edit it, a manager can observe without taking over, another agent can consume the same session as context — the value isn't just the output, it's that how it got there was recorded.
Three scenarios back to back with no visuals keeping up, but if you work on multi-agent collaboration the collaboration model here is worth more than the technical detail.▶ Jump to 11:40Speaker · Ishaan Sehgal - 13:10 – 14:02Watch
The real architecture, and the deepest lock-in
First the way Omnara actually splits it: the worker, the model provider call and the tool execution environment as separate components all coordinated around the central log, with state reconstructed rather than kept resident in a process. Then the sharpest line in the talk — what really locks you in was never the model or the API.
The model is replaceable, the runtime is replaceable, the machine is replaceable; the log is the thing that persists and the valuable part — whoever holds it doesn't just host your agent, they own it.
This is the one diagram in the talk that lays out how the pieces orbit the log; audio alone misses the flow between components, and the lock-in line only carries its weight alongside the picture.▶ Jump to 13:10Speaker · Ishaan Sehgal - 14:02 – 15:09Listen
Closing: stop treating it as exhaust
Down to one position: an agent is not just a model call, a prompt, a loop or a sandbox — it's the durable history of the work being done, and that history is the log. Stop treating the log as exhaust from the system and treat it as the system itself. Every dividend above is just a consequence of that premise.
What changes isn't a module, it's your definition of what an agent is — see it this way and reliability, compaction, forking, migration, multiplayer, ownership and scalability all fall into place.
A minute-plus of closing statement with no new information and nothing on screen, but this is the line worth repeating to your team verbatim afterwards.▶ Jump to 14:02Speaker · Ishaan Sehgal