What is LangChain? The Framework for Building LLM Apps

LangChain is an open-source framework for building applications powered by large language models (LLMs).

Launched in late 2022, it is the architectural "harness" or glue that connects a model's reasoning engine to application logic and external data. By providing a standardized interface for interacting with diverse model providers — OpenAI, Anthropic, or Google — LangChain lets engineers build complex, context-aware systems without being restricted by the implementation details of a single vendor's SDK.

LangChain is a unified abstraction layer that manages the flow of data between the user, the model, and external resources. Its modular pieces translate high-level application requirements into the specific tokens and message formats LLMs consume. This structural approach lets you keep a consistent code shape while swapping the components underneath it.

LangChain as the standardizing layer joining a large language model to private data and external tools

What problem does LangChain exist to solve?

The foundational challenge in deploying large language models for production is that these models are trained on static, public data and lack any state or context regarding a company's proprietary documentation. LangChain exists to bridge this gap by facilitating Retrieval Augmented Generation (RAG). RAG treats the LLM as a reasoning engine performing an "open book test": the framework retrieves relevant private data from an external source and injects it into the context window at runtime, giving the model the facts it needs to generate accurate, domain-specific responses.

RAG as an open book test: retrieve private data and inject it into the context window before the model answers

LangChain also addresses the high orchestration overhead and the risk of vendor lock-in. Building directly against a provider-specific SDK removes your ability to pivot models as performance and cost dynamics change. LangChain's "Runnable" interface abstracts provider-specific SDK idiosyncrasies into a unified runtime, letting teams swap a model from GPT-4 to Claude 3.5 with minimal modifications to the core business logic. That flexibility is what keeps long-term architectural agility possible in a fast-moving ecosystem.

The framework also solves the "glue code" problem inherent in data cleaning and prompt engineering. Production-grade AI requires more than a single API call; it requires robust pipelines to handle string interpolation, input normalization, and the transformation of raw unstructured data into valid JSON or tokens. LangChain provides the scaffolding to manage this complexity, ensuring raw data is cleaned and formatted into structured messages the model can consume reliably, which improves the determinism of the system.

Managing state and durability in agentic workflows is another core problem the ecosystem tackles. In a stateless API environment, long-running tasks that involve multiple model calls are fragile and prone to failure. LangChain, particularly when paired with LangGraph, introduces mechanisms for state management and durable execution. Complex reasoning loops can then survive process restarts or network interruptions, which is an essential requirement for any enterprise-grade AI infrastructure.

The core components of LangChain

The framework rests on one equation: Agent = Model + Harness. The LLM provides the raw reasoning capacity, while LangChain provides the harness — the collection of prompt templates, LLM interfaces, and retrievers. Prompt templates serve as pre-built structures for formatting queries, while retrievers manage the complexity of fetching context from vector stores like Pinecone, ChromaDB, or Amazon Kendra. Together, these components provide the infrastructure required to feed the reasoning engine.

To orchestrate these building blocks, LangChain uses the LangChain Expression Language (LCEL). LCEL is a declarative language that uses the pipe operator (|) to stitch components into a functional chain, such as prompt | model | parser. Every component implements a shared "Runnable" interface, which brings built-in support for streaming, batching, and asynchronous execution. This modularity is further extended by the Model Context Protocol (MCP), which acts like a "USB-C" standard for agents, letting a single server implementation connect a model to any compliant database or API.

The six core LangChain building blocks in layers: models, prompts, chains and LCEL, retrievers, memory, and agents

The framework has moved toward a more centralized and configurable agent implementation through the create_agent API. You define an agent by passing it a model, a set of tools, and a system prompt, and the framework handles the "decide, act, reason, repeat" loop:

python

from langchain.agents import create_agent
 
# Tools can be any Python function or MCP-compliant service
agent = create_agent(
    model="openai:gpt-5.5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)
 
# Execution handles tool calling and message history automatically
result = agent.invoke({"messages": [{"role": "user", "content": "What's the weather in London?"}]})

Using these primitives, engineers can build systems that are multimodal by design, handling text, image, and audio inputs through the same unified interface. The abstraction reduces the surface area for bugs when integrating new data types and allows for the incremental addition of middleware, such as guardrails or custom logging. The result is a configurable system that prioritizes developer control over the opaque black-box behaviors found in earlier versions of the library.

What changed in LangChain 1.0?

The release of LangChain 1.0 marks a pivot from high-level, opaque abstractions toward a low-level, controllable architecture. In the early days of the framework, developers struggled with the AgentExecutor, a black-box implementation that was difficult to debug and modify for non-standard use cases. In response to community feedback about this "death by abstraction," the 1.0 release promoted langchain-core and langgraph to stable versions, emphasizing transparency and fine-grained control over the execution graph.

Before and after 1.0: the closed AgentExecutor replaced by create_agent running on the LangGraph runtime

In the 1.0 architecture, the new create_agent implementation sits directly on top of LangGraph. That moves agent execution into a state-machine model. With LangGraph as the underpinning, agents now benefit from durable execution — the ability to save checkpoints of the agent's state to a database. That enables human-in-the-loop patterns, where an agent pauses for approval and resumes later without losing its reasoning context or re-running expensive tokens.

Another technical advancement in 1.0 is the .content_blocks property within the message interface. As LLM APIs have evolved from returning simple strings to returning lists of diverse content types — tool calls, reasoning blocks, multimodal data — legacy string-based abstractions have become a bottleneck. The .content_blocks property provides a standardized way to handle these modern API responses in a type-safe manner while maintaining backward compatibility for applications that still rely on traditional string outputs.

The 1.0 release also focused on stabilizing the massive integration library. By keeping langchain-core as a stable base for integration abstractions, and moving older chains and agents into a separate langchain-legacy package, the framework ensures core logic stays stable even as specific provider APIs change. This separation of concerns allows for a more predictable update cycle and reduces the risk of the spaghetti code that plagued earlier, more monolithic versions.

How do LangChain, LangGraph, LangSmith and Deep Agents differ?

The LangChain ecosystem is partitioned into tools designed for different phases of the agent development lifecycle. LangChain itself remains the primary library for high-level model abstractions and standardized interfaces, ideal for shipping RAG pipelines and basic chains quickly. It provides the "Runnable" primitives that serve as the foundation for the rest of the stack. For complex, multi-step workflows that require cycles or conditional branching, LangGraph is the preferred orchestration framework, letting you model agents as state machines with persistence and human-in-the-loop checkpoints.

Four-part ecosystem map: LangChain builds, LangGraph orchestrates, LangSmith observes, Deep Agents ships batteries-included

For observability and reliability, LangSmith is a framework-agnostic platform for tracing, debugging, and evaluating model performance. LangSmith does not require LangChain: it can trace and monitor applications built with the raw OpenAI or Anthropic SDKs via OpenTelemetry. It provides a de-facto standard for checking agents through quantitative evals and regression testing, so a prompt tweak doesn't quietly poison downstream reasoning steps.

At the higher end of the abstraction spectrum, Deep Agents provides a batteries-included framework for long-running autonomous agents. It includes infrastructure features like virtual file systems, task planning, and the ability for agents to spawn sub-agents to handle specialized sub-tasks. These tools differ in how much they abstract away, but they all integrate into the LangSmith backend for centralized monitoring.

What do people build with LangChain?

Real-world implementations of LangChain often focus on internal operational efficiency and complex document processing. Vodafone used the framework to build internal AI assistants that monitor performance metrics and retrieve information from documentation. Using LangChain's modular document loaders, the team benchmarked pipelines across models like LLaMA 3 and Gemini, then moved to LangGraph to handle the multi-agent orchestration its data engineering workflows required. This benchmarking-pipeline approach is a common pattern for teams optimizing for both latency and cost.

Another prevalent use case is agentic RAG. Unlike traditional RAG, where retrieval is a hard-coded step in a linear pipeline, agentic RAG treats retrieval as a tool the model calls only when it decides external context is necessary. This suits open-ended queries where the model may need to pull from several disparate sources — a SQL database, a vector store, a web search API — before synthesizing a final response.

In the legal and financial sectors, LangChain is used for document analysis involving map-reduce summarization and structured extraction. These workflows let organizations process contracts that exceed the context limits of current models by summarizing chunks and then synthesizing a final overview. Structured extraction pulls specific fields — expiration dates, counter-party names — directly into typed schemas for database integration. The same patterns keep high-turn conversational assistants grounded in verified internal data.

Why do many developers walk away from LangChain?

Despite widespread adoption, LangChain has drawn sustained criticism, centered on what developers call "death by abstraction." For many engineers, the frustration comes from navigating five or more layers of nested classes just to reach a minute detail, such as the token usage metadata in a model response. That architectural bloat leads to code where the framework's internal complexity makes it hard to debug why a specific agent hallucinated or failed silently inside a reasoning loop.

Stacked abstraction layers sitting between the developer and the actual API call

A specific technical critique from the developer community concerns the TypeScript version of the library. Critics argue the JS/TS implementation reads like a direct port of the Python version, ignoring the idiomatic patterns and structural type-checking benefits of the TypeScript ecosystem. The result is leaky abstractions, where the developer fights the framework's internal logic instead of focusing on the application's actual requirements.

For simple, one-shot completion tasks, many teams find the raw SDKs from OpenAI or Anthropic far more efficient. Because those native SDKs are the thinnest possible layer over the API, they are less prone to breaking during framework updates and offer direct control over prompts. The recurring complaint is the overhead of learning a large framework for tasks that a developer could handle in roughly 80 lines of standard Python and basic string interpolation.

The black-box nature of early agents also cost the framework trust. When an agent fails in production, an engineer needs to see exactly what went into the prompt and what the raw API response was. LangChain's tendency to hide prompts behind code made it slow to iterate on the text itself. The 1.0 release and LangGraph aim to fix this with more whitebox control, but the experience of managing opaque chains pushed many teams to build their own lightweight wrappers instead.

When should you choose LangChain, and when should you not?

Choose LangChain when your requirements involve multi-provider support, complex RAG architectures, or stateful, multi-step agents that need LangGraph's durable execution and checkpointing. It is the right call for teams that want to draw on a large ecosystem of pre-built integrations and need a standardized way to handle multimodal inputs and tool-calling across different model backends.

Decision split: choose LangChain for multi-step, multi-provider work; stay on the native SDK for one-shot calls

Avoid it for simple one-shot completion scripts or single-provider chatbots where the model choice is unlikely to change. There, the orchestration overhead adds complexity and new points of failure without paying for itself. If your application logic is mostly straightforward string handling and a single API call, stay on the native SDKs.