Almost every product team building on AI right now has hit the same fork in the road. Which framework do we build our AI on? LangChain, because everyone uses it?
LlamaIndex, because our team already indexes documents? DSPy, because a research paper made it sound serious? Or just custom code because none of the frameworks feel like they fit?
The internet is loud about this decision and mostly unhelpful. The frameworks are also moving fast enough that last quarter's clear winner is this quarter's cautionary tale. And underneath the noise, the real question your team needs to answer is quiet: what is your product's AI actually doing, and which framework's shape matches that?
So how do you actually pick? That is the point of this piece. You will see what these frameworks really do without the marketing language, the 4 framework paths your product can pick between, the 3 decisions that pick the right framework for your specific product, the 4 things that quietly break framework decisions after launch, a simple pattern that keeps your product loose from any one framework, and the 3 signs somebody is selling you a framework you do not need. All of it is written for the product owner making the call, not the engineer wiring the framework in, because the product owner is the one who lives with the framework's shape across every feature that comes after.
Why does this matter more this year than last? Because the AI framework landscape has both matured and fragmented. LangChain has stabilised its LangGraph branch and become genuinely useful for agent products.
LlamaIndex has doubled down on the retrieval and document-processing story. DSPy has grown from a research curiosity into a practical option for programmatic prompt engineering. And a growing share of serious production teams are building their own framework layer because none of the off-the-shelf ones fit their product exactly. The right pick today is not the right pick from last year, and most teams have not revisited the assumption since they made the original choice.
4
Framework paths your product can pick between: LangChain, LlamaIndex, DSPy, and a custom framework built on top of the model providers directly.
3
Decisions that pick the right framework: the shape of your AI workflow, how much you value framework maturity over control, and whether you plan to run agents or retrieval or both.
4
Things that quietly break framework decisions after launch: version churn, abstraction leaks, framework-specific lock-in, and community-support decay.
1
Wrapper layer that keeps your product's code independent from whichever framework runs underneath. Skip it and switching frameworks becomes a rewrite.
The rest of this piece walks the answer in the order the questions come up during a real conversation about framework choice. What do these frameworks actually do? Which one fits you?
What decides the pick? What breaks after launch? How do you build so a change is cheap?
And how do you spot a vendor selling you the wrong path? Boring on purpose, because the boring framework choice is the one that survives the next version release.
AI Orchestration Frameworks, Explained Without the Jargon
What is an AI orchestration framework? An orchestration framework is a set of pre-built pieces that handle the plumbing between your product's code and the AI model. Instead of calling the model provider's raw interface directly, your product calls the framework, and the framework handles the details: sending prompts, parsing responses, managing conversation history, connecting the model to tools and data, chaining multiple model calls together into a workflow. The framework is the layer between your product's business logic and the model's raw capability.
Why did these frameworks emerge in the first place? Because raw model interfaces are low-level. If your product needs the model to read a document, remember an earlier conversation, use a tool, and produce a structured answer, doing all of that by hand every time takes real engineering work.
Frameworks package the patterns most teams end up needing, so your team writes less plumbing code and reaches a working AI feature faster. The trade is that the framework's assumptions become your product's assumptions, and moving to a different framework later is not free.
So what are the 4 paths actually different from each other? LangChain is the broadest framework, covering agents, chains, tools, memory, retrieval, and just about every AI pattern the community has invented; it is the popular default and the largest ecosystem. LlamaIndex started as a document-indexing and retrieval library and remains strongest there, though it has grown to cover more; if your product's core is "read documents and answer questions", LlamaIndex fits closely.
DSPy takes a different approach: instead of building your product on hand-crafted prompts, DSPy lets you declare what you want the AI to do and generates the prompts programmatically, useful for teams who want to reduce prompt-engineering drift. Custom means building your framework layer directly on top of the model providers, which is more work upfront and more control forever.
The Framework Question
If your team is spending more time working around a framework's assumptions than benefiting from its shortcuts, the framework is probably the wrong fit for your product's AI shape. Every framework has an implicit product model it was designed for; picking one that matches your product is worth more than picking the one everyone recommends.
Which of the 4 Framework Paths Fits Your Product Right Now?
Which of the 4 paths does your product actually need? Almost every "which AI framework should we use" conversation resolves into one of them once you push on the actual product. Knowing which one you are in changes everything: the launch effort, the team skills you need, the community you draw on, and how much your product owns versus rents.
4 Paths
What "Which AI Framework Should We Use" Actually Turns Out to Mean
Path 1
LangChain (and LangGraph)
The broadest framework, covering agents, chains, tools, memory, and retrieval. LangGraph is the maturing agent-workflow layer. Best for teams building varied AI features who value ecosystem breadth over surgical fit. Largest community, fastest-moving, and most churn between versions.
Path 2
LlamaIndex
Retrieval and document-processing first, with a growing agent story. Best for teams whose product is fundamentally about reading documents, indexing them well, and answering questions grounded in specific content. Cleaner mental model when your workload is retrieval-heavy.
Path 3
DSPy
Declarative programming for AI pipelines, generating prompts programmatically rather than hand-crafting them. Best for teams who want to reduce prompt drift, evaluate multiple prompt strategies, and iterate systematically. Smaller community, more research-oriented, real production adoption growing.
Path 4
Custom Framework on Top of Providers
Skip the frameworks and build your framework layer directly on top of the model providers. More upfront engineering, more control forever, no framework-version churn. Best for teams whose product's AI shape does not match any framework's assumptions well.
Which Path Fits You
Ask what your product's AI actually does most. If it is a mix of everything, LangChain covers the widest ground. If it is document reading and retrieval, LlamaIndex fits closer. If your team values systematic prompt evaluation, DSPy is worth serious consideration. If none of the frameworks fit your product's shape cleanly, custom is often the honest long-term answer.
Why does the framework path matter so much before you build? Because each framework has a different implicit product model. LangChain assumes your product is a mix of chains and agents; LlamaIndex assumes your product is a retrieval pipeline; DSPy assumes your team wants to iterate on prompt programs; custom assumes your team is willing to build the plumbing. Picking a framework whose implicit model does not match your product means you spend more time working around the framework than benefiting from it, and the shortcuts the framework was supposed to provide become a tax instead of a saving.
3 Decisions That Pick the Right Framework
Once you know the 4 paths exist, which questions actually separate the right one from the loud one? The 3 decisions below are the ones that keep showing up. Every other input (star count on the framework's repository, blog post recommendations, which framework a friend at another company uses) is downstream of these 3.
01
What Is the Actual Shape of Your Product's AI Workflow?
Sit down and describe, in one paragraph, what your product's AI actually does when a user hits the feature. Is it "read a customer question, look up 3 relevant documents, and answer"? That is a retrieval pipeline and LlamaIndex fits closely. Is it "take a request, decide which of 8 tools to use, act on the result, and possibly loop"? That is an agent workflow and LangGraph is the maturing choice. Is it "run the same well-defined transformation on every input with occasional prompt improvements"? That is where DSPy shines. Match the framework to the actual workflow shape, not to the workflow you wish your product had.
02
Framework Maturity Versus Product Control
How much are you willing to pay in engineering time to escape the framework's assumptions? LangChain is the most mature and the most opinionated; you get a lot done fast, and you inherit assumptions that may not fit your product. Custom is the least assumption-heavy and the most engineering; every piece is yours. LlamaIndex and DSPy sit between. For early-stage products moving fast, framework maturity often wins. For products where the AI is a differentiator, control usually wins. Answer this honestly before the vendor pitch, not after.
03
Are You Building Agents, Retrieval, Both, or Something Else?
Agents and retrieval are the 2 shapes most frameworks focus on today. Agents are AI workflows that decide what to do next based on the current state and can loop through multiple steps. Retrieval is pulling relevant information from your data at question time to ground the AI's answer. Products doing one of these primarily fit a framework designed for it; products doing both fit a broader framework or a custom setup. Products doing something else entirely (batch processing, structured extraction pipelines, embedding jobs) often find frameworks less useful and custom more honest.
Answer in This Order
Answer the workflow-shape question first, the maturity-versus-control question second, the agents-versus-retrieval question third. Teams that answer them in reverse pick a framework because it is trendy and then discover the workflow shape did not fit, and the shortcuts became tax. Order matters more than most teams realise.
4 Things That Quietly Break Framework Decisions After Launch
What actually goes wrong with framework choices once they are running in production? The 4 below show up in almost every framework choice that felt clean at launch and started causing arguments a few months in. All of them are survivable if the framework was picked with them in mind. Skipping them at launch is why so many AI products end up refactoring their framework layer.
01
Version Churn That Breaks Your Product on Upgrade
The frameworks are moving fast. LangChain in particular has gone through several rounds of significant restructuring, with abstractions being renamed, deprecated, or replaced. Products that pin to a version stagnate; products that follow the latest version discover the upgrade broke their carefully-tuned code. Every framework has its own churn rhythm and you inherit it when you adopt the framework. Plan for regular upgrade cycles and version-lock discipline; treat each framework upgrade like a small migration project.
02
Abstraction Leaks You Have to Work Around
The framework promises to hide the model provider's details behind clean abstractions. In practice, one provider's specific quirk leaks through, or the framework's tool-calling abstraction does not quite match the newest provider capability, or the framework's memory pattern does not fit your product's session model. Every time the abstraction leaks, you write custom code that half-lives inside the framework, half outside. Enough of these accumulate and you have the worst of both worlds: framework overhead plus custom code plus impedance mismatch between them.
03
Framework-Specific Lock-In That Was Not Obvious at the Start
Your product's evaluation, observability, deployment, and prompt-management workflows all end up tied to the framework's ecosystem. Moving to a different framework means moving all of that too, and every framework has its own conventions for these adjacent tools. This lock-in is subtle and only becomes visible when you try to switch. The wrapper pattern covered below is what keeps your product's code loose from the framework; adjacent tooling is where the lock-in still creeps in unless you plan for it explicitly.
04
Community Support Decay When the Framework Falls Out of Fashion
Popular frameworks have vibrant communities, and popular frameworks eventually get less popular as newer options attract attention. When the community shifts, the questions your team asks on forums get answered slower, blog-post coverage dries up, integrations with new model providers arrive later. The framework still works technically, but the ecosystem around it thins out. Products that picked a framework primarily for community size have to reassess when the community moves on.
Why These Are Framework-Specific
All 4 of these are things you inherit when you adopt a framework, whether the framework's docs mention them or not. Building on top of a framework means adopting its version cadence, its abstraction philosophy, its ecosystem lock-in patterns, and its community lifecycle. None of this is a reason to avoid frameworks; it is a reason to pick deliberately and to build the wrapper pattern below from day one.
The Framework Fit Table
4 Framework Paths Across the Workloads That Show Up in Real Products
Workload
LangChain
LlamaIndex
DSPy
Custom
Chain of prompts
Strong
OK
Strong
Full control
RAG over documents
OK
Strongest
OK
Full control
Prompt optimisation
Weak
Weak
Native
Own tooling
Structured production traffic
Care needed
Care needed
Fits well
Best-in-class
Match Framework to Dominant Workload
Pick by the workload that dominates your product traffic, not by the framework with the loudest ecosystem noise. Mixed workloads usually benefit from the loose-coupling pattern below rather than one framework doing everything.
A Pattern That Keeps Your Product Loose From the Framework Choice
So what does an AI product built to survive framework changes actually look like? Not fancy. The shape below is the arrangement that keeps your product code from ever calling a specific framework directly, so moving between LangChain, LlamaIndex, DSPy, or a custom layer is a wrapper change and not a rewrite.
Every layer has one job. When the framework underneath changes (and it will), the change stays contained.
Architecture
A Pattern That Keeps Your Product Loose From the AI Framework Underneath
Layer 1
Your Product
Calls your internal AI service by intent (answer a question, run this agent workflow, extract these fields). Never imports LangChain or LlamaIndex or any framework directly.
Layer 2
Your AI Service Interface
One clean interface for every AI operation your product does. Framework names live only inside this layer. Adding a second framework means adding an adapter, not touching product code.
Layer 3
Framework Adapter
Translates your service interface into the specific framework's calls. One adapter per framework you use. Swapping a framework means writing a new adapter, not changing the rest of your product.
Layer 4
Framework and Model Providers
The framework itself, wired to whichever model providers you use. Isolated from the rest of your product by the adapter above. When the framework changes or the provider does, only this layer knows.
↓
What This Buys You
Freedom to Move as the Framework Landscape Shifts
Survive Version Churn
Framework upgrades change the adapter, not your product code. The team can plan upgrades as small projects instead of full migrations.
Mix Frameworks Per Task
Use LangGraph for agents and LlamaIndex for retrieval; the product does not need to know either exists.
Exit to Custom Cleanly
If the framework stops fitting, replace it with a custom adapter. Your product code stays unchanged during the swap.
Why the Wrapper Matters
The frameworks will keep churning. Your product should not have to churn with them. The wrapper is the pattern that lets your team upgrade, mix, or exit frameworks as the landscape moves, without ever touching the product code that lives above the AI service interface. The upfront investment is small; the long-term freedom is real.
Why build this pattern even if you only use one framework today? Because adding it later is much harder than adding it now. A product with framework imports scattered through the code becomes a very hard rewrite when the day comes to change frameworks.
A product that started with the wrapper in place adds the second framework as a small adapter. This is the choice that lets your product age well as the framework landscape keeps moving.
3 Signs You Are Being Sold a Framework You Do Not Need
How do you tell whether a framework being pushed on your team is actually going to help your product, or whether it is going to add complexity you do not need? The 3 signs below give it away. If you spot more than one, the framework is probably being sold for the wrong reasons.
01
The Pitch Cannot Match Framework Features to Your Actual Product Workflow
The person recommending the framework talks about its features, its community, its momentum, and how many companies use it. What they do not do is walk through what your product actually does and show how the framework's features match. A framework recommendation without that mapping is a general pitch, not a fit assessment. Insist that the person recommending walks through the product's real AI workflow and points to specific framework pieces that will do specific work. If they cannot, the recommendation is not grounded in your product.
02
The Comparison Skips Custom as a Real Option
A serious framework evaluation compares each framework path against building the same layer custom. If the comparison skips custom entirely or dismisses it as "not worth doing", the evaluation is biased. Custom is a real option for many products, especially ones whose AI shape does not match any framework's assumptions cleanly. A framework recommendation that will not honestly assess whether custom would be simpler and lower-risk for your specific product is over-selling the framework.
03
The Argument Rests on "Everyone Uses It"
Popularity is a signal, not a decision. Every framework has fit some products well and fit others badly. A recommendation that leans on "the community is huge" or "the star count is highest" without walking through what your product needs is treating framework choice as a social decision rather than a product decision. Popular frameworks are popular because they fit many workflows; your product needs to be one of those workflows, or the popularity gives you nothing beyond a bigger community you can complain to when things break.
The Framework Filter
Ask the person recommending the framework 3 things in the same meeting: walk through my product's AI workflow and point to the framework's pieces that will do each step; compare each framework option against building it custom; and tell me why my product's shape specifically benefits from this framework beyond the general popularity argument. Serious recommenders answer all 3; casual ones answer none.
Frequently Asked Questions
Is LangChain still the default AI framework in 2026?
For breadth of ecosystem and community, still yes. For a growing share of production teams, no longer the automatic pick. LangChain has been through several significant restructuring rounds, and many teams that adopted early have since either migrated to LangGraph specifically (the maturing agent-workflow branch), moved to alternatives like LlamaIndex where retrieval is the focus, or built custom because the framework's assumptions did not fit their product. LangChain remains the right pick for many products; it is no longer the automatic pick for all products, and the difference matters when your product's AI shape is specific.
When should you actually build a custom framework instead of adopting one?
When your product's AI workflow does not match any framework's assumptions cleanly, when the framework's abstractions leak often enough that your team is writing more workaround code than framework code, when framework version churn is costing you more than the shortcuts are saving, or when the AI layer is a core differentiator you want to own completely. Custom is more upfront engineering; it is also less framework overhead forever, and no version churn from someone else. Most products should start with a framework and evaluate custom seriously when at least 2 of these conditions apply to their situation.
Can you use LangChain and LlamaIndex together in the same product?
Yes, and many production teams do. LlamaIndex for the retrieval pipeline (indexing documents, storing embeddings, retrieving relevant chunks), LangChain or LangGraph for the agent workflow that consumes those chunks and orchestrates the response. The wrapper pattern above is what makes this practical without turning your codebase into a mess; each framework lives behind its own adapter, and your product code just calls the AI service interface. Mixing frameworks per task is usually cleaner than picking one framework and forcing all your workflows through it.
Is DSPy production-ready or still a research tool?
Both. DSPy started as a research framework and is now used in production by teams who want systematic prompt-program iteration rather than hand-crafted prompt engineering. The community is smaller than LangChain's, the ecosystem is thinner, and the mental model requires a real shift for teams used to writing prompts as strings. When it fits, DSPy meaningfully reduces prompt drift and lets your team iterate on prompt strategies as measurable programs. When it does not, forcing a product into the DSPy model adds more complexity than it removes. Try it on a specific workflow before committing at product level.
How much overhead do frameworks add at runtime?
Usually more than teams expect and less than the loudest critics claim. Frameworks add some function-call overhead, occasional extra round trips for their built-in orchestration, and memory usage for the pieces they load. For most production workloads this is negligible compared to the model inference time itself, which dominates the latency budget. For very high-throughput or latency-sensitive workflows, the overhead can start mattering and is one of the reasons some teams build custom. Measure the overhead on your actual workload before deciding whether it is a problem; do not assume based on internet arguments.
What happens when your chosen framework has a breaking change in a new version?
If your product code depends on the framework directly, the breaking change becomes a migration project across every file that uses the framework. If your product code lives above the wrapper pattern covered above, the breaking change becomes an adapter update and your product code stays unchanged. This is the single strongest argument for the wrapper: framework versions will break, some of them soon, and the wrapper turns those breaks from full migrations into small localised changes. Every serious AI product ends up with some version of this pattern; the ones that added it early avoid the pain the ones that did not eventually feel.
Can Entexis help you pick the right framework and build the wrapper pattern?
Yes. Entexis designs and builds AI product foundations across LangChain, LangGraph, LlamaIndex, DSPy, and custom framework layers, and the wrapper pattern that keeps your product loose from any one of them. That work starts with the sorting conversation to identify what your product's AI actually does most, which framework's shape matches that workflow, and whether custom is actually the honest long-term answer. We then design the wrapper layer that isolates your product code from the framework choice, wire the framework adapter for whichever path fits, and hand you a foundation that can absorb the next round of framework churn without breaking. Reach out with what your product does today, which frameworks you have looked at, and where you feel your team spending time working around a framework rather than benefiting from it, and we can walk through the right framework path for your specific product.
So where does that leave your product? The 4 framework paths cover almost every AI-product build. LangChain fits broad, mixed AI workflows and has the biggest community.
LlamaIndex fits retrieval-heavy products cleanly. DSPy fits teams valuing systematic prompt iteration. Custom fits products whose AI shape does not match any framework well, or whose AI is core enough to be worth owning entirely.
The 3 decisions above pick between them honestly; the 4 breakers happen after launch and need to be planned for; the wrapper pattern keeps your product loose so any of these choices can change without a rewrite. Get the framework fit right first, put the wrapper in from day one, and your product stays free as the framework landscape keeps moving. Skip the wrapper and you are picking a framework permanently, whether you meant to or not.
Want a Product That Uses the Right Framework Instead of the Popular One?
At Entexis, we design and build AI product foundations across every framework path (LangChain, LangGraph, LlamaIndex, DSPy, and custom). We start with the sorting conversation to identify which framework matches your product's actual AI workflow, design the wrapper layer that keeps your product loose from the framework choice, wire the specific framework adapter that fits, and hand you a foundation that can absorb the next round of framework churn without breaking. Your product runs on the framework that actually fits its shape, your team stops working around a framework's mismatched assumptions, and your AI foundation stays free to move as the landscape does. Start the conversation with Entexis.
Ready to Add AI to Your Business?
From intelligent chatbots to workflow automation, we build AI solutions that understand your domain, your data, and your users. Tell us what you need.
We'll get back within one business day.
Thank You!
We've received your message and will get back to you within one business day.
Try the AI workflows we build, for real, right now.
Same workflow patterns Entexis rolls into client setups. Try them in your browser, no signup. If one feels like it'd help your team, we build a private version tuned to your data.
