Very cool to see Pi build a durable agent harness too. I've been building in this space for quite some time myself [0][1] and it is a super interesting place of innovation. Less hype-y that on-your-machine coding agents, but all major players are building products in this space: LangChain Deep Agents, Vercel Eve, OpenAI Agents API, Anthropic Managed Agents, etc.
The main reasons are:
1) they are "durable", i.e. easier to make long-running in an unattended way, and easier to implement recovery, monitoring, etc
2) separating the harness from the compute brings safety and scaling benefits
It's quite an interesting place to hack on, because it's both a well understood problem but with so many wrinkles to it. I can't count how many earlier designs we chewed through before we ended up with the final one and I would not be surprised if we learn even more about it.
Yes, from your release post I can tell that you put a lot of thought into it!
I like your structured concurrency approach with tasks, which is similar to how I do it in Lightspeed too.
Also, the durable state implementation as documents is elegant! Question, though: why directly write/read to the store, why not abstract it and do more of a reducer/redux pattern and hide the persistence of the documents?
> why directly write/read to the store, why not abstract it and do more of a reducer/redux pattern and hide the persistence of the documents?
We tried so many things. At one point it pulls in so much more complexity. At one point we had half of automerge's proxy system in there. In the end we felt like this is a reasonable line to draw, but we will see!
Things are still not settled, and while the API looks like store i/o it's actually more similar to Immer's drafts, just with a different encoding, as JSON patch can't deal with the kinds of data we encounter in our workloads, at least not in a way that keeps memory and perf within some bounds.
The good thing is that this more low level API can be easily papered over with a nice sugary thing.
Brilliant. I wish the the durable application state wasn't restricted to just the json documents though. There should be some sort of integrated way of implementing the outbox pattern so external stores can be synchronized with the conversation state.
The main reasons are:
1) they are "durable", i.e. easier to make long-running in an unattended way, and easier to implement recovery, monitoring, etc
2) separating the harness from the compute brings safety and scaling benefits
3) easier to make multi-player.
[0] https://github.com/smartcomputer-ai/lightspeed
[1] https://github.com/smartcomputer-ai/agent-os/
I like your structured concurrency approach with tasks, which is similar to how I do it in Lightspeed too.
Also, the durable state implementation as documents is elegant! Question, though: why directly write/read to the store, why not abstract it and do more of a reducer/redux pattern and hide the persistence of the documents?
We tried so many things. At one point it pulls in so much more complexity. At one point we had half of automerge's proxy system in there. In the end we felt like this is a reasonable line to draw, but we will see!
The good thing is that this more low level API can be easily papered over with a nice sugary thing.
Woah, that big of a difference when it comes to token counting?