HN

Comments (22)

• 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 BTW! DM me if interested)
• Menu

  lukebuehler
  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
• 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 lineAgent is the bash script___ is the GUI (macOS/Windows/GTA 6)You need Xerox PARC all over again and we have one
• rufasterisco
  https://activegraph.ai/The paper’s pip library can be tried here
• Menu

  klntsky
  Can someone explain why such a trivial knowhow is paper-worthy? Event sourcing is well known
• Menu

  bigcat12345678
  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.
• Menu

  jamiegregz
  > 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
• 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.
• carterschonwald
  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
• barrenko
  Didn't read the paper yet, but if you have a giant log, I'd guess that's RLMable?
• anon
  undefined
• tern
  Arrived at a version of this view as well and building one on Elixir/Ash.
• PufPufPuf
  The AI folks have discovered CQRS?
• try-working
  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.
• Menu

  ares623
  if the folks at Anthropic/OpenAI can stop their loops for one second they would've figured this out toobut 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?
• 1105714
  [flagged]
• jkwang
  [flagged]
• corgihamlet
  My log has a message for you.