3 ms·
I agree with the overall point but I do think there's a better approach than langchain. Langchain is a framework, not a library. I think a library approach is b
by octopoc 1y ago
I agree with the overall point but I do think there's a better approach than langchain. Langchain is a framework, not a library. I think a library approach is better at this point because libraries can be composed, which supports fundamental shifts in the structure of the code using the library. Frameworks can't be composed--that's the whole point of having a framework. Agentic patterns are so early that frameworks are limiting and we should be choosing libraries instead.
For example, there was a paper recently (unfortunately I can't remember which it was) that talked about how if you support pausing generation and allowing the human to edit the generated text, then resuming, you can get much better results than if you force the human to respond to the AI as a separate message. That's something that is more difficult for a framework to adapt to than for a library to adapt to.
I'm building an agentic framework that is more on the library side of things, and it necessarily leaves control of the iteration in the hands of the developer. The developer literally writes a while loop to run the agent, offloading things like RAG and tool calling to different pieces of the library. But every part of the iteration is controlled by the developer's agent source code.
- digitcatphd 1y agoMakes sense, yes, I think a spectrum of tools will be useful depending on the build. N8N, LangGraph, and working with primitives all have their use case and then tools built on each will be useful much like the landscape of RAG builds have evolved.