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.
I don't really understand why an engineer would use langraph. If a graph based interface for coding was useful, wouldn't they already be used for regular programming? Regular software functions can be viewed as graphs already, what's new about LLMs that make a graph based UI desired? Maybe for really basic no-code programs for non-programmers?
Langgraph is not a no-code tool for visual programming, it's an implementation of the Pregel algorithm for execution of cyclical computation graphs (ie not DAGs)
Honestly I'm happy to be proven wrong about the usefulness of it.
I've used langsmith and found it quite useful. I think I was just so jaded by my bad experience with Langchain, that I'm immediately skeptical of other "lang" products.
I almost didn't try langgraph because I had similar experiences with langchain. IMO it is a lot better than langchain; its abstractions are lower level and more appropriate at least for the projects I've taken on. I think it's probably the best toolkit with which to prototype an agent-based workflow right now.
That being said, it's not doing that much. And you still end up having to use some of langchain's abstractions. If this current "make a cyclical graph of LLM agents that send messages to each other" thing has any staying power than I imagine we'll see a more robust option soon. Personally I'd love a way to build agent graphs in a strongly typed language with first class concurrency.
Really? Can you point to code for that? To me it's just a way to describe a graph and execute it, exactly like https://github.com/dagworks-inc/burr (I'm an author).
One of the issues with LLMs is that each function needs to be tested and observed more thoroughly than regular functions, which leads to these UIs to figure out what the heck is actually going on.
For our DSL (BAML https://github.com/BoundaryML/baml ) we found that adding a VSCode playground to visualize LLM function inputs and outputs was a massive win in terms of debuggability and testability, so I can see why langraph is going this way.
Langgraph engineer seems promising, especially given the complexity in building an effective agentic AI solution. While Pragel seems like an overkill (to build graphs on internally in langgraph), not found other simpler tools that provide same flexibility to build and visualize agent based flows.
Looking for similar tools for a project am working on.
Thanks, would using a topological sort or other simpler algos, not sufficed processing the graph with cycles directly, may not be as optimised as Pregel, but would have been simpler.
I don't understand how LangChain is in enough of an echo chamber that I'm reading RTs this AM from the titular lead cheering on someone open-sourcing "AGI" via the umpteenth implementation on LangChain of "monkeys on typewriters via N LLM responses"
I don't complain actively about LangChain because this seems widely understood at this point, and apologize for being abrupt, but at some point, when this behavior is repeated, the assumption shifts from "lack of perspective on our own work", which we all suffer from, into "feigned naivete designed to mislead"
I think if you actually meet the people you'd realize they're pretty earnest and candid of these things' limitations, though it may not show in tweets and hackernews posts.
This repo, for instance, makes no claims of AGI. It just claims to help bootstrap a starting point for a software project: "it will not attempt to write the logic to fill in the nodes and edges."
Right, if we swap in something else for what I was actually talking about, it doesn't demonstrate what I said it does.
I agree, my heart says they know they're lying too, but that seems worse than assuming they're suffering from self-blindness, since we all do and that bears less intention
It's a sad reminder that as long as you have the "right" credentials you can appear legitimate. Stanford grad, SF based. I haven't used it much and I can already sense it's over-promise-under-deliverness. Hopefully langchain will get found out sooner rather than later.
I pray 7 years at Google is enough to break through this with my own startup. Left a year ago. Before Google, I was a college drop out & waiter that sold a mildly successful startup. No one cared. Next best offers were $120K in NYC, or $50K in Buffalo.
You know, thinking on it, the factor you mention gets it more likely to get you funding, and the funding is what lets you live in an echo chamber.
Tis sort of close-minded navel-gazing happened all. the. time. at Google. I call it "rich people thinking" but it might just be the penultimate white collar thing. At some point the "success" of being there is widely considered enough, and anyone speaking up is either crazy or not a team player.
Even when you've been watching the naked emperor together for 6 months.
Even when "speaking up" is hilariously non-negative, ex. "just a thought exercise, is it possible the emperor does not have 1000 layers of clothes? if so, maybe possibly could I do some work to contribute to the team that could consider an action plan to account for any anticipated negative effect in the market if, possibly, it is shown they are lacking some clothes?"
There's plenty of obviously coarse contrarians, I used to think complaining about this sort of thing was for chumps who couldn't communicate. It's not. Social problems tend to be well-known, drive ~all variability in results, and simple enough that a middle schooler would grok them.
it’s amazing how the latest trend in software engineering feels so unengineered. “if process doesn’t work cross your fingers and try again” feels like a religious sacrament
Can someone please point to some practical things implemented with these frameworks? I’m quite confused by what requires such complexity that wouldn’t be better done by humans
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.