LangGraph Multi-Agent Swarm
Coordinate specialized agents through dynamic handoffs and persistent conversational state.
The workflows restrict GitHub Actions to read-only contents, the README explicitly says that default handoffs pass the full message history, and it describes a custom-state approach for isolating internal agent records. The license, package author, and project attribution provide basic provenance. Deductions apply because runtime least privilege is not systematically designed, human confirmation is only named as an upstream LangGraph capability, sensitive-data redaction, retention, and secret-handling guidance is absent, dependency auditing and vulnerability mitigation are not evidenced, arbitrary tool side effects have no confirmation or containment mechanism, and checkpoints are described without a rollback procedure. Unknown publisher identity is not treated as suspicious or as an independent deduction.
The README's handoff, active-agent memory, and multi-turn descriptions align with the test assertions. Python requirements, bounded dependencies, installation commands, and CI installation steps are also clear. Deductions apply because the supplied evidence omits the core implementation, the import test is empty, and there are no documented or tested diagnostic messages for invalid agent names, incompatible state schemas, model failures, or tool failures.
The material covers basic agent handoffs, short- and long-term memory, custom handoff tools, custom state schemas, and agent wrappers, while explaining the boundaries of shared messages and active-agent routing. Configurable tool names and descriptions support reasonably precise handoff triggers. Deductions apply because scenarios remain centered on one small example, with no strategy for complex routing, conflicting handoffs, or negative non-trigger conditions; environment guidance is largely limited to Python, LangGraph, and an OpenAI quickstart, without developed deployment or alternative-provider coverage.
The README has clear installation, quickstart, memory, and customization sections. Public naming is consistent across package metadata, imports, and examples, and important operational constraints are presented as notices. The complete MIT text agrees with package metadata, justifying full license marks. Deductions apply because there is no FAQ, migration guide, release history, or changelog, while maintenance responsibility is only weakly indicated by one author entry and the copyright holder, with no support channel, maintainer roles, or update policy.
The examples yield directly usable graph state and message collections, and active-agent persistence plus customizable handoffs provide clear value over manual orchestration. Deductions apply because utility is demonstrated only through a small arithmetic/persona handoff scenario and no production-scale benefit is shown. Model-call count, latency, token usage, storage cost, and multi-agent orchestration overhead are not discussed, leaving cost-benefit support thin.
Major claims map to README examples, package metadata, CI configuration, and deterministic fake-model tests that assert message counts, transfer messages, calculation output, and active-agent state. Package naming, dependencies, and workflow behavior are broadly corroborated across the supplied files. Deductions apply because core source files, release records, and broader tests are absent, some upstream capabilities are asserted mainly through links, and there is no formal claim-to-evidence map or comprehensive labeling of inference versus demonstrated fact.
- Default handoffs pass the full message history to the next agent; production deployments should add minimization, redaction, and inter-agent isolation for sensitive content.
- The framework permits custom agent tools, but the material shows no approval, permission-reduction, or compensation controls for external side effects. Host applications should add confirmation and idempotency safeguards around write-capable tools.
- Do not equate checkpointing with rollback: state persistence is documented, but restoration, undo, and cleanup procedures are not.
- Dependencies use relatively broad major-version ranges, and the evidence includes no lockfile, security scan results, or vulnerability-response policy. Deployers should pin and audit dependencies independently.
- This assessment uses only the supplied static files, without executing code or tests, and the core implementation was not included in the evidence.
What does this agent do, and when should you use it?
LangGraph Multi-Agent Swarm is a Python library for building swarm-style multi-agent applications. It combines specialized agents into a LangGraph `StateGraph` with `create_swarm`, while `create_handoff_tool` lets those agents transfer control and context to one another. The router tracks the last active agent so a later turn can resume with that agent when checkpointing is configured. The graph must be compiled before invocation and can use LangGraph checkpointers, stores, streaming, and human-in-the-loop facilities. This is an application-level orchestration library rather than a hosted service: adopters remain responsible for model access, agent definitions, persistence, and deployment.
A developer creates individual agents with langchain.agents.create_agent or custom StateGraph implementations, assigning each its own tools and system prompt. create_handoff_tool adds callable transfers between agents; by default, a handoff forwards the complete swarm message history and appends a successful-handoff ToolMessage. create_swarm([alice, bob], default_active_agent="Alice") assembles the parent StateGraph and tracks its current controller through active_agent. The developer compiles it with workflow.compile(checkpointer=..., store=...) to add short-term or long-term memory, then sends messages through app.invoke({"messages": [...]}, config) and receives the resulting workflow state. For isolated histories or specialized schemas, developers can wrap child graphs with state transformations and construct routing explicitly through add_active_agent_router.
- A Python team building customer support can route a conversation among billing and technical specialists while retaining the currently responsible agent across turns.
- An application developer can give math, language, or other domain agents distinct prompts and tools, then let the model initiate handoffs according to specialization.
- A team that cannot expose every agent's internal history can define separate message keys and transform state at each parent-to-child graph boundary.
- Existing LangGraph users can add a checkpointer for resumable conversations and a store for memory that persists across threads.
- Engineers designing structured delegation can customize a handoff tool so the calling model supplies a task description or other context for the next agent.
What are this agent's strengths and limitations?
create_handoff_toolandcreate_swarmprovide concrete primitives for context transfer, agent switching, and active-agent routing.- Compiled workflows can use LangGraph's documented streaming, short-term and long-term memory, and human-in-the-loop capabilities.
- Handoff tools can be customized with different names, descriptions, model-populated arguments, and transferred state.
- Custom child schemas and state-conversion wrappers allow applications to isolate agent histories instead of sharing one global message list.
- Multi-turn operation requires a checkpointer; without one, the swarm loses conversation history and forgets which agent was last active.
- The default handoff exposes the full accumulated message history to the next agent, so privacy or context isolation requires custom implementation.
- A custom handoff returning
Commandneeds a compatible tool-calling node, and both the parent and destination graphs must declare every updated state key. - The only runnable provider setup shown uses
langchain-openai, an OpenAI API key, and network access; no ready-to-run configuration for another provider is documented. - The repository documents an embeddable Python workflow, not a standalone server, container image, or managed deployment.
How do you install or deploy this agent?
A Python environment is required. Install the library with:
pip install langgraph-swarmTo run the documented OpenAI example, install its adapter and provide an API key:
pip install langgraph-swarm langchain-openai
export OPENAI_API_KEY=<your_api_key>How do you use this agent?
Instantiate ChatOpenAI(model="gpt-4o"), then define named agents with create_agent, adding a create_handoff_tool for each allowed transfer. Build the workflow with create_swarm([alice, bob], default_active_agent="Alice"). For a multi-turn application, compile it with InMemorySaver or another checkpointer: app = workflow.compile(checkpointer=checkpointer). Invoke it using a stable thread configuration such as config = {"configurable": {"thread_id": "1"}}, followed by app.invoke({"messages": [{"role": "user", "content": "i'd like to speak to Bob"}]}, config). Reuse that thread_id on later turns so the saved conversation and active-agent state can be restored.
How does this agent compare with similar options?
Compared with manually assembling a LangGraph StateGraph, create_swarm and create_handoff_tool supply prebuilt active-agent routing and transfer behavior. Applications needing isolated message state or custom transformations can instead assemble nodes themselves and add routing with add_active_agent_router.
FAQ
Is a persistence component required for multi-turn conversations?
workflow.compile(checkpointer=checkpointer); otherwise the swarm forgets the last active agent and loses conversation history.What information is passed during a handoff?
create_handoff_tool forwards the complete message history accumulated by the swarm and adds a tool message confirming the transfer. A custom handoff can change that payload.Must every agent share the same conversation history?
messages is the default, but developers can give child agents separate message keys and write wrappers that translate state between parent and child graphs.