LangGraph Engineer(github.com)
github.com
LangGraph Engineer
https://github.com/hwchase17/langgraph-engineer
40 comments
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
Good to know!
Is there a succinct explanation of the value that pregel brings to LangGraph? Is it the 3 items I mentioned?
Is there a succinct explanation of the value that pregel brings to LangGraph? Is it the 3 items I mentioned?
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)
Making concurrent work deterministic and solving data races makes sense.
Thanks for explaining! I didn't fully grok this from the LangGraph docs
Thanks for explaining! I didn't fully grok this from the LangGraph docs
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.
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'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...
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 machineYea, 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!
I'll take a look at your repo!
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)
Oh I see - that's interesting.
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.
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.
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).
Wow. Implemented pregel to run a 3 node graph... Jokes aside, that's an interesting thesis to have in there...
all that could be implemented simply using instructor: https://www.lycee.ai/courses/a1ba236b-59e8-48e3-8577-a3e7bc6...
i recently learned that superhuman uses langgraph fwiw https://www.youtube.com/watch?v=Pt3xdZ5vcxE
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.
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.
Looking for similar tools for a project am working on.
Fwiw we didn't start with Pregel, but instead reached for it when we saw issues (described elsewhere in this thread) with the previous approach
[deleted]
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 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."
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
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
Where is the lie in this repo?
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.
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.
The core concept of agent graphs seems quite similar to an LLM agent framework I created last year, [1].
Imo it is a more promising way to make agents, than the prior approach of just giving an LLM N tools to use at once.
[1] https://github.com/sradc/MakeAgents
Imo it is a more promising way to make agents, than the prior approach of just giving an LLM N tools to use at once.
[1] https://github.com/sradc/MakeAgents
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
Is anyone here actually using the LangChain ecosystem in production with success? I’ve only seen/heard bad things.
https://github.com/elastic/kibana/tree/main/x-pack%2Fplugins...
one I saw recently, obvs not the only one
one I saw recently, obvs not the only one
[deleted]
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.