LangChain

LangChain is the framework everyone reaches for first — the thing that made "an app on top of an LLM" a normal thing to build. This page is the orient-and-decide surface: what it is, where it wins, and why the house default sits one altitude up. Official docs at docs.langchain.com own the API contracts.

Not in GL production. The house default is DSPy at the programming-model altitude, Neo4j for state, Ollama for local inference. This page is the honest map of the foil — LangChain is where you land the moment an integration LangChain already ships beats writing it yourself.

What it is

A Python (and TypeScript) framework for building LLM applications. Created by Harrison Chase; released by LangChain, Inc.; MIT licensed; pip install langchain. As of the 1.x line the monorepo is split into layered packages:

• langchain-core — the base abstractions and the runtime that joins them: messages, prompts, tools, output parsers, and the Runnable interface that everything implements. This is the stable contract.
• langchain — the common building blocks: agents (create_agent), chains, retrievers, MCP wiring. In 1.x these moved to top-level exports, and LangGraph became a formal dependency — a signal that agentic workflows are now central.
• langchain-community — third-party integrations implementing the core interfaces. The long tail of the 600+ catalog lives here.
• Partner packages — the most-used integrations got dedicated, provider-maintained packages: langchain-openai, langchain-anthropic, langchain-ollama, langchain-aws, langchain-google-genai, and more.

The glue is LCEL (LangChain Expression Language) — the pipe operator (prompt | model | parser) composes any Runnables into a chain that streams, batches, and runs async for free. The pitch: each messy part of an LLM app — provider wrappers, retrievers, memory, output parsing, agent loops — is a class you swap in, and the integration is probably already written.

When to use it

Reach for it when:

• You need an integration that already exists — a specific vector store, loader, tool, or provider LangChain ships and you don't want to write from scratch. The catalog is the moat.
• The wording is the product and you want explicit, hand-owned control of every token in the prompt — the opposite of "let the compiler write it."
• You're prototyping a one-off — a chain you'll run twice and throw away, where an optimization loop is overhead you don't need.
• The team already knows LangChain. On a deadline, familiarity is a real edge.
• You want the streaming / batching / async ergonomics of the Runnable interface without building them.

Skip it when:

• The program will live and quality has to be measurable — that's where DSPy's typed signatures + compiler earn their keep over hand-tuned prompt strings.
• You want LLM calls to survive a model swap — a wall of prompts tuned to one model's quirks doesn't; a typed contract you re-compile does.
• The job is document-layer RAG and nothing else — LlamaIndex's loaders / node parsers / query engines are more ergonomic for that specific shape.
• The job is stateful multi-actor orchestration — that's LangGraph, which is separable from LangChain-the-toolkit and can be adopted on its own.
• A DSPy-first codebase already exists and works — mixing paradigms is a dependency tax without a clear win.

At a glance

Core primitives

• Runnable — the universal interface. .invoke(), .stream(), .batch(), plus async variants. Everything composable implements it; LCEL is just sugar over it.
• Prompt templates — ChatPromptTemplate, PromptTemplate. Strings with holes; you author the instructions and decide the wording.
• Model wrappers — ChatOpenAI, ChatAnthropic, ChatOllama, etc. A common message interface across providers.
• Output parsers — StrOutputParser, PydanticOutputParser, structured-output helpers. The "turn text back into a type" seam.
• Retrievers + vector stores — pluggable backends (pgvector, Chroma, Qdrant, Pinecone, and dozens more) behind one Retriever interface.
• Memory — conversation buffers and summaries for multi-turn state.
• Agents — create_agent (LangGraph-backed in 1.x) for tool-calling loops.

Distribution

• Framework — open-source, MIT, pip install langchain. The whole toolkit is free; this is what any GL build would use.
• LangGraph — the orchestration layer for stateful, multi-actor, human-in-the-loop workflows. Open-source; separable — adoptable without the rest of LangChain. See LangGraph.
• LangSmith — the observability + eval platform (traces, datasets, monitoring). Hosted, commercial, closed-source. Separable, and the paid surface. See LangSmith. GL's self-hosted equivalent is Langfuse.

How to integrate

If a GL build needs LangChain (usually for one integration, not the whole paradigm), the à-la-carte order is:

1. Import narrowly. Pull the one partner package you need (langchain-ollama, a vector-store integration) — not the whole langchain meta-package. Keep the surface small.
2. Isolate behind an interface. Wrap the LangChain call in a function with a typed signature (input → output). The rest of the codebase talks to that boundary, not to LangChain internals — so the inside can be swapped later.
3. Compose with LCEL if it's genuinely a chain. retriever | prompt | model | parser. For a single call, skip the pipe — a plain function call is clearer.
4. Keep the reasoning in DSPy. Let LangChain do the plumbing it's good at (the loader, the connector, the streaming), and let a DSPy module own the actual prompt-and-parse step. LangChain moves bytes; DSPy owns the contract.
5. Point observability at Langfuse. If you trace the chain, use the Langfuse callback (self-hosted) rather than reaching for LangSmith — same visibility, no vendor, no new bill.

The rule of thumb: use LangChain for the connector, not the cognition. The moment the prompt matters and has to be measured, that step belongs in DSPy.

In the GL stack

Concrete places LangChain could slot into the three active GL products. None are shipped, and in every case the house default (DSPy for the brain, Neo4j for state, Ollama for inference) does the work — LangChain shows up only where its integration catalog beats hand-rolling.

builddaily.io

• Loader shortcut for the chat-bridge corpus. If the resources/posts corpus grows to source types with no local loader, langchain-community loaders can read them into documents — then hand the chunks to a DSPy answer module. Plumbing from LangChain, cognition from DSPy.
• Not the answer path. The chat-bridge's actual generate-and-parse step stays DSPy-first; LangChain would only ever be the read layer, isolated behind an interface.

paiddaily.io

• Connector for an exotic data source. If a catalyst feed or venue API already has a LangChain integration, using it beats writing a client. The classification of what comes back is still a DSPy module against a typed signature — not a LangChain prompt template.
• No LCEL in the hot path. The Pendle / Aerodrome reasoning is measured and compiled; that's the opposite of a hand-authored chain.

sagedaily.io

• Nothing compelling today. The reading pipeline (deck draw → chart compute → DSPy generation) has no LangChain-shaped gap. The astrology/tarot canon is a LlamaIndex RAG question if anything, not a LangChain one. Listed here for completeness and honesty: this is where LangChain doesn't earn a slot.

Gotchas

• Abstraction churn. LangChain has restructured its packages more than once (the core/community split, then the 1.x consolidation and LangGraph dependency). Deprecations like LLMChain in favor of LCEL land regularly. Pin versions; budget a re-pin per upgrade.
• The abstractions leak. When a chain misbehaves, the failure is often buried inside a Runnable composition rather than in code you wrote. Debugging means reading LangChain internals — the tax of the convenience.
• Prompts are still hand-tuned. LCEL composes the pipeline, but the prompt template is a string you tune by eye. There's no compiler in the box — that's a DSPy idea, not a LangChain one.
• Meta-package bloat. pip install langchain pulls a wide dependency tree. Prefer the narrow partner package for the one integration you actually need.
• "Easy demo, hard production" gap. Hello-world is ten lines; a production chain (structured output, retries, eval, cost control) is still real engineering. The framework removes plumbing, not judgment.

Risks

• Paradigm lock-in spreads quietly. Once chains, agents, and memory are all LangChain-flavored, the framework threads through the whole app. Loaders port easily; deeply-composed LCEL chains and agent graphs accrete framework-specific shape. Keep the application interface (input → output) framework-agnostic so the inside stays swappable.
• The prompts don't survive a model swap. Chains hand-tuned against one model's quirks need re-tuning on the next model. A typed, compiled DSPy program re-compiles instead. This is the central reason the house stance is DSPy-first — not that LangChain is bad, but that it optimizes for a different property.
• LangSmith is the pricing tier. The framework is free, but the paved path nudges toward LangSmith for observability. Route traces to self-hosted Langfuse to keep the surface free and the data local.
• Velocity vs. measurability. LangChain gets you to a working demo fast; that speed can paper over the absence of an eval loop. Fast-to-demo is not the same as good-and-defensible.

Alternatives

Related

• DSPy — the programming-model counterpart and house default. The essay walks the altitude difference in full.
• LangGraph — LangChain's orchestration layer; separable from the toolkit and adoptable on its own.
• LangSmith — LangChain's hosted observability + eval platform; the paid surface. GL routes traces to self-hosted Langfuse instead.
• LlamaIndex — the document-layer sibling; the better fit when the job is RAG over a corpus.