Hacker News Reader

Comment by huevosabio | Hacker News Reader

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.

View on HN

I've thought about the same things as we built our own open source project for LLM workflows (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

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...

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

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!

Reply on news.ycombinator.com