Discussion summary
Discussion centered on AI logs, the efficiency of request-response loops, and the quality of submissions on Hacker News. Participants debated technical challenges, submission algorithms, and the potential of new AI papers.
What the discussion says
- Some believe logging and request handling are costly and complex.
- Concerns about submission algorithms and voting rings affecting content quality.
- Interest in new AI research and tools like BabyAGI and CQRS.
“if the folks at Anthropic/OpenAI can stop their loops for one second they would've figured this out too”
“The author is a VC and the BabyAGI author, and doesn't even have a valid ssl cert on their website”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > graph-memory research
The problem I have with graph representations relative to LLMs is that you can never directly apply the concept. Everything that speaks to an LLM must ultimately be serialized. There's no getting around the token stream semantics.
I've found that one big flat markdown file tends to outperform everything. You could certainly project an event log into a graph and then serialize that, but it starts to feel like a Rube Goldberg machine at this point. It's a lot easier if you just work with the same terms that the models do.
Remember if that big document rarely changes and everything that comes before it is also constant, you'll pay something like 10% of the normal rate with providers like OAI for the tokens in those documents. The clever schemes to piecemeal out information feel good to the ego and might appeal to accounting at first glance, but I think the bitter lesson will ultimately win out here. We already have a million token context windows. Even if 90% of that is bullshit it's still a lot of tokens to work with.
by bob1029 - > 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]
by jamiegregz - Can someone explain why such a trivial knowhow is paper-worthy? Event sourcing is well knownby klntsky
- https://activegraph.ai/
The paper’s pip library can be tried here
by rufasterisco - 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.
- 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.by politician
- 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
by lukebuehler - 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)
by gcr