LangChain is an open-source software framework for applications that use large language models. Its current high-level focus is an agent harness: a model calls tools in a loop, while application code supplies the prompt, tool definitions, state, middleware, and stopping conditions. The project also provides common interfaces for model providers, messages, structured responses, streaming, and component composition in Python and TypeScript. It does not include a language model, a vector database, or a hosted application runtime by itself.[1][2]

The name is also used informally for an ecosystem maintained by LangChain, Inc. Three parts of that ecosystem should be kept separate. LangChain is the higher-level framework. LangGraph is a separately installable orchestration runtime used underneath LangChain agents and directly by applications that need explicit graphs, persistence, or human interruption. LangSmith is a separate closed-source commercial platform for tracing, evaluation, prompt management, and deployment. An application can use LangGraph without LangChain, and it can use LangSmith with software built using neither open-source framework.[3][4][5]

This article describes the software and product boundaries as they stood at the editorial cutoff of July 28, 2026, 23:59:59 in Bangkok (UTC+7).

Scope and product boundaries

Name	Primary role	Distribution	License or access model
LangChain	Higher-level interfaces and an agent harness for models, tools, messages, middleware, and structured output	Python `langchain`; TypeScript `langchain` plus `@langchain/core`	Open source, MIT for the official framework repositories
LangGraph	Low-level orchestration runtime for long-running, stateful workflows and agents	Python `langgraph`; TypeScript `@langchain/langgraph`	Open source, MIT
LangSmith	Tracing, evaluation, prompt tooling, and managed or enterprise deployment services	Hosted platform, SDKs, and self-hosted or hybrid enterprise configurations	Closed-source commercial product; self-hosting requires an enterprise agreement and license key

This division is architectural rather than merely a branding choice. Calling create_agent in LangChain builds a graph-backed agent, but it does not turn LangSmith on, create a production database, or deploy an endpoint. Conversely, LangSmith can ingest manually instrumented traces from applications written with provider SDKs or other frameworks.[2][4][27]

Cutoff versions

The Python and TypeScript implementations are released independently. Matching major or minor numbers should not be read as a compatibility promise between languages.

Ecosystem	Package	Stable version at cutoff	Registry publication time (UTC)
Python	`langchain`	1.3.14	2026-07-16 13:28:16
Python	`langchain-core`	1.5.2	2026-07-28 16:38:36
Python	`langgraph`	1.2.9	2026-07-10 01:30:13
TypeScript	`langchain`	1.5.4	2026-07-24 20:41:38
TypeScript	`@langchain/core`	1.2.3	2026-07-14 21:43:02
TypeScript	`@langchain/langgraph`	1.4.8	2026-07-15 04:49:06

The version record is taken from the official PyPI and npm registries.[6][7][8][9][10][11] A boundary case illustrates why the timestamp matters: Python langgraph 1.2.10 was published at 18:34:14 UTC on July 28, which was already July 29 in Bangkok, so it falls after this article's cutoff and is not treated as current here.[12]

Development history

Harrison Chase released langchain 0.0.1 as a Python package on October 24, 2022. The initial package centered on model abstractions and "chains", meaning predetermined sequences of computation. General-purpose agents based on the ReAct pattern followed in December 2022, and a JavaScript implementation appeared in January 2023. LangChain, Inc. was formed in February 2023 by Chase and Ankush Gola around the open-source project.[1]

The company released LangSmith as a closed-source observability and evaluation product in June 2023. It released LangGraph as a separate open-source library in February 2024 after users sought more control over execution flow than the original high-level chains exposed. LangChain 1.0, released in October 2025, narrowed the main package around one high-level agent abstraction built on LangGraph and moved older chains, retrievers, and related APIs to langchain-classic.[1][3]

This history explains why examples written for LangChain 0.x can look unlike v1 code. Classes such as LLMChain, ConversationChain, older AgentExecutor patterns, and many memory objects remain relevant to maintenance work, but they do not define the current main-package architecture. The v1 migration guide directs applications that still need those interfaces to install langchain-classic explicitly.[3]

Package architecture

Core and framework packages

The Python distribution is split so that abstractions and integrations can evolve on different schedules:

langchain-core defines base types for chat models, messages, tools, retrievers, vector stores, documents, callbacks, and the Runnable invocation protocol. It intentionally contains no third-party provider integration.[13]
langchain contains the higher-level v1 agent entry point, agent state and middleware, model and embedding initializers, and re-exports for selected message and tool types.[3]
langchain-community contains community-maintained third-party integrations. Its dependency and stability profile is broader than that of the core package.
langchain-classic preserves legacy chains, retrievers, indexing helpers, and other 0.x-era functionality for migration and maintenance.[3]
Provider packages such as langchain-openai and langchain-anthropic implement the common interfaces while exposing provider-specific capabilities. They are separate dependencies, not code bundled into langchain-core.[14]

TypeScript uses analogous concepts but different package names and release numbers. @langchain/core supplies shared interfaces, while langchain, @langchain/langgraph, @langchain/community, and provider packages have their own dependency graphs. Applications should therefore pin and test the exact language-specific packages they deploy rather than translating a Python version number into an npm version.

Models, messages, and provider differences

LangChain's model interface makes operations such as invocation, streaming, tool binding, and structured output look similar across providers. Standard message classes represent system, human, model, and tool messages. Content blocks provide a cross-provider view of text, reasoning blocks, citations, images, and server-side tool activity while retaining an escape hatch for provider-native data.[15]

The abstraction is not a guarantee that providers behave identically. Models differ in context limits, tool-call formats, multimodal support, safety behavior, retry semantics, and native structured-output features. Provider packages also accept provider-specific parameters. Swapping a model may reduce adapter code, but it still requires capability checks, evaluation, and often prompt or schema changes.[14][15]

Runnables and composition

langchain-core defines a Runnable as a unit of work that can be invoked, batched, streamed, transformed, and composed. LangChain Expression Language (LCEL) is the pipe-based syntax commonly used to create a RunnableSequence, for example prompt | model | parser. A sequence can expose synchronous, asynchronous, batch, and streaming methods, but streaming begins only after any component that cannot transform a stream has completed.[16]

Runnables remain useful for deterministic pipelines and custom composition. They should not be confused with agents. A runnable sequence follows the application-defined composition; an agent lets a model choose whether and how to call tools during a loop.

Agents, tools, and middleware

Agent execution

In the current API, create_agent configures a model, a set of tools, a system prompt, optional response schema, state, and middleware. The model receives the conversation and the available tool schemas. It can return a final response or request one or more tool calls. Tool results are added to the state and returned to the model, and the loop continues until a final response or another stopping condition is reached.[2]

This design is historically related to ReAct, which interleaves model-generated reasoning with actions that obtain information from an external environment. The 2023 ReAct paper evaluated that pattern on question answering and interactive tasks. LangChain's production API is not an implementation of that paper alone: modern provider-native tool calling, middleware, persistence, and structured output add behaviors outside the original prompting method.[17]

LangChain agents are compiled onto LangGraph. That gives the high-level API access to LangGraph streaming, checkpoints, interrupts, and stores when the application supplies the corresponding configuration. Developers can instead use LangGraph directly when they need explicit nodes, conditional edges, cycles, parallel branches, or mixed deterministic and model-driven steps.[4]

Tools

A LangChain tool is a callable with a name, description, input schema, and output behavior. The Python @tool decorator can derive a schema from a function signature and use its docstring as the description shown to the model. Tools may read data, execute code, call an API, update graph state, return media, or hand a result directly back to the caller.[18]

The model proposes tool names and arguments; ordinary application code performs the call. This distinction has practical consequences:

A schema validates shape, not intent. A syntactically valid argument can still target the wrong file, account, record, or URL.
A tool runs with the permissions and network access granted to its host process unless the application adds a sandbox or another enforcement layer.
Credentials belong in the execution environment, not in prompts or model-visible tool descriptions.
Read and write capabilities should be separated when possible. Destructive or expensive actions benefit from policy checks and human approval.
Tool outputs are untrusted input when they contain web pages, documents, email, database text, or other externally controlled content.

LangChain's human-in-the-loop middleware can pause selected tool calls and persist graph state while a reviewer approves, edits, or rejects the proposed action. It is a configurable control, not an automatic property of every agent.[19]

Middleware and structured output

Middleware can inspect or alter the agent loop around model calls and tool calls. Current uses include dynamic prompts, context trimming or summarization, retries, tool selection, personally identifiable information handling, and approval gates. Middleware order matters because one layer can change the data seen by the next.[2]

For structured output, an application supplies a schema. LangChain can use a provider's native structured-output mechanism when supported or represent the schema as a tool-call strategy. The returned object is validated against the schema, and validation failures can be retried or surfaced. Schema validation improves machine readability; it does not establish that the values are factually correct.[20]

Retrieval and RAG

Retrieval-augmented generation combines generation with information fetched at query time. A typical LangChain-oriented pipeline uses document loaders to produce Document objects, text splitters to create retrievable units, embeddings or another index representation, a vector database or search system, and a retriever that returns documents for a query.[21]

These pieces span packages. Loaders and vector-store integrations often live in langchain-community or provider-specific packages; retriever base interfaces live in core; older higher-level retriever implementations may live in langchain-classic. The langchain v1 package does not itself contain a managed corpus, embedding service, or vector database.

LangChain documentation distinguishes several orchestration patterns:

In two-step RAG, retrieval runs before one bounded generation step. Its control flow and maximum number of model calls are comparatively predictable.
In agentic RAG, retrieval is exposed as a tool and the model decides whether, when, and how often to query it.
Hybrid workflows add query rewriting, retrieval validation, answer checks, or bounded iteration under application-defined control.[21]

The term RAG originated in research that combined a generator's parametric memory with a retrieved non-parametric document index. That work showed how replacing the index could update accessible knowledge without retraining all model parameters.[22] In application frameworks, "RAG" is broader and does not imply the end-to-end trained architecture from the original paper.

Retrieval can make evidence available to a model, but it does not guarantee grounding. Results may be irrelevant, stale, duplicated, access-controlled incorrectly, or malicious. Applications that need citations must preserve source identifiers through chunking and retrieval and verify that the final claims are actually supported by the cited passages.

State, persistence, and memory

The word "memory" is used for several different mechanisms. Treating them as interchangeable causes design and privacy errors.

Mechanism	Scope	What it stores	Typical use
Model context	One model call	Messages and content sent to the provider	Immediate generation
Agent or graph state	Current execution or thread	Messages plus application-defined fields	Control flow and working state
Checkpointer	One thread across invocations	Snapshots of graph state	Resume, interruption, conversation continuity, fault recovery
Store	Application-defined namespaces across threads	Key-value or document-like records	User preferences, durable facts, shared application memory
Retrieval index	Corpus or knowledge base	Searchable documents, chunks, or vectors	Find external evidence for a query

LangGraph supplies the persistence layer used by LangChain agents. A checkpointer records thread-scoped state, while a store holds cross-thread application data. In-memory implementations are suitable for examples and local tests; durable deployments require an appropriate database-backed implementation or Agent Server persistence.[23][24]

Persisting a conversation is not the same as fitting it into a model's context window. Long threads may need message deletion, trimming, or summarization before a model call. Summaries are model-generated representations and can omit or distort details, so important application facts are better stored in explicit typed fields or records than recovered only from a rolling summary.[23]

Long-term memory also needs a policy for authorship, correction, expiry, and isolation. A store makes data retrievable across threads, but the application still decides what deserves to be written, which namespace may read it, and when it should be deleted.

LangGraph

LangGraph is the low-level runtime beneath the current LangChain agent abstraction. An application defines nodes that perform work, edges or commands that select subsequent work, and a state schema that controls how updates are merged. Graphs can include cycles, conditional branches, subgraphs, parallel work, deterministic code, and model-driven nodes. LangGraph can be used with LangChain model and tool integrations, but it does not require them.[4]

The maintainers cite Google's Pregel system among LangGraph's inspirations. Pregel expressed graph computation as synchronized supersteps in which vertices process messages and update state. LangGraph borrows graph and message-passing ideas for application orchestration, but the acknowledgement does not mean its public API or execution semantics are identical to Pregel.[4][25]

Persistence and durable execution

With a checkpointer, graph state can be saved at execution boundaries and associated with a thread identifier. This enables pause and resume, human interruption, replay for debugging, and recovery after some failures. A store provides separate cross-thread data.[24]

"Durable execution" should not be read as exactly-once execution for arbitrary side effects. On resume, workflow code may replay to reconstruct the recorded path. LangGraph's functional API therefore directs developers to wrap nondeterministic work and side effects in tasks so persisted results can be reused. Calls that charge money, send messages, write files, or mutate remote records should also be idempotent or protected by application-level deduplication.[26]

When to use it directly

Direct LangGraph use is appropriate when the flow itself is a first-class part of the application: for example, a support process with required validation and escalation stages, or a research workflow that fans out and then joins. LangChain's create_agent is simpler when the central behavior is one model-and-tools loop with middleware. A plain provider SDK or ordinary function may be simpler still for a single model call or a short fixed pipeline.

LangSmith

LangSmith is not an open-source submodule of LangChain. It is a framework-agnostic commercial platform whose major functions include observability, evaluation, prompt tooling, and agent deployment.[1][27]

Tracing and evaluation

LangSmith represents one application operation as a trace made of runs. A run can correspond to a model call, retrieval step, tool execution, parser, or other unit of work; multiple traces can be grouped into a conversational thread. Integrations can instrument supported frameworks, while decorators, context managers, and a low-level run API support custom code.[27]

Evaluation is a separate activity. Offline evaluation runs application versions on datasets before release; online evaluation scores sampled production traces. Evaluators may be code rules, human review, pairwise comparison, or another model acting as a judge.[28] The platform records and compares scores, but the meaning of a score still depends on dataset coverage, evaluator validity, sampling, and the model used as judge.

Tracing has a data-governance cost because traces can contain prompts, user inputs, retrieved documents, tool arguments, tool results, and model outputs. LangSmith tracing can be disabled with configuration, and conditional tracing can restrict what is sent. Teams need retention, access-control, redaction, and deletion decisions before sending sensitive production data.[29]

Deployment

Open-source LangChain code can be deployed with any web framework or application platform; the library does not choose an infrastructure model. LangSmith Deployment is a distinct service for packaging and operating agent applications. Official configurations include managed cloud, hybrid deployments with the application data plane in a customer's environment, and self-hosted enterprise deployments. A standalone Agent Server can also be run on customer-managed infrastructure.[30][31]

Those modes assign different responsibilities. In self-hosted deployment, the customer operates components such as Kubernetes, PostgreSQL, Redis, networking, secrets, backups, upgrades, and observability. A local development server is not equivalent to a production high-availability setup. Deployment convenience does not remove the need to size provider limits, worker concurrency, checkpoint storage, timeouts, retry budgets, or incident response.

Licensing

The official Python LangChain repository, the LangGraph repository, and the LangChain.js repository use the MIT license.[32][33][34] That permission covers the code in those repositories under their license files. It does not relicense external model APIs, databases, document sources, third-party integrations, or commercial LangSmith services.

Provider and community packages may bring their own dependencies, optional extras, and service terms. Applications should review the license and transitive dependencies of the exact package and version they ship. LangSmith is described by the company as a closed-source platform, and self-hosted use is an enterprise add-on requiring a license key.[1][31]

Operational and security limitations

LangChain can standardize interfaces and supply orchestration primitives, but reliability remains a property of the whole application. Important limitations include:

Prompt injection: Retrieved or tool-supplied text can contain instructions that compete with the application's prompt. Research on indirect prompt injection demonstrated that malicious content placed in data likely to be retrieved can influence outputs and API calls.[35]
Excess authority: An agent with write tools and broad credentials can turn a model error into an external side effect. Least-privilege credentials, allowlists, typed validation, approval gates, and idempotency controls belong outside the model's discretion.
Provider variance: A common interface cannot erase differences in model behavior, content filtering, tool support, latency, rate limits, or data handling.
State growth: Checkpoints, message histories, traces, and retrieval indices can grow without explicit retention and compaction policies.
Replay effects: Resuming a durable workflow can repeat unprotected side effects. Persistence must be paired with replay-safe application design.[26]
Evaluation gaps: Passing a fixed dataset does not establish behavior on unseen users, new tools, adversarial inputs, or provider changes.
Dependency and API risk: Provider integrations change quickly, and published security advisories show that framework utilities themselves can have vulnerabilities. Applications should pin versions, monitor advisories, and test upgrades rather than assuming all 1.x packages have identical risk.[36]

The open-source release policy reserves breaking changes in stable public APIs for major releases, while community integrations and experimental features have weaker guarantees.[37] Semantic versioning reduces planned API churn; it does not guarantee behavioral equivalence, bug-free upgrades, or unchanged third-party services.

Editing: LangChain