hwchase17

Hi HN! It’s been three years since we launched LangChain as an open source package. Since then, we’ve evolved into a broader platform for agent engineering (LangGraph, LangSmith). Our tools now power AI teams like Replit, Clay, Harvey, Vanta, Cloudflare, Rippling, Cisco, Workday, and many more. Our goal has always been to figure out what the agents of the future look like, and then build tools to help make them real.

Today we’re excited to announce new funding (at a $1.25B valuation) to allow us to continue building the platform for agent engineering, as well as new features and products.

And what I’m most excited about today is that we’re launching a number of new features and products: an insights agent in LangSmith, 1.0 releases of LangChain and LangGraph, and a no-code agent builder. We’ll talk a lot more about these throughout the week.

I’m excited to see how you like these new releases and get feedback. I'll hang out in the comments here for a while to answer any questions folks might have.

Author here!

Main takeaways (which I'd love feedback on) are:

There are series of agents recently (claude code, manus, deep research) which execute tasks over longer time horizons particular well

At the core of it, it's just an LLM running in a loop calling tools... but when you try to do this naively (or at least, when I try to do it) the LLM struggles with doing long/complex tasks

So how do these other agents accomplish it?

These agents all do similar things, namely:

1. They use a planning tool

2. They use sub agents

3. They use a file system like thing to offload context

4. They have a detailed system prompt (prompting isn't dead!)

I don't think any of these things individually is novel... but I also think that they are not super common place to do when building agents. And the combination of them is (I think) an interesting insight!

Would love any feedback :)

that was a quote from anthropic's blog (not us saying it)... our Ghost theme does not make it super apparent what is a quote :/

lol taken completely out of context

I was actually arguing *for* MCP in this blog

But I don't think its good for all use cases! hence the quote

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

Excited to launch this! Happy to answer any questions HN community might have

what did it look like though? I'm really keen to hear what the common patterns you saw emerging were

> My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part

a lot of our effort recently has been going into standardizing model wrappers, including for tool calling, images etc. this will continue to be a huge focus

> My other advice would be to build a lot of these small libraries… take advantage of your resources to iterate quickly on different ideas and see which sticks. Then go deep on those. What you’re doing now is doubling down on your first success, even though it might not be the best solution to the problem (or that it might be a solution looking for a problem).

I would actually argue we have done this (to some extent). we've invested a lot in LangSmith (about half our team), making it usable with or without langchain. Likewise, we're investing more and more in langgraph, also usable with or without langchain (that is in the orchestration space, which youre separately not bullish on, but for us that was a separate bet than LangChain orchestration)

would love any feedback if you do!

> Different agents for different situations...

totally agree. we've opted for keeping langgraph very low level and not adding these higher level abstractions. we do have examples for them in the notebooks, but havent moved them into the core library. maybe at some point (if things stabilize) we will. I would argue the react architecture is the only stable one at the moment. planning and reflection are GREAT techniques to bring into your custom agent, but i dont think theres a great generic implementation of them yet

totally agree on not hiding prompts, and have tried to stop doing that as much as possible in LangChain and are not doing that at all in LangGraph

thanks for the thoughts, appreciate it

ooc, what was the "same single solution"

sorry to hear that, totally understand feeling burnt

ooc - do you think theres anything we could do to change that? that is one of the biggest things we are wrestling with. (aside from completely distancing from langchain project)

Hi HN, Harrison (CEO/co-founder of LangChain) here, wanted to chime in briefly

I appreciate Fabian and the Octomind team sharing their experience in a level-headed and precise way. I don't think this is trying to be click-baity at all which I appreciate. I want to share a bit about how we are thinking about things because I think it aligns with some of the points here (although this may be worth a longer post)

> But frameworks are typically designed for enforcing structure based on well-established patterns of usage - something LLM-powered applications don’t yet have.

I think this is the key point. I agree with their sentiment that frameworks are useful when there are clear patterns. I also agree that it is super early on and super fast moving field.

The initial version of LangChain was pretty high level and absolutely abstracted away too much. We're moving more and more to low level abstractions, while also trying to figure out what some of these high level patterns are.

For moving to lower level abstractions - we're investing a lot in LangGraph (and hearing very good feedback). It's a very low-level, controllable framework for building agentic applications. All nodes/edges are just Python functions, you can use with/without LangChain. It's intended to replace the LangChain AgentExecutor (which as they noted was opaque)

I think there are a few patterns that are emerging, and we're trying to invest heavily there. Generating structured output and tool calling are two of those, and we're trying to standardize our interfaces there

Again, this is probably a longer discussion but I just wanted to share some of the directions we're taking to address some of the valid criticisms here. Happy to answer any questions!

Cofounder of LangChain here!

LangSmith is designed to be independent of LangChain. Some resources:

tracing without LangChain: https://github.com/langchain-ai/langsmith-cookbook/blob/main...

Docs on tracing without LangChain: https://docs.smith.langchain.com/tracing/tracing-faq#how-do-...

We are also actively revamping our documents on this! Hopefully will be better soon

We're also actively revamping our documentation on this topic, so example

hi all - Harrison (co-founder) of LangChain here

We released this as a way to make it easier to get started with LLM applications. Specifically, we've heard that when people were using chains/agents they often wanted to see what exactly was going on inside, or change it in someway. This basically moves the logic for chains and agents into these templates (including prompts) - which are just python files you can run as part of your application - making it much easier to modify or change those in some ways.

Happy to answer any questions, and very open to feedback!

LangChain co-founder here. There's lots of good feedback here (that also resonates with previous feedback) that we're working hard to address. On some key points:

- We genuinely appreciate all the thoughtful criticism and feedback. Our goal is to make it as easy as possible to build LLM applications (both prototypes and production-ready applications), and if we're falling short in an area we'd much prefer to hear it rather than not. We don't have the bandwidth to respond to all feedback directly, but we do (1) appreciate it, and (2) try to address it as quickly as possible.

- Documentation: we've heard this for a while now, and have been working to improve it. In the past ~3 weeks we've revamped our doc structure, changed the reference guide style, and worked on improving docstrings to some our more popular chains. However, there is a still a lot of ground to cover, and we'll keep on pushing. Feedback on which specific chains/components need better documentation is particularly helpful

- Customizability: we need to make it easy to customize prompts, chains, and agents. We're thinking of changes to more easily enable this - better documentation, more modular components. We'll up the priority of this.

- Other tooling: there are general difficulties in building LLM applications that aren't strictly related to langchain, such as debugging and testing. We're working on building separate tooling to assist with this that we hope to launch soon.

working on it as we speak!