Good for getting started, not always for staying
Technology
LangChain is the fastest way to get tool calling, prompt templates, retrieval, and memory working together. That is a real advantage in the first weeks of a build. It is also a layer of abstraction between you and the model, and abstraction has to keep earning its keep.
We have shipped on it and we have moved off it. On a voice booking agent we started with LangChain and switched to AWS Strands and Bedrock AgentCore when it arrived. On the Quicknode Builder's Guide it is still in the stack. This page is about telling those two cases apart.
The case for
What LangChain is genuinely good at
- It gets you to a working chain fast
Tool calling, prompt templates, retrieval, and memory arrive as components instead of as code you write twice. In week one of a build, that is the difference between arguing about architecture and having something a client can actually talk to and react to.
- It keeps the model decision open
The same chain runs against Claude, GPT, and open source models with a swap at the edges. While model selection is still an open question, not hard wiring the answer into your orchestration layer is worth paying some abstraction cost to protect.
- It built the first version of our assistant
The original monogram.io chatbot used LangChain document loaders, a recursive character text splitter, and Pinecone as the vector store. Load the sitemap, split, embed, index, retrieve. The whole indexing pipeline was framework code, and that was the right call at the time.
The move
Why we left it on the voice agent
- Voice runs on a tighter budget than chat
On a voice call the model is the last thing to get a turn. Speech recognition and synthesis have already spent their share of the budget by the time the transcript exists, and the target for the whole exchange was two seconds. Every abstraction between transcript and model has to justify the milliseconds it costs.
- Session state already lived in the client's stack
The booking agent keeps the whole conversation in DynamoDB and pulls policy from a Bedrock Knowledge Base. When the client's own datastore is the system of record for a call, a framework's memory layer becomes a second place for the same truth to live. We let the platform own it.
- Portability you never exercise is just cost
The abstraction that protects you from a vendor also puts that vendor's newest features behind a lag. If the model, the memory store, and the telephony are all going to live in one cloud anyway, the indirection is rent on an option nobody intends to take.
The record
Shipped on it, and moved off it
Writing
How we think about this
Framework choice is not a loyalty test. LangChain got the first version of our site assistant indexing and retrieving, and it got a voice agent to a working booking transaction. Then AWS shipped a runtime that did the same job natively, and we moved.
The question we ask on every build is what the abstraction is protecting you from, and whether that risk is still live. Model portability matters while the model is undecided. It stops mattering the day a client tells you everything runs inside their own AWS account.
We still ship LangChain where its retrieval and tool calling components carry their weight. We do not keep it around out of habit. Start a conversation.