Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree complex conditional LangGraph setups get pretty tedious after a certain point - though you claim to not use graphs here, but isn't that essentially what returning the "next task" does? The graph isn't explicitly defined but it still exists implicitly if you trace through all the tasks and next tasks.

Would be interesting to see a complex agent implementation in both Flow and regular LangGraph to compare maintainability.



In some sense yes, task dependencies do form a graph. However, what I meant when I was saying that graph is a wrong abstraction, is that predefined edges is a not the best of writing code when dealing with dynamic systems such as AI Agents.

As you said, the easiest conditional workflows are tedious and we have to rely on "conditional" edges to solve the simplest stuff. Then, how would you define cycles or spawning of the same task multiple times as a node-edge relation? It becomes extremely inconvenient and just gets in your way. The reason I built Flow is exactly because I previously relied on a predefined node-edge system which I also built (https://docs.lmnr.ai/pipeline/introduction).

Also it impossible to do MapReduce like operations on node-edge without inventing some special node for handling that stuff.

Idea about comparing LangGraph and Flow is really good and I will work on that asap! What kind of workflows would you love to see implemented in Flow? Btw, there're a lot of examples in the readme and in the /tests folder


Sometimes it reminds me of the evolution of process management software.

What might be new to those developing tooling with AI, might not be new to other areas of software.


we're working on a way to make these conditional flows less tedious :) some good devX improvements coming soon!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: