Which LangChain or LangGraph patterns are most valuable to learn early, and why?

The five patterns that prevent expensive rewrites

This is deliberately a short list. Each pattern prevents a familiar failure mode, and each one is useful outside LangChain.

The order matters. A structured router without clear state still leaves a confused program. An agent with many tools but no limits expands its failure surface. Checkpointing and evaluation become valuable after there is a concrete workflow to save and measure.

Build this one project: a support-triage draft assistant

Use a fictional SaaS product with public or synthetic support articles. A user submits a message such as, “My export keeps failing and I need a status update on ticket 1942.” The application must:

1. classify the request as an FAQ question, ticket-status request, or human escalation;
2. search a small approved knowledge base for FAQ questions;
3. look up a ticket through a read-only fake API when an ID is present;
4. draft a response with source references;
5. pause for a human to approve, edit, or reject any request to create or update a ticket.

This is intentionally not a general assistant. It gives you one ambiguous decision, two constrained tools, one consequential action, a reason for state, and clear ways to test failure. It also avoids pretending that a model should independently act on legal, medical, financial, or child-safety matters.

What the state should make visible

State is simply the named record shared by the steps of a workflow. Do not use it as a dumping ground for an ever-growing transcript. Store only what a later step needs to make a correct or auditable decision.

LangGraph's design centers on nodes that read and update shared state, with transitions between nodes. Its current guidance is to start by mapping a process into discrete steps and then connect them through shared state. Thinking in LangGraph That is the pattern to learn, even if the first version is ordinary Python functions rather than a graph.

Use deterministic routing before agentic routing

For this project, write deterministic rules first:

• If the request contains a valid ticket ID and asks for status, call the read-only ticket tool.
• If the request asks a known FAQ and retrieval returns a relevant source, compose a cited answer.
• If it describes a security incident, account lockout, or unclear issue, escalate to a person.

Only use the LLM classifier for the boundary cases, such as whether “I was charged twice” is a billing FAQ, a ticket-status request, or an escalation. Its output should be a schema, not an open-ended sentence. LangGraph's routing example uses structured model output as routing logic, and its graph API supports conditional transitions from the resulting decision. Routing workflow documentation

This is the practical decision rule:

If a rule can be expressed clearly, is safety-sensitive, or must be perfectly reproducible, use code. If the input is varied and semantic judgment is the value, use a model with a constrained output schema.

For example, a model may decide between the three permitted categories. Your code must decide that a ticket ID has the required format, that the caller is authorized to read it, and that a “create ticket” operation cannot proceed without approval.

Make model decisions machine-readable

Plain language is the right final interface for a person. It is usually the wrong interface between program steps. Structured output means requesting a JSON-like object that conforms to a schema such as a Pydantic model or dataclass, so application code can validate and act on it.

# Illustrative schema, not a complete application
class Route(BaseModel):
    target: Literal["faq", "ticket_status", "human"]
    reason: str
    confidence: float

The important part is not the exact fields. It is that target cannot become “maybe probably billing,” a spelling variation that breaks a branch, or prose that someone has to parse with another model call. Require a fallback like human whenever confidence is low or the result is invalid.

Current LangChain Python documentation says create_agent(..., response_format=...) captures and validates a structured result in the final agent state's structured_response key. Passing a schema type lets LangChain choose the provider-native or tool-calling strategy based on model capabilities. Structured output This is version-sensitive guidance: pin your dependencies and recheck the documentation for your installed LangChain release, model provider, and language binding before copying an API signature.

Do not confuse valid JSON with true correctness. Schema validation can show that target="faq" is permitted. It cannot prove that the request really should have been routed to FAQ. That is why the evaluation set later needs examples for both format and routing accuracy.

Bound every tool loop before adding more tools

Tools are the boundary between model-generated intent and the rest of your system. Treat each tool like a narrow API contract:

• Give it a clear verb and description.
• Define typed, validated arguments and stable return data.
• Give it least-privilege credentials. A search tool should not also be able to update customer records.
• Set a timeout and decide which failures are safe to retry.
• Make writes idempotent, so a resumed or retried run cannot create duplicate work.
• Return a useful, non-secret error that lets the workflow escalate rather than hallucinate success.

For the triage assistant, search_kb(query) and get_ticket(ticket_id) are reads. create_ticket_draft(summary) only returns a proposed draft. A separate submit_ticket(draft_id) is a write and must have deterministic authorization plus human approval. Splitting that action is more reliable than a single tool with an execute: true flag.

Put a budget on model and tool calls

An agent loop normally lets a model choose tools, observes results, then calls the model again until it stops. The loop needs an explicit exit budget. Current LangChain middleware includes ModelCallLimitMiddleware and ToolCallLimitMiddleware; their documented run_limit bounds a single invocation, while thread-level limits persist across a thread and require a checkpointer. Prebuilt middleware

# Current documented Python names as of 2026-08-26.
# Use your provider's supported model identifier and pin package versions.
from langchain.agents import create_agent
from langchain.agents.middleware import (
    ModelCallLimitMiddleware,
    ToolCallLimitMiddleware,
)

agent = create_agent(
    model="provider:model-name",
    tools=[search_kb, get_ticket],
    middleware=[
        ModelCallLimitMiddleware(run_limit=4, exit_behavior="end"),
        ToolCallLimitMiddleware(tool_name="search_kb", run_limit=2),
    ],
)

The values 4 and 2 are a hypothetical project budget, not universal settings. Choose limits from the task, cost, latency target, and recovery path. If the limit is reached, return a transparent outcome such as, “I could not verify this in the available steps. Please try a narrower question or contact support,” rather than silently starting another loop.

For a standard agent loop, LangChain middleware is the right extension point for limits, retries, guardrails, PII handling, and logging. When the surrounding topology is more than a standard loop, such as a classifier routing to distinct deterministic and agentic steps, the current docs show that the compiled agent can be used as a node in a larger StateGraph. Middleware overview

Use persistence when a run must survive a pause

“Memory” is often used imprecisely. A chat transcript in a prompt, durable workflow state, and user preferences are different things. Learn checkpointing for the second of these, not as a way to add limitless history.

Use a checkpointer when the run needs to:

• pause for a person to review a tool action;
• resume after a process failure or restart;
• continue a multi-turn workflow under the same thread ID;
• replay a stateful run for debugging.

LangGraph's persistence layer saves graph state as checkpoints at each step, organized by thread. The official documentation identifies human review, conversational memory, time travel debugging, and fault tolerance as uses, and distinguishes InMemorySaver for experimentation from separately installed SQLite or Postgres checkpointers for more durable use. LangGraph persistence

For the project, use an in-memory checkpointer while learning. Before a real deployment, decide what state can be stored, how long it is retained, who can inspect it, how it is deleted, and whether the state includes personal or confidential information. Persistence is a data-governance choice as well as a technical feature.

Pause writes for a human decision

For a real action, a model's intention should not equal execution. LangChain's current HumanInTheLoopMiddleware can interrupt selected tool calls and support approve, edit, or reject decisions. It uses LangGraph persistence, so a checkpointer and a thread ID are required to pause and resume safely. Human-in-the-loop middleware

In the triage assistant, show a review card that displays:

Proposed action: submit_ticket
Ticket summary: Export fails when PDF is selected
Evidence used: kb-export-4, ticket lookup 1942
Available choices: Approve | Edit summary | Reject and escalate

Keep side effects after approval idempotent. A resumed interrupt can re-run code in the containing node, so a non-idempotent write before the interruption can be performed twice. This is a version-independent engineering rule, and the current LangGraph interrupt documentation calls it out explicitly. LangGraph interrupts

Trace first, then evaluate a small set of cases

Tracing answers, “What happened on this request?” Evaluation answers, “Did this version perform better on cases we care about?” They work together but are not interchangeable.

For the project, record a redacted trace with request ID, route, retrieved source IDs, tool names and durations, final outcome, error class, model/provider configuration, and whether human approval was required. Do not place credentials, raw private documents, or unnecessary personal data in logs.

Start an offline dataset with 20 examples, not 2,000:

Score what you can verify deterministically: valid output shape, correct route, no write without approval, allowed number of tool calls, required citation, and correct failure state. Add human review for quality and completeness. Use an LLM-as-judge only with a clear rubric and spot checks, because a judge can be wrong too.

LangSmith's current evaluation docs separate offline evaluation on curated datasets from online evaluation of production interactions. Its documented loop is dataset, evaluators, experiment, and analysis, then feeding meaningful production failures back into the dataset. LangSmith evaluation The documentation also recommends starting with manually curated examples for each critical component, including correct tool selection and tool arguments for agents. Evaluation concepts

Do not wait for a production incident to create your first regression case. When a local test exposes a bad route or unsafe draft, keep that input in the dataset permanently and make the fix prove itself against the rest of the set.

When LangChain, LangGraph, or plain code is the better fit

Choosing less framework is often the durable pattern.

The table is not an argument that LangGraph is “better.” LangGraph's own overview says it is low level and recommends higher-level LangChain agents for people starting with common tool-calling loops. LangGraph overview If your workflow is a readable 40-line Python function with tests, preserve that advantage.

Common early mistakes and the correction

A seven-session learning plan

Each session can be 60 to 90 minutes. Stop once the project is useful and inspectable. Do not turn it into a broad agent platform.

1. Map the workflow. Write the routes, state fields, tools, safe fallback, and action boundary on one page.
2. Build deterministic paths. Implement FAQ and ticket-status functions with fake data and ordinary tests.
3. Add a structured classifier. Test valid routes, malformed outputs, and low-confidence escalation.
4. Add retrieval evidence. Save document IDs, return citations, and add no-answer cases.
5. Add bounded tools. Validate inputs, set call budgets and timeouts, and demonstrate a tool failure.
6. Add a checkpointed approval. Use an in-memory saver locally, a thread ID, and an approval/edit/reject flow. Test resume twice.
7. Trace and evaluate. Run the 20-case suite, inspect three traces, fix one actual failure, and record what regressed or did not.

At the end, you should be able to answer five questions about any request: What state did it start with? Why did it take this path? Which external action occurred? Where could a person intervene? How do we know the change helped? If you cannot answer one, that missing answer is usually more important than another framework feature.

Version-sensitive implementation notes

LangChain and LangGraph evolve quickly. The names below were verified in the official Python documentation on 2026-08-26:

• LangChain documents create_agent as its higher-level agent harness, with middleware passed through middleware=[...]. LangChain overview
• Current structured-output documentation names response_format, ProviderStrategy, ToolStrategy, and final-state key structured_response. Structured output
• Current middleware documentation names ModelCallLimitMiddleware, ToolCallLimitMiddleware, and HumanInTheLoopMiddleware. Prebuilt middleware Human-in-the-loop
• Current LangGraph examples use StateGraph, InMemorySaver, interrupt, Command, and a configurable thread_id. LangGraph overview Interrupts

Before implementation, pin the exact langchain and langgraph package versions, write a small smoke test for the model provider you use, and rely on the documentation that matches that release. Do not copy snippets that use deprecated package paths or an old agent abstraction merely because they rank highly in search.

Limitations and safety boundaries

• These patterns improve inspectability and control. They do not make a model's classification factually correct, remove the need for tests, or solve poor source data.
• Human approval should be designed around who is authorized and accountable. A button labeled “approve” is not sufficient access control.
• For legal, medical, financial, employment, or child-related workflows, obtain appropriate domain, privacy, security, and compliance review. A portfolio demo should use synthetic or properly licensed public data and should not automate consequential decisions.
• Traces and checkpoints can contain sensitive inputs, tool results, and model outputs. Redact and minimize data before sending it to any observability or persistence service.
• Framework capabilities and names are version-sensitive. The direct URLs above are the authority for the verified Python API shape, not old tutorials or social-media snippets.