Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Log is the Agent

arxiv.org

Post reply on HN
Print view View original

21–30 of 59 posts

Re: The Log is the Agent

#21

Post by throw1234567891 »

lukebuehler wrote: post #5

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

pi harness does this by default, sessions go into session jsonl files, is it not how everyone is doing this?

Re: The Log is the Agent

#23

Post by lukebuehler »

throw1234567891 wrote: post #21
lukebuehler wrote: post #5

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

pi harness does this by default, sessions go into session jsonl files, is it not how everyone is doing this?

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.

Re: The Log is the Agent

#24

Post by MelonUsk »

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

Re: The Log is the Agent

#25

Post by politician »

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.

Re: The Log is the Agent

#27

Post by dofm »

ares623 wrote: post #10

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?

> 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. ;-)

Re: The Log is the Agent

#28

Post by gcr »

Very 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 angel syndicate btw! DM me if interested)

Post reply on HN