Can someone explain why such a trivial knowhow is paper-worthy? Event sourcing is well known
[dead]
The Log is the Agent
31–40 of 59 posts
Re: The Log is the Agent
#32As 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.
Agree with your critique. I think this work is presenting common ideas as novel without thinking through existing problems. Defining a provider-agnostic event graph that enables full session branching replay was the whole point of pi: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/ , though the language around it perhaps didn’t click until a bit later. I don’t even think pi was the first to do this.
Another critique: the abstract mentions how their system allows for “branch[ing] a run at any event without re-executing the shared prefix,” but that’s only possible with very careful KV caching. Generally, rerunning inference from an earlier point still incurs O(n) input token cost and this paper is working at the wrong layer to see that. In this work, execution refers to tool calls but token generation is the expensive part.
Re: The Log is the Agent
#33Very cool work!! This is the same pattern we used at $MY_STARTUP to develop $MY_HARNESS which persists the entire graph to disk, unlike all the other agent harnesses which only store the graph nodes and edges. Event graphs aren’t just the agentic foundation for $MY_HARNESS — they’re the working cognitive substrate, native to what our favorite toolcall gremlins actually consume. (Looking for lead investors for our ang…
Did you just emdash not-just-X-it's-Y unironically or am I missing the satire?
Re: The Log is the Agent
#34Very cool work!! This is the same pattern we used at $MY_STARTUP to develop $MY_HARNESS which persists the entire graph to disk, unlike all the other agent harnesses which only store the graph nodes and edges. Event graphs aren’t just the agentic foundation for $MY_HARNESS — they’re the working cognitive substrate, native to what our favorite toolcall gremlins actually consume. (Looking for lead investors for our ang…
Did you just emdash not-just-X-it's-Y unironically or am I missing the satire?
I was at an AI event and the number of people who have started talking like AI output is crazy.
Re: The Log is the Agent
#35Very cool work!! This is the same pattern we used at $MY_STARTUP to develop $MY_HARNESS which persists the entire graph to disk, unlike all the other agent harnesses which only store the graph nodes and edges. Event graphs aren’t just the agentic foundation for $MY_HARNESS — they’re the working cognitive substrate, native to what our favorite toolcall gremlins actually consume. (Looking for lead investors for our ang…
Nice work! Excited to try $YOUR_HARNESS out!
Reading your comment reminded me; I actually did something quite similar at $MY_BETTER_STARTUP! My approach is slightly different, however, employing what I like to call State-Horizon-Aware-Rercursive-Threaded-Graph-Position-Topology.
With a 400% increase in words, $MY_WAY_BETTER_HARNESS looks to be about four times as performant. SHARTGPT isn’t just a harness engineer's playground — it's a the cyber jungle gym that frees them from $MY_HARNESS.
If you want, I can even include a sentence or two that will really tell those potential investors why they should shower you with money instead of the other commenter! Just say the word!
(Looking for lead investors for our angel syndicate btw! DM me if interested)
Re: The Log is the Agent
#36I think this can be safely ignored.
"...and how it extends the BabyAGI lineage and prior graph-memory research. "
From BabyAGI from two years ago: "This is a framework built by Yohei who has never held a job as a developer. The purpose of this repo is to share ideas and spark discussion and for experienced devs to play with. Not meant for production use. Use with cautioun."
Re: The Log is the Agent
#37Very 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
pi harness does this by default, sessions go into session jsonl files, is it not how everyone is doing this?
getting downvoted for my other answer. I wasn't clear: yes, there is of course a lot of prior art in pi, and pi specifically does not just store the session events, but adds an abstraction for easy branching which is great.
But what I tried to get at is the question what additional events you store to construct more than just the llm session log but also more fine grained events around the entire agent state, which of course depends on what you want out of your agent.
The paper here in question is going even further and is event sourcing a larger state than just the session transcript, specifically additional graph structures that are getting built as part of the session.
in my agent, specifically, I focus on the event sourcing all the stuff that makes an agent work well as part of a deterministic workflow, which again is prerequisite to run agents in durable workflow engines like Temporal.
I write more about my approach here: https://github.com/smartcomputer-ai/lightspeed/blob/main/doc...
Re: The Log is the Agent
#38Very cool work!! This is the same pattern we used at $MY_STARTUP to develop $MY_HARNESS which persists the entire graph to disk, unlike all the other agent harnesses which only store the graph nodes and edges. Event graphs aren’t just the agentic foundation for $MY_HARNESS — they’re the working cognitive substrate, native to what our favorite toolcall gremlins actually consume. (Looking for lead investors for our ang…
Did you just emdash not-just-X-it's-Y unironically or am I missing the satire?
Oh pardon, I’m trying to sarcastically complain how a lot of comments in this thread have a similar form: “I used this pattern in my own agent, which is different from (all the other agents which use the same representation)”
Agentic development tends to encourage siloed individualistic development, so a lot of engineers reinvent similar patterns from first principles. It’s easier to write your own new thing than survey other approaches, so you’re more likely to perceive good ideas as original to your session.
Re: The Log is the Agent
#39if 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?
The author is a VC and the BabyAGI author, and doesn't even have a valid ssl cert on their website...
Re: The Log is the Agent
#40Earlier quoted context omitted.
Did you just emdash not-just-X-it's-Y unironically or am I missing the satire?
I was at an AI event and the number of people who have started talking like AI output is crazy.
It’s insidious! I used Claude code at my last job enough for it to influence my writing and speaking style without me really noticing, even though I tried to be wary of that.