I was thinking through, what are the benefits of coding up your agent system via a pregel-like graph, instead of just doing function calls? Or versus the actor model? The execution trace of a (concurrent or serial) computer program is a graph. And the actor model lets you do message passing between "nodes/actors" without having to predeclare your graph structure.
The three reasons I can think of:
1. by predeclaring the structure, you can show debugging UI of the full graph, even if you've only executed part of it
2. Pregel can make it easier to reason about global state transitions (you can accomplish this in other systems too, if you set it up right)
3. by enforcing heavier structure on your program, you can ask the AI to reason about the whole graph or generate new graph parts
The downside is that this is an abnormal way of writing computer programs, originally designed for high-scale processing (Hadoop, Apache Spark, etc.). If you want to dynamically change the control flow of your program or special case control flow at various points, you'll wrestle against the up-front graph structure.
I personally have more of a preference to write normal-looking code, without having to predeclare my execution graph.
Pregel actually doesn't require the structure of the graph to be declared ahead of time, the next set of tasks (functions) to run is computed at the beginning of each step, so in theory the graph topology could be entirely dynamic. Langgraph supports dynamic topologies too, ie. don't declare any hard edges, add a conditional edge after every node
The value of using pregel is supporting cyclical graphs, with concurrent tasks, but completely deterministic behavior (eg. doesn't matter that task A this time happens to finish before task B, its results will be applied in a predetermined order, etc)
Yes, I originally thouoof building AI workflows with an existing DAG package or creating my own.
But I think DAGs don't scale, or rather, as you point out, it quickly becomes easier to reason about code than about a graph.
I thought, maybe a setup like pytorch that let's you code it normally and once you run it or compile it creates a graph for you to see. But I remain unconvinced.
I like the Pytorch comparison, and I've seen DSPy position themselves as Pytorch for prompting.
I also think the actor model is a natural fit for AI agents, which has some similarities with Pregel (message passing), and some differences (there are no super-steps of graph execution, each actor has its own thread).
I definitely dislike state machines for most use cases.[2] I think we can learn a lot about good AI agent paradigms from game programming, and I enjoyed this article on game state: https://gameprogrammingpatterns.com/state.html
At the end, they mention that game AI doesn’t often use state machines anymore, because the structure they impose is limiting.
Also, the folks behind Temporal are anti-state-machine:
[1]: our goal is to be an open-source alternative to the OpenAI Assistants API, not to compete with LangGraph, but there is overlap
[2]: I understand that LangGraph is not a state machine
Yea, I think it clicked with me when I saw the DSPy documentation that maybe that's a good balance between code-like and graph like, though I still find DSPy to be overly obfuscated.
We sort of realized this and just decided to use node async_hooks to track additional deeply nested context and print out state. No need for the rigidity and new stuff to learn about graphs.
The three reasons I can think of:
The downside is that this is an abnormal way of writing computer programs, originally designed for high-scale processing (Hadoop, Apache Spark, etc.). If you want to dynamically change the control flow of your program or special case control flow at various points, you'll wrestle against the up-front graph structure.I personally have more of a preference to write normal-looking code, without having to predeclare my execution graph.