jamiegregz

We’re working on this problem at my company. All of our competitors have churned out a bunch of generic chat based agents (basic harness with a few tools connected and different system prompts) to do basic stuff you’d used to do from a wizard or even just a couple of buttons in a form. We’re steering away from this by building full ‘surface’ agents with A2UI and an initial surface message. The users just see a normal looking web application but under the hood it’s all driven by a harness. UI updates are effectively just new events received by the client. Events are either generated by an LLM directly, or deterministically - it’s up to the dev.

> 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