The Log is the Agent
75 points by iacguy 12 hours ago | 21 comments

lukebuehler 7 hours ago
Very cool. I settled on the same/similar design in my agent harness.

All relevant events that affect the context window are stored in an event log. Forking agents and sessions is simply setting a pointer to the sequence number of another event log.

So if you want to check an implementation of this pattern see: https://github.com/smartcomputer-ai/lightspeed

reply
throw1234567891 3 hours ago
pi harness does this by default, sessions go into session jsonl files, is it not how everyone is doing this?
reply
lukebuehler 2 hours ago
most coding harnesses store the exact messages that have been sent to the llm and the messages items that have come back from the llm, not much else. Then, there is also a set of events/commands/etc that are in-memory only. Together they constitute the current state of the agent loop.

In Lightspeed, we store all of them as events, thus can always reconstruct the exact state of the loop (e.g. state of open tool calls, compaction decisions in-flight, etc). This makes it possible to run the agent in a durable workflow engine easily.

reply
tern 4 hours ago
Nice work. Excited to check this out.
reply
MelonUsk 2 hours ago
Current text-based LLMs are the same old story - text-based vs graphical UIs that ate them whole for most of humanity:

Chatbot is the command line

Agent is the bash script

___ is the GUI (macOS/Windows/GTA 6)

You need Xerox PARC all over again and we have one

reply
rufasterisco 7 hours ago
https://activegraph.ai/

The paper’s pip library can be tried here

reply
klntsky 6 hours ago
Can someone explain why such a trivial knowhow is paper-worthy? Event sourcing is well known
reply
bigcat12345678 8 hours ago
This is true after learning this framing.

It's more like the log is the only user/agent accepted consensus. It has to be the grounding base. Although extending it into an agentic system architecture becomes something not necessarily effective in practice.

reply
lmwnshn 7 hours ago
With my database hat on, in the context of agentic systems I would argue that write-ahead logs form a good (and potentially transactional) interface between speculative agent work and durable world mutations [0].

That said, there are a _lot_ of "logs for agents" papers that I've read (and unfortunately gotten assigned to review) which are basically "we asked claude to hack on a graph DB and generate a paper".

[0] https://onewill.ai/blog/2026/stealing-50-years-of-database-i...

reply
try-working 3 hours ago
We should probably only interact with the agent by writing to the log, which it executes from, and the agent should probably only interact with the external environment by writing and executing code. That fixes a lot of issues with non-determinism.
reply
jamiegregz 7 hours ago
> In this arrangement the log is a byproduct: an audit artifact written alongside the real computation, never the substrate of it.

I’ve come to the same conclusion building my own agents. It simply feels ‘wrong’ that most frameworks will happily mutate your context. You have to explicitly go out of your way to store the original events. I’ve now started storing an event log for my own agents, this is used as the source of truth for deriving all subsequent context.

The great thing about this is that I have finer control over drift in long runs, as I can look back through the conversation/tool history and build context suitable for the current state of the agent. It also allows me to run compactions across the entire event history instead of ‘compactions on top of compactions’ which happens on long runs with checkpoints.

It definitely feels like this will be a bigger issue going forward as we have agents running longer and more complex workflows, I’ve started building a product aimed at addressing this issue in a framework agnostic way. [0]

[0]: https://statefabric.dev

reply
spike021 6 hours ago
Why not save progress and important results of a conversation (i.e. including tool calls and such) to a project markdown (even multiple as needed) and clear your context window completely rather than compacting many times? You can then just specify a markdown file to be included as context. Especially if following any kind of plan document and executing on a part of it.
reply
jamiegregz 6 hours ago
[dead]
reply
politician 31 minutes ago
As others have commented, this is an obvious application of event sourcing. It's irritating to see the claim of "deterministic replay" in the abstract along with the caveat "we can't actually do deterministic replay, so we store all of the model's responses and reproject off of that". Sure, ok, whatever. You're doing session recording and calling it replay.
reply
carterschonwald 5 hours ago
This paper points at an idea, but its really only legible if you have a more developed version of the idea already. I really should write more
reply
barrenko 4 hours ago
Didn't read the paper yet, but if you have a giant log, I'd guess that's RLMable?
reply
tern 7 hours ago
Arrived at a version of this view as well and building one on Elixir/Ash.
reply
PufPufPuf 3 hours ago
The AI folks have discovered CQRS?
reply
try-working 5 hours ago
This is one of the most interesting papers I've seen. Someone said it's AI slop, well I sent it to 5.5 Pro and it was a great read.
reply
ares623 6 hours ago
if the folks at Anthropic/OpenAI can stop their loops for one second they would've figured this out too

but wouldn't feeding that log for each request/response iteration must get expensive really fast no?

also "We discuss--without claiming to demonstrate--" wtf? someone had a showerthought and slopped this out in 10mins to see what others thought?

reply
dofm 60 seconds ago
> someone had a showerthought and slopped this out in 10mins to see what others thought?

The window on back-of-napkin-idea acquihires is closing fast. ;-)

reply
1105714 20 minutes ago
[flagged]
reply
jkwang 7 hours ago
[flagged]
reply
corgihamlet 8 hours ago
My log has a message for you.
reply