5 LangChain GitHub Repos Worth Studying in 2026

Most LangChain application repositories look convincing until I ask one question: what happens when a tool fails halfway through a multi-step run? The answer is usually buried in a notebook, missing entirely, or handled with a broad try/catch that quietly returns a bad answer.

When I design agentic workflows or RAG systems, I study repositories for decisions rather than copy-pasting code. I am looking for how a project models state, retrieves evidence, evaluates output, handles retries, and gets deployed without turning a demo into an operational liability.

These are the LangChain GitHub repositories I would reverse-engineer before starting a serious LLM application.

Update (October 2026): The LangChain ecosystem has moved since this post was first published. LangChain 1.0 and LangGraph 1.0 shipped with a stability commitment: no breaking changes until 2.0. LangChain 1.0 introduced create_agent, built on the LangGraph runtime, and moved legacy functionality to langchain-classic. See the LangChain and LangGraph 1.0 announcement for details. I have updated the sections below where that changes what I would study, and added a short section on Open SWE and a note on the langchain-ai organization itself.

Start with repos that expose the failure path

A useful LangChain reference repository does not just show the happy path. It makes state transitions, tool failures, retrieval quality, and evaluation visible enough that I can adapt the underlying pattern to a production system.

GitHub stars are not my selection criterion. A popular repository can still be a poor architecture reference if its operational assumptions are hidden. The langchain-ai organization hosts a very large number of repositories, so a filter matters more than a popularity count. I use five questions to decide what is worth studying:

I also separate reference code from application code. A reference repository should teach a narrow concept clearly. It does not need complete authentication, multi-tenant permissions, billing, rate limits, migrations, or a polished UI. Those omissions are acceptable as long as I recognize them before building on top of it.

The dangerous move is treating a well-written example as an enterprise AI automation blueprint. It rarely is.

One practical habit: before reading any repository's code, I read its README for what it claims to be, then check the releases page and the last few commits. A repo that is archived or marks part of itself as archival is telling you something important about how to read it, and that honesty is itself a quality signal.

Study LangGraph for durable agent state, not prompts

The LangGraph repository is the first place I look when an LLM workflow needs branching, persistence, approvals, or recovery after a failed run. Its core lesson is that a useful agent is a stateful workflow with model calls inside it, not a model call with a few tools attached.

The README describes LangGraph as a "low-level orchestration framework for building, managing, and deploying long-running, stateful agents." It lists durable execution, human-in-the-loop (inspecting and modifying agent state), memory, LangSmith debugging, and production deployment as core capabilities. That framing is important. The graph is the product architecture. The model is one decision-making component inside it.

The project is also actively released; check the releases page for the current version and the LangChain changelog for what changed. I find resume behavior the most interesting part of the release history, because resuming correctly after an interruption is exactly where durable agent state either works or quietly corrupts a run.

I study four patterns in LangGraph source code and documentation:

1. Explicit graph state State should include more than chat messages. I usually model task status, tool results, source identifiers, retry counts, approval requirements, and error information separately.

2. Nodes with narrow responsibilities A planner should plan. A retrieval node should retrieve. A publishing node should publish only after validation. Combining all of that in one "agent" node creates traces that nobody can reason about.

3. Conditional edges instead of prompt-only routing If a workflow has an objective rule, I encode it in software. For example, if a content item has no verified citations, it goes back to research. I do not ask the model to remember that rule.

4. Checkpoints and interrupts Human approval belongs at an explicit interruption point, not as an afterthought. This is essential for actions with external consequences, such as sending messages, writing CRM data, publishing content, or modifying cloud resources.

A small illustration of the second and third patterns. This is a sketch of the shape, not a drop-in implementation, and the node and field names are my own:

from langgraph.graph import StateGraph, END
from typing import TypedDict

class ContentState(TypedDict):
    topic: str
    sources: list[str]
    draft: str
    citations_verified: bool
    retries: int

def route_after_validation(state: ContentState) -> str:
    # Objective rules live in code, not in a prompt.
    if not state["citations_verified"]:
        return "research" if state["retries"] < 2 else "escalate"
    return "publish"

graph = StateGraph(ContentState)
# graph.add_node("research", research_node)
# graph.add_node("draft", draft_node)
# graph.add_node("validate", validate_node)
# graph.add_conditional_edges("validate", route_after_validation,
#     {"research": "research", "escalate": "human_review", "publish": "publish"})

The retry counter sits in state and the escalation path is explicit. Nobody has to hope the model remembers to stop looping.

BizFlowAI ContentStudio is an autonomous system that researches, writes, optimizes, and publishes content across multiple sites. I design that kind of pipeline as a chain of independently inspectable stages rather than one opaque generation step. That structure makes it possible to find out whether a weak result came from poor source selection, an unreliable model response, or a publishing rule that should never have passed.

Two practical cautions:

• The examples directory is archival. The README-level examples in the LangGraph repo are no longer updated, and current examples and guidance live in the consolidated LangChain documentation. Read the repo for the runtime and its source, and read the docs for current usage patterns.
• langgraph.prebuilt is deprecated. With the 1.0 release, the prebuilt agent functionality moved to langchain.agents. If you are following an older tutorial that imports from langgraph.prebuilt, expect to translate it.

What I would copy from LangGraph is the graph mindset: make progress and decisions observable in state.

What I would skip is the temptation to turn every workflow into a graph. A one-step classification task, a simple extraction job, or a deterministic API transformation does not need agentic AI. A straightforward serverless function with schema validation is cheaper, easier to test, and easier to operate.

Use RAG from Scratch to build the baseline before adding agents

The RAG from Scratch repository is worth studying because it shows the progression from basic retrieval to more advanced retrieval patterns. It contains notebooks that accompany a video series, building from indexing, retrieval, and generation basics. The notebooks are grouped in sets, which makes it easy to follow one concept at a time.

I use it as a reminder that agentic RAG is not the starting point. A measurable retrieval baseline is.

Many teams begin with an agent that can search multiple sources, rewrite queries, critique its own answer, and call five tools. Then they discover their chunks are poorly structured, metadata is incomplete, and the retriever cannot find the answer to a direct question.

I start much smaller:

Question
  -> query normalization
  -> hybrid retrieval
  -> reranking or context selection
  -> grounded answer
  -> citations and trace

Before I add a routing agent, I want answers to these questions:

• Does the corpus contain the answer?
• Does retrieval return the right source in the top results?
• Is the chunk too large, too small, or missing surrounding context?
• Does document metadata support filtering by tenant, document type, date, or permission?
• Can I show the user exactly which sources supported the answer?

The repository is especially useful for comparing retrieval techniques without pretending they are interchangeable. Multi-query retrieval may help when users phrase questions poorly. Parent-document retrieval can preserve useful context when child chunks are small. Query transformation can help, but it also adds model cost and another place for hallucinated intent to enter the pipeline.

For production RAG pipeline design, I generally prefer a hybrid retrieval baseline: lexical retrieval plus vector search, merged with reciprocal rank fusion (RRF). Keyword search handles identifiers, product names, exact policy terms, and error codes well. Vector search handles paraphrases and conceptual similarity. Neither is sufficient alone for many B2B knowledge bases. In my own work this is typically PostgreSQL with pgvector combined with hybrid search (RRF).

A simple RRF merge is often enough to test whether hybrid search improves recall:

RRF score(document) = Σ 1 / (k + rank_from_each_retriever)

The constant k reduces the advantage of a single first-place result. The exact tuning matters less at first than creating a test set that tells me whether retrieval improved.

Here is a minimal, runnable version of the merge so the formula is concrete. The document IDs are made up for the example, and k=60 is a common default rather than a tuned value:

def rrf_merge(rankings: list[list[str]], k: int = 60) -> list[tuple[str, float]]:
    scores: dict[str, float] = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)

lexical = ["doc_err_4012", "doc_policy_7", "doc_faq_2"]
vector  = ["doc_policy_7", "doc_overview_1", "doc_err_4012"]

print(rrf_merge([lexical, vector]))
# doc_policy_7 and doc_err_4012 rise to the top because both retrievers found them.

An exact error-code match (doc_err_4012) that vector search ranked low still survives the merge, which is precisely why I do not rely on embeddings alone.

A caution on freshness: the repository is a companion to a video series, and I could not confirm from the repo page how actively it is maintained. Treat it as a teaching resource for retrieval concepts, then check the current LangChain documentation for the up-to-date API surface before copying any imports.

What I would copy from this repository is its incremental approach. Build naive RAG, inspect it, measure it, then introduce one complexity at a time.

What I would skip is notebook-style operational design. Notebooks are excellent for experimentation. They are not where I want configuration management, secrets, tenant isolation, retry behavior, document ingestion jobs, or scheduled re-indexing to live.

Read Open Deep Research for multi-agent boundaries

The Open Deep Research repository (langchain-ai/open_deep_research) is a useful reference for research-oriented agentic workflows. One important note: the repository is archived and read-only, so read it as a historical reference rather than as a living project. Check its GitHub page for the current status. I study it for decomposition, research loops, source gathering, and synthesis, not because I would deploy its full workflow unchanged.

Research agents are a useful stress test for AI agent development because they reveal where autonomy becomes expensive. A research task can expand indefinitely if the system has no stopping conditions. More searches can produce more sources, more contradictions, more context, and more opportunities for the model to drift away from the original question.

The architecture lesson is simple: give every agentic loop a budget.

That budget can include:

• Maximum number of tool calls
• Maximum research iterations
• Maximum sources retained for synthesis
• Deadline per task
• Token budget per run
• A required confidence or evidence threshold
• An escalation path when evidence is weak

Without those constraints, "self-improving" can become "self-extending." I have seen this problem in content and SEO automation systems. The workflow needs enough room to search, compare, and revise. It also needs a clear definition of done.

For a research pipeline, I separate at least four concerns:

The crucial distinction is between a source that was visited and a source that was used as evidence. A search trace is not proof. In a production LLM application, I store the final selected evidence separately from all tool activity. That makes later audits, user-facing citations, and quality analysis much easier.

A concrete way to enforce the budget idea is to carry it in graph state and check it in a routing function, the same way as the retry counter earlier:

class ResearchState(TypedDict):
    question: str
    iterations: int
    tool_calls: int
    evidence: list[dict]   # selected, citable sources only

MAX_ITERATIONS = 4
MAX_TOOL_CALLS = 12

def should_continue(state: ResearchState) -> str:
    if state["iterations"] >= MAX_ITERATIONS or state["tool_calls"] >= MAX_TOOL_CALLS:
        return "synthesize_or_escalate"
    if len(state["evidence"]) >= 3:
        return "synthesize"
    return "research_more"

The numbers there are illustrative round values for the example, not recommendations. The point is that the stopping condition lives in code and is testable.

What I would copy is the deliberate separation of planning, research, and writing.

What I would skip is unconstrained delegation. Multiple agents do not automatically mean better output. Each extra agent creates another context boundary, another model call, another failure mode, and another billable unit of latency. I use multiple roles only when they create a meaningful verification or specialization benefit.

Use the LangSmith Cookbook, and agentevals, to make evals part of delivery

The LangSmith Cookbook (langchain-ai/langsmith-cookbook) is the repository I would study before claiming an LLM feature is ready for users. It is archived and read-only, so I treat it as a still-useful collection of recipes for tracing, datasets, and evaluation rather than as an actively maintained project; verify its status on GitHub. Its practical value is not a particular evaluator. It is the discipline of connecting traces, datasets, experiments, and decisions. That discipline is what turns raw LLM observability into something you can act on.

For deterministic software, a unit test can often establish correctness. For generative AI, output quality is probabilistic and contextual. I need more than one kind of evaluation.

My minimum RAG evaluation stack for a RAG or agent workflow has four layers:

1. Contract tests Does the system return valid structured output? Does a tool call conform to its schema? Are required fields present?

2. Retrieval tests For a known question, did the expected source appear in the retrieved context? This is often the most valuable test in a RAG system.

3. Task-quality tests Did the answer address the question, follow the requested format, and remain grounded in available evidence?

4. Production trace review What are actual users asking? Which tool calls fail? Which documents are retrieved repeatedly but lead to poor answers?

I do not start with an LLM-as-a-judge score and call the system evaluated. A judge can be useful, especially for ranking large output sets, but it should be calibrated against examples a domain expert has reviewed.

A small but carefully curated dataset is more useful than a giant synthetic one. For an internal knowledge assistant, I might start with a few dozen questions that represent real operational requests: direct policy lookups, ambiguous questions, questions with no answer in the corpus, multi-document questions, and permission-sensitive requests.

The "no answer" cases matter. A helpful assistant must know when to say it cannot verify something. In many business settings, a confident unsupported answer is worse than an incomplete one.

Evaluating the path, not just the answer

For agents, the final text hides most of what went wrong. This is where the agentevals repository is a useful complement to the cookbook. It offers ready-made evaluators for agent trajectories, meaning the sequence of tool calls and messages, with several matching modes: strict, unordered, subset/superset match, LLM-as-judge, and graph trajectory.

Those modes map to real questions:

• Strict match: must the agent call the same tools in the same order? Right for compliance-style flows.
• Unordered match: does order not matter, as long as the same tools were used?
• Subset/superset match: did the agent avoid extra tool calls, or at least call the required ones?
• LLM-as-judge: is the trajectory reasonable when no single reference path exists?
• Graph trajectory: useful when the agent is a LangGraph graph and you care about node transitions.

Two honest caveats. It is a much smaller project than the headline repos, and its quickstart relies on an LLM judge configured through LangChain chat model integrations. Check the live README for the current default before copying the quickstart. Its value to me is the vocabulary of trajectory matching, which I can reimplement against my own traces if needed.

What I would copy from both repositories is the experiment loop:

Change one variable
  -> run against a fixed dataset
  -> inspect failures and traces
  -> compare against the previous version
  -> decide whether the change ships

What I would skip is optimizing a single aggregate score. A small improvement in an average metric can conceal a serious regression for a high-value workflow. I segment results by question type, user role, source type, and failure category.

Read Open SWE for async agents, sandboxes, and approval boundaries

The Open SWE repository is the newest addition to my reading list. It describes itself as an open-source software factory built on Deep Agents. It uses LangGraph for durable execution and thread state, and it runs coding work in persistent per-thread Linux sandboxes. It is invoked from surfaces such as Slack, Linear, and GitHub. LangChain's own write-up, Open SWE: an open-source framework for internal coding agents, is a good companion read.

I am not suggesting you build a coding agent. I study it because it is a worked example of several production concerns at once:

• Durable execution with real consequences. A coding agent that opens pull requests is an agent with external side effects. Seeing how thread state and durable execution are combined is directly transferable to CRM, ticketing, or publishing agents.
• Isolation per task. Giving each thread its own sandbox is a concrete answer to "where does untrusted tool execution happen?"
• A curated toolset. LangChain's write-up on Open SWE describes a "curated, not accumulated" toolset. That is the right instinct: every added tool is more attack surface and more ways for the model to choose badly.
• Asynchronous invocation. Work is triggered from where people already are and completes in the background, which matches the async-job pattern I recommend in the deployment section below.

One detail deserves attention because it is easy to miss: the repository notes that its approval prompts guard detected Git pushes, not every possible shell or API write. That is an important lesson about bounded tools. An approval gate only protects the actions it can recognize. If your agent has a general shell or an HTTP client, "human approval before writes" is a weaker guarantee than it sounds, and you should design the sandbox and credentials so that the dangerous action is impossible rather than merely prompted.

A second caution on versions: Open SWE has changed substantially over time, and older descriptions of it differ from the current README. When you read blog posts or videos about it, check their date against the current README.

What I would copy is the combination of durable thread state, per-task isolation, and a deliberately small toolset. What I would skip is assuming its approval prompts are a complete permission model for your own system.

Learn deployment boundaries from LangServe, then build beyond them

The LangServe repository (langchain-ai/langserve) is useful for studying how LangChain runnables become HTTP endpoints, how streaming fits into an API contract, and how input and output schemas can be exposed. Be aware, though, that LangServe is deprecated: its README carries a deprecation notice, and new projects should use LangSmith Deployment (the LangGraph platform) instead. I treat LangServe purely as a historical deployment reference, not as a production platform. Verify the current recommended path in the official LangChain docs before choosing a deployment approach.

The biggest deployment mistake I see in LLM application development is exposing the agent directly as an endpoint and calling that architecture complete. A production service needs boundaries around the model workflow.

At minimum, I want these components separated:

Client UI or calling system
  -> authenticated API layer
  -> workflow orchestrator
  -> model and tool services
  -> durable state, vector store, and audit data
  -> observability and evaluation pipeline

For a serverless AI architecture, some of these may be implemented with AWS Lambda, API Gateway, EventBridge, SQS, Step Functions, PostgreSQL, and object storage. The technology choice is less important than the operational separation.

I ask several deployment questions before choosing a pattern:

• Is the user waiting synchronously for the result?
• Can the workflow run for minutes, or must it finish in seconds?
• Does a failure need automatic retry, manual review, or both?
• Can the action be safely repeated without duplicate side effects?
• Where are API keys stored and rotated?
• How do I enforce tenant-level retrieval and tool permissions?
• Which trace fields could contain sensitive data?

For a chat assistant, streaming a partial response may be appropriate. For document ingestion, batch classification, report generation, or publishing automation, asynchronous jobs are usually safer. The API should return a job identifier, while a worker handles the long-running workflow and writes durable progress.

A minimal shape for that async contract, as a sketch:

POST /jobs            -> 202 Accepted { "job_id": "abc123" }
GET  /jobs/abc123     -> { "status": "running", "step": "validate", "attempt": 2 }
GET  /jobs/abc123     -> { "status": "needs_approval", "pending_action": "publish" }
GET  /jobs/abc123     -> { "status": "done", "result_ref": "..." }

The needs_approval state is the HTTP-level counterpart of a LangGraph interrupt. Designing the API so that "waiting for a human" is a first-class status keeps long-running agents from looking like hung requests.

That design is not glamorous, but it is how unattended automation stays unattended. My AWS and Zendesk SLA integration succeeded because the workflow was designed around events, failure handling, and operational ownership, not around a single request-response interaction.

How the five fit together

If you want a one-glance map of what to read for which problem:

What I'd do before building a LangChain application

I would not clone all of these repositories and combine them. I would choose one reference architecture based on the actual problem, then prove the riskiest assumption with a narrow AI proof of concept.

My sequence would be:

1. Write five real user tasks, including one that should be refused or escalated.
2. Build a retrieval or tool-use baseline without an agent loop.
3. Create a small evaluation dataset before tuning prompts.
4. Add LangGraph only when the workflow needs state, branching, retry, approval, or resumability.
5. Add research or multi-agent patterns only when a single controlled workflow cannot meet the quality target.
6. Deploy asynchronous work separately from interactive requests.
7. Review real traces weekly and turn recurring failures into tests.

That process is slower than starting with a flashy autonomous agent demo. It is much faster than debugging a system that has no baseline, no evidence trail, and no idea why it failed.

The repositories above are valuable because they make important design choices visible. Study the state model, the retrieval assumptions, the evaluation loop, and the deployment boundary, then adapt those ideas to the system you actually need to operate.

If you are designing an AI workflow, RAG system, or agentic application with real operational consequences, I write more about the engineering decisions behind them on this blog. You can also reach me through lazar-milicevic.com/#contact.