That's mostly correct, one small correction is that cells don't have to be pure. They just have to focus on doing a single task with some hard boundaries. And

That's mostly correct, one small correction is that cells don't have to be pure. They just have to focus on doing a single task with some hard boundaries. And what I meant with the law of the graph was simply that the graph defines the actual business logic, and then each cell is a context free component that can be plugged into it. I guess I was just trying to be clever there. The key benefit I'm finding is that cells can be reasoned about in isolation because they know nothing about one another. You don't have implicit coupling happening the way you do in normal programs that's embedded in the call graph. My approach is to use inversion of control where the cell gets some context and resources like a db connection, does some work, and produces the result. That gets passed on to the graph layer which inspects the result, and decides what cell to call next. With this approach you can develop and tests these cells as if they were completely independent programs. The context stays bounded, and the agent doesn't need to know anything about the rest of the application when working on it. The cells also become reusable, since you arrange them like Lego pieces, and snap them together into different configurations as needed.