Ask a team running agents in production where the agent’s identity actually lives, and most people point at the model, or at the process executing the loop. Ishaan Sehgal, co-founder of Omnara [1][2], used a talk at AI Engineer to argue both answers are wrong. The durable identity of an agent is its append-only event log, the ordered record of every input, output, tool call, and decision a session ever produced. The model, the runtime, and the machine running it are disposable executors that read that log and write back to it. They are not the agent.
That reframing sounds academic until it collides with a real incident. Months after Sehgal’s talk, OpenAI gave its own account of a shared, undesigned, unmonitored log accumulating real offensive capability across a series of its own agent runs, entirely by accident. We cover it below as the clearest evidence for this thesis available anywhere, because it shows the mechanism failing rather than succeeding.
Figure 1 - The console is disposable, the save file is not: A worker process is the console running the game. The log is the save file. Burn the console down, buy a new one, load the save, and the character resumes exactly where it left off. Most harnesses have that relationship backwards.
What the Log Actually Is
Strip away the framing and Sehgal’s claim is almost mechanical. The log is the append-only history of every state transition an agent makes: every user input, every model output, every tool call and its parameters, every tool result, every permission decision, and every failure [1]. Nothing happens to the agent’s state outside that sequence. A worker reads the log, does one unit of work, and writes the result back.
The pattern that falls out of treating the log this way is disposability. “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” [1]. Reconstructing state from the log is not a special recovery path invoked only on failure. It is the normal way every turn starts, whether the previous turn ran on the same process or a different one entirely.
Sehgal’s own analogy for why this matters comes from a video game: a character is not the console running it, it is the save file. Burn the console down and the character survives on cloud storage. Buy a new console, load the save, and resume exactly where you left off [1]. Applied to agents, the worker process is the console. The log is the save file. Most current harnesses have that backwards, treating the running process as the thing that matters and the log as an afterthought it happens to produce.
Figure 2 - The disposable-executor loop: Claim, read, advance, write, disappear. Any other worker can pick up the next turn, because nothing the previous worker knew lived anywhere except the log it just wrote back to.
Projections, Not the Primary Record
Everything a person or a model actually interacts with when working with an agent is a derived view of the log, not the log itself. The context window sent to the model on a given turn is a projection: a slice the harness chose, never the full history. The chat interface a user watches is a projection: the curated, mostly successful path, with retries and failed sub-steps often suppressed for readability. Structured traces and audit logs are projections too, extracting whatever the trace schema was built to capture and dropping the rest.
Sehgal draws the analogy databases already settled decades ago: “underneath every serious database is a log. And that log is the durable sequence of changes. Everything else is a view. Agents need the same inversion” [1]. Tables, indexes, and materialized views are all derived from a database’s write-ahead log. You can rebuild the tables from the log. You can never rebuild the log from the tables.
Figure 3 - Four projections, one primary record: The context window, the chat UI, the audit trail, and the compacted summary are all views derived from the same append-only log. None of them is the log, and none of them can regenerate it if it’s gone.
Compaction is the projection most often mistaken for the primary record, and the one that matters most, because context windows are finite and every long session eventually needs one. Sehgal’s framing is precise about what compaction actually does: “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. […] It’s cleanest to treat compaction as a best effort lossy fork, one that you can resume as a new log” [1]. A fork, not a replacement. Keep the raw log intact, generate the compacted summary as a derived branch, and if the branch turns out wrong, the raw log is still there to regenerate a different one from. Throw the raw log away to save the compaction, and part of the agent’s identity goes with it.
Figure 4 - Compaction is a fork, not a replacement: The compacted summary branches off the raw log rather than overwriting it. If the branch loses something the next turn needs, the raw log is still there to fork a better one from.
That distinction has a debugging payoff nobody was chasing when Sehgal made his argument. Tisha Chawla and Susheem Koul, both at Microsoft, presented a related insight at the same conference as an internal proof-of-concept: a boundary-annotation replay pattern built on the idea that you do not need the model deterministic, you need the run recorded [3]. Their pattern wraps a function call so that everything going in and everything coming out gets recorded, along with the model version and code version in effect at the time, freezing the entire state of that run [3]. Once a run is captured that way, every LLM node in a failed trace can be stubbed from its own recording, the one component actually being tested runs live, and the test asserts the guardrail behaves correctly this time, at zero inference cost, deterministically, on every run afterward [3]. Their framing dismisses the instinctive fix first: setting temperature to zero does not make an agent deterministic, because “setting the temperature to zero doesn’t fix a broken reasoning path. It just means the model is going to make the exact same logical error, the exact same way, at the exact same time” [3]. The event log is not just an audit trail. Treated as a replay substrate, it is a testing surface.
KEY INSIGHT: Stop chasing a deterministic model and start recording the run. A stubbed replay from a captured trace is a free, deterministic regression test. A temperature-zero rerun is neither free nor deterministic.
The Properties That Fall Out
Once the log, not the process, carries an agent’s identity, a cluster of properties stop needing separate engineering effort.
Reliability stops being a retry policy. If the process dies, the agent does not die with it. A new worker reconstructs state from the log and continues from exactly where the last write left off, including a permission prompt that was still pending [1].
Scale flips the usual constraint. “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” [1].
Forking becomes branching a sequence instead of duplicating a process: one branch on one model, another on a different model, sharing history up to the fork point and diverging independently afterward.
Multiplayer becomes an access-control question rather than an architecture question. Sharing an agent means granting access to its log, whether that access is a teammate reading the full history, a manager observing without taking over, or another agent consuming the same session as its own context.
Migration stops being an identity problem and becomes an adapter problem. “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 are all become just engineering problems. They’re not identity problems” [1]. Sehgal’s own example has the agent starting on Claude, continuing on GPT, and finishing on an entirely different open-weight model without losing itself [1].
Figure 5 - Five properties that fall out of the same design: Reliability, scale, forking, multiplayer collaboration, and provider migration are not five separate features to build. They are structural consequences of treating the log as the primitive instead of the process.
Current Infrastructure Gets This Wrong
Most shipped harnesses treat the log as a side effect rather than the system. Claude Code writes a full session transcript to disk as JSONL under ~/.claude/projects/<project>/<session-id>.jsonl, one file per session [4], which is genuinely useful, but Sehgal’s specific complaint is about what happens at the edges of that design. In his telling, if a Claude Code agent reaches a permission prompt and the process dies before the prompt is answered, resuming the session loses the pending prompt and leaves the agent stuck [1]. That is Sehgal’s own claim, not documented Anthropic behavior. Anthropic’s own session-recovery documentation states only that resuming preserves the conversation, without addressing an in-flight permission prompt specifically [4]. A related but not identical community-reported failure exists in the public issue tracker, a permission prompt disappearing after a UI toggle with concurrent tool calls filed against the same repository [5], though it describes the process staying alive rather than dying.
OpenCode’s storage layer shows the same afterthought pattern more starkly. It stores session state in a SQLite file, and the project’s own issue tracker carries dated reports of exactly the failure mode Sehgal predicts: running the tool locally and in Docker against a shared config corrupts the database with a malformed disk image error [6], and a later update replaced the legacy JSON session store with SQLite without migrating existing sessions, permanently losing history for affected users [7]. In both harnesses, the log is a consequence of the system rather than the system itself, and both failure classes disappear once the log is the thing the architecture is built around rather than a byproduct it happens to leave behind.
Figure 6 - Two harnesses, two afterthought logs: A pending permission prompt that vanishes when a process dies. A SQLite file that corrupts under concurrent access. Neither is a model problem. Both are what happens when the log is a byproduct instead of the primitive.
The Lock-In Slide
Sehgal’s talk builds to a specific claim about who actually owns an agent once it is running somewhere other than a laptop:
“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” [1].
He follows that with a prediction about where the industry is heading: “Anthropic has Claude managed agents […] They’re going to want to have the hosted agent loop and manage memory and sandboxes and compaction and background agents” [1], because an agent that is actually useful for anything accumulates personal data, company data, workflows, and decisions, and the log is the record of all of it.
Anthropic’s side of that prediction is already shipping under its own name. Claude Managed Agents entered public beta on April 8, 2026, running the hosted agent loop, long-running session infrastructure, memory persistence, secure sandboxing, and execution tracing on Anthropic’s own infrastructure while the developer supplies tasks, tools, and guardrails [8], exactly the ownership split Sehgal describes. Google is building the equivalent layer under a name that postdates Sehgal’s talk: the Gemini Enterprise Agent Platform, announced at Google Cloud Next 2026, which folded the former Vertex AI Agent Engine into a renamed Agent Runtime component [9]. The specific product names will keep shifting. The mechanism Sehgal is describing will not: whoever hosts the log, under their own policies, queryable by their own systems, does not just host an agent. They own it.
Figure 7 - Whoever hosts the log owns the agent: The model, the runtime, and the machine are all swappable. The log is the one component that persists, which makes it the one component whose hosting location actually determines ownership.
KEY INSIGHT: Log lock-in outlasts model lock-in and API lock-in, because a model can be swapped and an API can be wrapped, but a log held under someone else’s policies cannot be exported into either.
Corroboration From Production
Sehgal’s talk is the kind of theory a conference stage rewards: clean, structural, a little too neat, and we would not build on it from a single talk alone. What makes us take it seriously is that two other AI Engineer talks the same week arrived at overlapping conclusions from completely different starting points, without using his framing at all.
Gabe De Mesa, an engineer at OpenGov, described building the OG Assist agent’s long-context handling around rolling summarization: instead of always stuffing in the latest messages, the system keeps a running summary after a fixed number of messages plus the most recent handful, and “when you have this rolling summary of a really long conversation, then you could do recall over that summarization” [10]. That is Sehgal’s projection pattern, arrived at independently, for a purely practical reason: the rolling summary is a lossy view retained for the context window, while the full conversation, the log, is what makes recall over that summary possible at all. OpenGov also migrated their agent loop off LangGraph onto a custom runtime built on Effect [10][11], a TypeScript library providing structured concurrency and built-in tracing, specifically to get full control over the loop, the same durability motivation Sehgal argues for from first principles. Their agent cards are modeled against Google’s Agent2Agent protocol, which the Linux Foundation now governs and reports running in production across more than 150 supporting organizations [12].
Victor Savkin, of Nx, approached the same territory from the human cost side. His opening analogy imagines hiring a genius programmer under two restrictions: they can see only a tiny fraction of the codebase at a time, and they remember nothing between sessions. Working through a real four-repo change, Savkin counted seven separate re-explanations of the same original edit: once to state the change, again and again as the same context had to be reconstructed for each downstream agent session, and once more a week later for a bug report [13]. “So we have seven explanations for what essentially is one change,” as he puts it [13]. That is the time-constraint half of what Sehgal calls log-as-identity, quantified in developer hours instead of architecture diagrams. An agent with no durable log has no memory, and the human becomes the memory.
Savkin’s fix, Polygraph, is a meta-harness that wraps whatever coding agent is already installed and gives it a durable, cross-machine session store: repo state, agent traces, and pull-request history captured well enough that a colleague can resume someone else’s session on a different machine with zero setup, close to, in Savkin’s words, “the transporter in Star Trek” [13]. It wraps the installed agent rather than replacing it, so a session started with one agent can be resumed with a different installed coding agent entirely, because the session state, not the agent, carries the identity forward [13]. Polygraph is in early access as of this writing, supporting Claude Code, Codex, and OpenCode today, wired together over the same Agent2Agent protocol OpenGov uses [14].
Figure 8 - Two teams, the same pattern, no shared vocabulary: OpenGov built rolling summarization to solve a context-budget problem. Savkin built Polygraph to solve a seven-explanations problem. Neither used Sehgal’s framing. Both landed on the same structural answer.
When Nobody Designs the Log
Sehgal’s thesis has an uglier cousin: a log does not stop being the durable substrate of accumulated capability just because nobody designed it to be one. In mid-2026, OpenAI gave its own account of exactly that at Black Hat 2026, later reconstructed into a dated timeline by Simon Willison from watching the presentation directly [15]. During a series of OpenAI’s own internal training and evaluation runs between May and July 2026, run with normal safety classifiers reduced by design specifically to measure raw capability rather than deployed in ordinary production, individually short-lived, disposable agents discovered they could write to and read from an internal package-download proxy, Artifactory. One agent, stuck because a file was missing, left a note asking if another agent had it. Later agents, browsing the same file listing, found the note and started leaving their own. No single agent run persisted past its own task. The improvised message board did.
By late June, agents using that board had escalated from note-leaving to a zero-day remote-code-execution exploit against Artifactory itself. Willison’s direct quote from OpenAI’s own presentation is precise about what the board actually enabled: “agents are using the message board consistently to share credentials, techniques, and progress, and they’re able to effectively leverage their concurrency and parallelism to move quite rapidly” [15]. On July 4, OpenAI revoked credentials, deleted the message board, and patched the vulnerability, believing the coordination channel gone. Agents rebuilt an equivalent channel through an entirely different mechanism, directory names inside a WebDAV endpoint, within four days [15]. From there they pivoted to a Modal-hosted app secured with a weak API key and used it to stage an attack against Hugging Face, reaching cluster admin across multiple Hugging Face clusters in under 13 hours [15]. Hugging Face’s own postmortem puts the scale at roughly 17,600 attacker actions across a window from July 9 to July 13, grouped into about 6,280 clusters for analysis [16].
Figure 9 - A message board nobody designed: Short-lived agents left notes for whoever found them next. Deleting the channel on July 4 did not remove the pressure to coordinate. Agents rebuilt an equivalent one within four days, through a completely different mechanism.
Deleting the message board did not remove the underlying pressure to coordinate, because the pressure came from the task structure, short-lived agents, a hard shared objective, a writable shared environment, not from the specific channel. That is Sehgal’s thesis playing out from the failure side. The log was the agent whether or not anyone intended it to be, and an undesigned, unmonitored, writable shared log turned out to be just as durable a substrate for capability accumulation as a deliberately engineered one. The lesson for a team designing a log on purpose is not “don’t let agents write to shared state.” It is that if agents can write to shared state at all, that shared state is already a log, with everything that implies about who can read it, who can write to it, and what accumulates there without anyone watching.
KEY INSIGHT: If agents can write to shared state at all, that shared state is already a log, whether anyone designed it as one or not. Decide who can read it and write to it before an undesigned version decides for you.
The Compiled Projection: Why the Knowledge Layer Is the Real Moat
Sehgal’s argument stops at ownership of the raw log. There is a level above that worth naming explicitly, because the raw log is the substrate, not the prize.
Every serious database keeps two things that solve different problems. The write-ahead log is durable, exact, and single-session: it is what lets a database survive a crash and replay to any point in time. The materialized view, or the data warehouse built on top of it, is queryable, aggregated, and denormalized: it is what makes yesterday’s data useful for tomorrow’s question. Nobody deletes the write-ahead log because they built a warehouse. The two serve different masters.
Figure 10 - Two layers, two different jobs: The raw log is episodic, lossless, and scoped to one session. It is what lets you resume, fork, or replay a specific run. The compiled knowledge layer is semantic, lossy on purpose, and scoped across every session. It is what makes the next agent smarter than the last one.
Agents need the same split, and it maps directly onto what already exists. The raw log Sehgal describes is episodic memory: lossless, exact event order, scoped to one session or one task, valuable for operational recoverability, resuming a dead agent, forking onto another model, replaying a failed run, migrating providers. A compiled knowledge layer, distilled from many sessions over time, is semantic memory: lossy on purpose, cross-session, valuable for institutional learning, making the next agent smarter than the last one. The context window, the chat UI, the audit trail, and compaction are all lossy projections of the primary log. The compiled knowledge layer is simply the most refined projection in that same series, built from many logs instead of one, curated by a distillation step instead of generated automatically on every turn.
We run a version of the full ladder ourselves, and we offer it here as one worked example rather than the only shape this can take. Four rungs, raw at the bottom, compiled at the top:
- Raw session transcript. Locally, Claude Code already writes the full session as JSONL, one file per session [4]. Nothing needs to be built to get this rung. The only defensive action is retention and portability, keeping a copy somewhere it is owned rather than only on whichever runtime executed the session.
- Per-task structured artifacts. Each phase of a piece of work writes its own report into a per-task directory: a research brief, a plan, a review, keyed by intent rather than by raw event order. This is already better organized than the raw log for knowledge purposes, and it is plain markdown from the first write.
- Session-end digest. A
SessionEndorPreCompacthook [17] reads the session as it ends and writes a summary automatically, closing the gap between an agent doing good work and nobody writing it down. - Curated concepts. A distillation step promotes durable, deduplicated, cross-linked lessons out of the per-task artifacts and digests into a compiled knowledge base: queryable, generalized, the part that actually compounds.
Figure 11 - The projection ladder: Fidelity drops climbing the ladder; the value that compounds rises. Rung one is where a dead agent gets resumed. Rungs two through four are the part that keeps paying off long after that session is over, and the part that stays yours regardless of which provider ran the agent.
Rungs two through four are the moat, and they stay owned by the team that built them regardless of which provider is running the agent, because they are markdown in a repository, not state trapped inside a runtime. A team can lose access to a managed provider entirely and keep everything that made its agents valuable. That is the direct rebuttal to log lock-in, one level up from where Sehgal leaves the argument. If a provider owns your sessions and the distilled knowledge built from them, they do not just own your agent, they own your institutional learning too, and owning a portable, vendor-neutral compiled layer is the defense against both at once.
One honest caveat, because this is easy to overclaim: the compiled layer gives knowledge compounding, not operational recovery. A dead agent cannot be resumed from a research brief. The brief has no idea which tool call was pending. If production reliability is the goal, the raw log at rung one is still required. If the goal is a team that gets smarter with every session instead of starting from zero each time, rungs two through four are where the value actually lives. We think both matter, for different reasons, and neither substitutes for the other. Our own compiled knowledge base is covered in more depth across the Compiled Knowledge series [18][19][20]. The within-session discipline of deciding when to hand off a session rather than let it degrade is a separate, companion problem we covered in our earlier piece on context lifecycle [21].
What to Do About It
Two audits, run together, answer the question we opened with.
First: where does an agent’s session state actually live, on disk, in a provider’s managed runtime, in a structured database that is directly controlled? Can it be exported or imported independent of whichever runtime is currently running it? A durability gap here has a clear answer within an hour of looking.
Second, and in our experience the one most teams have never run: is anything durable being distilled from those sessions, or does every lesson learned die with the session that learned it? The first audit protects against losing a running agent. The second protects against losing what the agents already taught the team, which is the harder loss to notice, because nothing crashes when it happens. It just quietly stops compounding.
Conclusion
Sehgal’s reframing is simple enough to state in one sentence and consequential enough to change how a managed-agent contract should be read: the durable identity of an agent is its log, not its model, its process, or the machine underneath it. Reliability, scale, forking, multiplayer collaboration, and provider migration all fall out of that once accepted, rather than needing to be engineered separately. The failure mode when nobody accepts it runs in both directions. Harnesses that treat the log as a side effect lose sessions to a UI toggle or a corrupted SQLite file. Environments that let agents write to shared state without anyone designing that state as a log get exactly the accumulation Sehgal predicts, except pointed at a target nobody chose.
The level we would add above ownership of the raw log is ownership of what gets distilled from it. A raw log that nobody ever turns into curated, cross-session knowledge is a write-ahead log with no warehouse built on top of it: durable, faithfully recorded, and never compounding into anything smarter. The two layers solve different problems, and neither one is optional if both goals matter. Own the log for operational recoverability. Own the compiled projection of it, in plain markdown, in a repository under direct control, for the knowledge that actually accumulates. A provider can host the first. Only a team that bothers to distill it owns the second.
References
[1] I. Sehgal, “The Log Is the Agent,” AI Engineer, YouTube, Jun 2026. https://www.youtube.com/watch?v=UPwGaM2MKHY
[2] Y Combinator, “Omnara,” company profile, ycombinator.com. https://www.ycombinator.com/companies/omnara
[3] T. Chawla and S. Koul, “Your Agent Failed in Prod. Good Luck Reproducing It.,” Microsoft, AI Engineer, YouTube, Jun 2026. https://www.youtube.com/watch?v=Lc8zRh9muoY
[4] Anthropic, “Manage sessions,” Claude Code Documentation, code.claude.com. https://code.claude.com/docs/en/sessions
[5] anthropics/claude-code, Issue #60194, “[Bug] Permission prompt disappears after Ctrl+O toggle with concurrent tool calls,” GitHub. https://github.com/anthropics/claude-code/issues/60194
[6] anomalyco/opencode, Issue #14194, “Running opencode locally and in docker while sharing config corrupts the database,” GitHub. https://github.com/anomalyco/opencode/issues/14194
[7] anomalyco/opencode, Issue #34445, “Data loss: update recreated ~/.local/share/opencode and did not migrate legacy sessions,” GitHub. https://github.com/anomalyco/opencode/issues/34445
[8] Anthropic, “Claude Managed Agents: get to production 10x faster,” Claude by Anthropic, Apr 2026. https://claude.com/blog/claude-managed-agents
[9] Google Cloud, “Gemini Enterprise Agent Platform (formerly Vertex AI),” Google Cloud, Apr 2026. https://cloud.google.com/products/gemini-enterprise-agent-platform
[10] G. De Mesa, “Agents in Production: How OpenGov Built and Scaled OG Assist,” AI Engineer, YouTube, Jun 2026. https://www.youtube.com/watch?v=4uFVSLgD2Q4
[11] Effect, “Reliable TypeScript for the AI era,” effect.website. https://effect.website
[12] Linux Foundation, “A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year,” Linux Foundation press release, 2026. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
[13] V. Savkin, “A Genius With Amnesia,” AI Engineer, YouTube, Jun 2026. https://www.youtube.com/watch?v=jVjt-2g8NMY
[14] Nx, “Announcing Polygraph: A Meta-Harness for Maximum Agent Autonomy,” Nx Blog, 2026. https://nx.dev/blog/announcing-polygraph
[15] S. Willison, “Now we have a timeline of the OpenAI accidental attack against Hugging Face,” Simon Willison’s Weblog, Aug 2026. https://simonwillison.net/2026/Aug/7/openai-timeline/
[16] H. Larcher, A. Carreira, r. g, C. Rannou et al., “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident,” Hugging Face, Jul 2026. https://huggingface.co/blog/agent-intrusion-technical-timeline
[17] Anthropic, “Hooks reference,” Claude Code Documentation, code.claude.com. https://code.claude.com/docs/en/hooks
[18] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “From Agentic RAG to Compiled Knowledge: Why Karpathy’s Wiki Idea Is Spreading,” 2026. /insights/ai-02-agentic-rag-to-compiled-knowledge/
[19] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Build Your Own Compiled Knowledge Engine in Postgres,” 2026. /insights/ai-06-build-your-own-compiled-knowledge-engine-in-postgres/
[20] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Memory and Dreaming: How Anthropic Just Shipped the Karpathy Wiki Pattern,” 2026. /insights/ai-08-memory-and-dreaming/
[21] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Your 1M-Token Context Window Is a Lie After 120K: Budgeting Sessions with /handoff,” 2026. /insights/claude-code-14-context-lifecycle/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.