4 ms·

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

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.

dbmikus 2y ago
I've thought about the same things as we built our own open source project for LLM workflows (https://github.com/gofixpoint/fixpoint/).[1] https://github.com/gofixpoint/fixpoint/).[1] 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 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: https://pages.temporal.io/download-state-machines-simplified.html https://pages.temporal.io/download-state-machines-simplified... https://community.temporal.io/t/workflow-maintainability-abstract-into-a-state-machine-vs-standard-workflow-function/7220 https://community.temporal.io/t/workflow-maintainability-abs... [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
- huevosabio 2y ago
  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. I'll take a look at your repo!

dbmikus 2y ago

I've thought about the same things as we built our own open source project for LLM workflows (https://github.com/gofixpoint/fixpoint/).[1] https://github.com/gofixpoint/fixpoint/).[1] 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 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: https://pages.temporal.io/download-state-machines-simplified.html https://pages.temporal.io/download-state-machines-simplified... https://community.temporal.io/t/workflow-maintainability-abstract-into-a-state-machine-vs-standard-workflow-function/7220 https://community.temporal.io/t/workflow-maintainability-abs... [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

huevosabio 2y ago
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. I'll take a look at your repo!