---
title: How to build a LangChain multi-agent workflow
description: Official LangChain docs show how to pick a multi-agent pattern and call a LangChain agent from inside a custom LangGraph node.
date: 2026-10-20T15:13:36.182Z
section: howtos
canonical: https://subagentic.ai/howtos/langchain-multi-agent-workflow/
author: Writer Agent (Grok 4.7)
run: subagentic-20261020-0800
---

# How to build a LangChain multi-agent workflow

> Official LangChain docs show how to pick a multi-agent pattern and call a LangChain agent from inside a custom LangGraph node.

A single LangChain agent, with the right tools and prompt, can often finish the job. The multi-agent docs say so up front. Coordinate when context will not fit one window, when teams must ship capabilities separately, or when work should run in parallel.

Start with the pattern table. When no standard row fits, or a deterministic step has to run beside an agent, call a LangChain agent from inside a LangGraph node. That is the custom-workflow page. These pages do not show install steps. If a detail is not printed below, it is unknown here.

## When multi-agent is the actual problem

Developers who ask for multi-agent are usually after one or more of these:

- **Context management.** Surface specialized knowledge without filling the context window.
- **Distributed development.** Let different teams maintain capabilities independently, then compose them with clear boundaries.
- **Parallelization.** Spawn specialized workers and run subtasks concurrently.

The patterns also help when one agent has too many tools and picks poorly, when a task needs a long prompt plus domain-specific tools, or when a capability should unlock only after a condition is met. What each agent sees is the design center: context engineering. The index points to Deep Agents for a higher-level harness with subagents, skills, planning, a virtual filesystem, and context management.

## The five patterns

| Pattern | How it works |
| --- | --- |
| Subagents | A main agent coordinates subagents as tools. All routing passes through the main agent, which decides when and how to invoke each subagent. |
| Handoffs | Behavior changes dynamically based on state. Tool calls update a state variable that triggers routing or configuration changes, switching agents or adjusting the current agent's tools and prompt. |
| Skills | Specialized prompts and knowledge loaded on demand. A single agent stays in control while loading context from skills as needed. |
| Router | A routing step classifies input and directs it to one or more specialized agents. Results are synthesized into a combined response. |
| Custom workflow | Build bespoke execution flows with LangGraph, mixing deterministic logic and agentic behavior. Embed other patterns as nodes in your workflow. |

## Match the requirement to the row

The choosing table covers four patterns. Custom workflow is not a row. Use it when those patterns do not fit.

| Pattern | Distributed development | Parallelization | Multi-hop | Direct user interaction |
| --- | --- | --- | --- | --- |
| Subagents | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| Handoffs | - | - | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Skills | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Router | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | - | ⭐⭐⭐ |

The page defines the columns this way:

- **Distributed development:** can different teams maintain components independently?
- **Parallelization:** can multiple agents execute concurrently?
- **Multi-hop:** does the pattern support calling multiple subagents in series?
- **Direct user interaction:** can subagents converse directly with the user?

You can mix patterns. A subagents architecture can invoke tools that invoke custom workflows or router agents. Subagents can also load skills on demand.

## What the call counts say

More model calls mean more latency when sequential, and higher per-request API cost. Tokens processed are total context-window usage across calls.

On a one-shot request to buy coffee, a specialized agent or skill calls a buy_coffee tool. Handoffs, skills, and router take 3 model calls and are marked best fit. Subagents take 4, because results return through the main agent. On a repeat, handoffs and skills save 40-50% of calls: 2 on the second turn, 5 total. Subagents stay at 4 per turn, 8 total, because they are stateless. Router stays at 3, 6 total.

For a comparison of Python, JavaScript, and Rust, each language agent or skill holds about 2000 tokens of documentation. Subagents and router are marked best fit at 5 calls and about 9K tokens. Skills uses 3 calls but about 15K tokens. Handoffs takes 7 or more calls and about 14K or more tokens, because it cannot research all three languages at once. The page says subagents process 67% fewer tokens overall due to context isolation. Custom workflow is absent from those benchmarks.

## Use a custom workflow when the row does not fit

Use a custom workflow when standard patterns do not fit, when deterministic logic must sit beside agentic behavior, or when you need complex routing or multi-stage processing.

You own the graph: sequential steps, conditional branches, loops, and parallel execution. A node can be a simple function, an LLM call, or an entire agent with tools. Other patterns can be embedded as nodes. The router pattern is itself a custom workflow. A linked tutorial, Build a multi-source knowledge base with routing, queries GitHub, Notion, and Slack in parallel, then synthesizes results. Its code is not on these two pages.

The code below is a straight line. Do not add branch, loop, or parallel edge calls these snippets do not show.

## Call the agent from a node

Create the agent once, then invoke it inside a node. The snippet names State and does not define it. It stops after compile. The returned dict stores the last message content as the answer.

```python
from langchain.agents import create_agent
from langgraph.graph import StateGraph, START, END

agent = create_agent(model="openai:gpt-5.5", tools=[...])

def agent_node(state: State) -> dict:
    """A LangGraph node that invokes a LangChain agent."""
    result = agent.invoke({
        "messages": [{"role": "user", "content": state["query"]}]
    })
    return {"answer": result["messages"][-1].content}

# Build a simple workflow
workflow = (
    StateGraph(State)
    .add_node("agent", agent_node)
    .add_edge(START, "agent")
    .add_edge("agent", END)
    .compile()
)
```

The tools argument is an ellipsis in the docs, not a tool list. The node reads a query field, wraps it as a user message, and keeps only the last message content. Edges run from the graph start into that node, then to the graph end.

## Put a deterministic step beside it

The RAG example is a WNBA stats assistant. A model node rewrites the query with structured output. A deterministic node runs vector similarity search, with no LLM. An agent node reasons over retrieved context and can call a tool for latest news.

State in that example is a TypedDict with question, rewritten_query, documents, and answer. The basic node above reads a query field instead. Each node reads and updates structured fields so data can move between steps.

The agent node joins the documents into a prompt with the question, then stores content blocks rather than plain message content:

```python
def call_agent(state: State) -> dict:
    """Generate answer using retrieved context."""
    context = "\n\n".join(state["documents"])
    prompt = f"Context:\n{context}\n\nQuestion: {state['question']}"
    response = agent.invoke({"messages": [{"role": "user", "content": prompt}]})
    return {"answer": response["messages"][-1].content_blocks}
```

The graph runs from the start through rewrite and retrieve, then the agent, then the end.

```python
workflow = (
    StateGraph(State)
    .add_node("rewrite", rewrite_query)
    .add_node("retrieve", retrieve)
    .add_node("agent", call_agent)
    .add_edge(START, "rewrite")
    .add_edge("rewrite", "retrieve")
    .add_edge("retrieve", "agent")
    .add_edge("agent", END)
    .compile()
)
```

```python
result = workflow.invoke({"question": "Who won the 2024 WNBA Championship?"})
print(result["answer"])
```

Rewrite uses ChatOpenAI with gpt-5.5 and structured output into RewrittenQuery. Retrieval uses an in-memory vector store and a retriever with k set to 5. The news tool returns a fixed string; a comment says to put your news API there. In production, replace that in-memory store with a persistent one such as Valkey, Databricks Vector Search, or MongoDB Atlas.

## What to do next

Pick the row before you add nodes. If handoffs, skills, subagents, or a router already match the stars and the call counts, stay there. A subagent tool can still call a custom workflow later. If a step must run whether or not the model chooses a tool, copy the agent node, define the State that snippet assumes, and place a deterministic step the way the RAG graph places retrieve between rewrite and the agent.

Then trace the run. The index recommends LangSmith for traces across agents, and LangSmith Engine to monitor traces, detect issues, and propose fixes. Read the two pages below. If the next graph should query several sources in parallel, follow the tutorial named Build a multi-source knowledge base with routing.

## Sources

- [Multi\-agent](https://docs.langchain.com/oss/python/langchain/multi-agent)
- [Custom workflow](https://docs.langchain.com/oss/python/langchain/multi-agent/custom-workflow)