LangChain Tutorial 2026: Complete Guide for Python Developers

LangChain has undergone significant evolution since its early days of complex chain classes and verbose configuration. The modern LangChain ecosystem in 2026 is organized into focused packages: langchain-core provides the foundational abstractions like Runnables, prompt templates, and output parsers; langchain-openai, langchain-anthropic, and similar packages provide model integrations; and langchain-community houses third-party tool and retriever integrations. The most important shift is the adoption of LangChain Expression Language (LCEL) as the primary way to build chains. LCEL uses a pipe operator syntax that reads like a data pipeline: input | prompt | model | parser. Every component in an LCEL chain implements the Runnable interface, which gives you .invoke() for single inputs, .batch() for multiple inputs, .stream() for token-by-token streaming, and .ainvoke() for async execution, all for free. Another major change is the separation of simple chains from complex agentic workflows. LangChain itself handles linear and branching chains: RAG pipelines, summarization chains, structured extraction, and similar well-defined flows. For stateful, multi-step agent workflows with cycles and human-in-the-loop patterns, the team recommends LangGraph, which builds on LangChain's abstractions but adds a graph-based state machine. Understanding this division is crucial for choosing the right tool: use LangChain when your flow is a DAG (directed acyclic graph), and use LangGraph when you need cycles or persistent state.

LCEL chains are built by composing Runnable objects with the pipe operator. The simplest chain connects a prompt template to a model. A ChatPromptTemplate.from_messages() creates a prompt with system and human message templates. Piping this into ChatOpenAI() creates a chain that formats the prompt and sends it to the model. Adding StrOutputParser() at the end extracts the text content from the model's response. The real power of LCEL emerges when you add branching and parallel execution. RunnablePassthrough passes the input through unchanged, useful for including the original question alongside processed context. RunnableParallel runs multiple chains simultaneously, for example retrieving from a vector store while formatting the question. RunnableLambda wraps any Python function into a Runnable, letting you insert custom logic anywhere in the chain. Conditional branching uses RunnableBranch, which evaluates conditions and routes input to different chains. For example, you might route simple factual questions to a fast model and complex reasoning questions to a more capable model. This pattern is essential for building cost-effective production systems. Every LCEL chain automatically supports streaming, which is critical for user-facing applications. When you call chain.stream(input), tokens flow through the entire pipeline as they are generated, giving users instant feedback. You also get built-in retry logic with .with_retry(), fallbacks with .with_fallback(), and rate limiting. These production features come free with every LCEL chain, which is why the community has largely abandoned the older chain classes in favor of LCEL composition.

Tool calling is the mechanism that lets LLMs interact with external systems. In LangChain 2026, you define tools using the @tool decorator on Python functions. The decorator extracts the function's name, docstring, and type hints to create a schema that the LLM can understand. When you bind tools to a model using model.bind_tools([tool_list]), the model can choose to call one or more tools in its response. The tool call flow works as follows: the model returns a message with tool_calls containing the function name and arguments, you execute the function with those arguments, and you send the result back to the model as a ToolMessage. LangChain handles this serialization and deserialization automatically. For complex tools, use Pydantic models as argument types to get rich validation and nested schemas. Structured outputs are a related but distinct feature. Instead of getting free-form text, you can force the model to return data matching a specific schema. Call model.with_structured_output(PydanticModel) to get a chain that always returns an instance of your Pydantic model. This is invaluable for extraction tasks: pulling structured data from unstructured text, classifying inputs into categories, or generating configuration objects. One pattern that combines both features is tool-augmented structured output: define a tool that the model calls to collect information, then use structured output to format the collected information into a clean schema. This two-phase approach produces more reliable results than trying to do everything in a single generation step, because the model can iteratively gather the information it needs before committing to a final output.

A production-quality RAG chain in LangChain goes well beyond the basic retriever-prompt-model pattern. Start with a query analysis step that uses structured output to extract the user's intent, entities, and any filters they specified. For example, 'Show me sales reports from Q4 2025' should extract intent='retrieve_report', time_filter='Q4 2025', and domain='sales'. Use these extracted parameters to configure your retriever dynamically. LangChain's retriever abstraction supports metadata filtering, so you can pass the time filter directly to your vector store query. Combine semantic search with keyword search using an EnsembleRetriever that merges results from a vector store and a BM25 index, giving you the best of both approaches. After retrieval, add a re-ranking step. The Cohere re-ranker or a cross-encoder model from sentence-transformers scores each retrieved document against the original query and re-orders them by relevance. This dramatically reduces noise in the context passed to the LLM. The generation step uses a carefully crafted prompt that instructs the model to cite sources, handle cases where the context is insufficient, and format the response appropriately. Add a citation parser that extracts source references from the response and validates them against the retrieved documents. Finally, wrap the entire chain with LangSmith tracing. Every step, the query analysis, retrieval, re-ranking, and generation, is logged with inputs, outputs, and latency. This observability is non-negotiable in production: when a user reports a bad answer, you need to trace exactly which step failed and why. The chain should also include fallback logic: if the primary retriever times out, fall back to a cached result or a graceful error message.

After building LangChain applications for production, several best practices emerge consistently. First, always pin your langchain package versions. The ecosystem moves fast, and a minor version bump can change behavior in subtle ways. Use a lockfile (pip-compile or poetry.lock) and test upgrades explicitly. Second, separate your prompt templates from your code. Store them in YAML or JSON files, or use LangChain Hub for versioning and sharing. This lets you iterate on prompts without redeploying code, and it enables A/B testing different prompts in production. Third, use async everywhere in web applications. LangChain's async support (ainvoke, abatch, astream) is mature and significantly improves throughput when your application handles multiple concurrent requests. A FastAPI endpoint using async LangChain chains can handle 10x more concurrent users than synchronous code. Common pitfalls to avoid: do not put complex logic inside prompt templates. If you find yourself writing Python-like conditionals in Jinja2, extract that logic into a RunnableLambda step. Do not ignore token counting; use callbacks or middleware to track token usage per request and set hard limits to prevent runaway costs. Do not build complex agents with plain LangChain; if your workflow has loops, conditional branching based on LLM output, or persistent state, switch to LangGraph. Finally, test your chains. LangChain's unit testing support lets you mock LLM responses and verify that your chain logic works correctly. Integration tests with real models should run against a golden test set. Automated evaluation using RAGAS or LangSmith's evaluation framework catches regressions before they reach production. A mature LangChain project has test coverage on par with any other production software.