How Agent Handoffs Work in Multi-Agent Systems

of LLMs’ reasoning capabilities with memory, planning, and power use (creating what we call agents) has expanded the range of tasks LLMs can perform.

Nonetheless, a single agent alone has its limitations. When coupled with too many tools or a very large context, it often results in poor decisions and subpar responses.

That is why multi-agent systems have grown in popularity, as they permit us to tackle use cases of accelerating complexity.

Multi-agent systems connect quite a few specialized agents that work together, each specializing in a particular task, while the system routes queries to the proper expert.

Consider it as a team of experts collaborating, each contributing their very own specialized skills through a “divide-and-conquer” approach.

In this text, we’ll clearly explore one in all the key concepts in multi-agent systems: how agents transfer control to at least one one other.

Contents

(1) Primer to LangGraph
(2) Definition of Agentic Handoffs
(3) Example Scenario
(4) Handoffs in LangGraph

Here is the link to the accompanying GitHub repo.

(1) Primer to LangGraph

[]

LangGraph is an open-source orchestration framework for constructing stateful, LLM-based agentic systems that reliably handle complex tasks.

It allows developers to design workflows as graphs, where each graph consists of nodes (representing tasks or LLM calls) and edges (representing control flow).

LangGraph is my framework of alternative for constructing agentic systems due to its key strengths:

• Low-level controllability that provides precise control over transitions, states, and the way each agent executes.
• Transparent and intuitive graph-based workflows that make complex logic easy to know, arrange, and trace.
• Flexible non-chat workflows that support agentic orchestration beyond conversational agents (e.g., frameworks like AutoGen)

The image below shows what a graph-based workflow designed for retrieval augmented generation looks like:

(2) Definition of Agentic Handoffs

First, let’s understand what a handoff means.

An agentic handoff is the moment when an agent directly and dynamically passes control to a different agent after ending its work.

This is essential because we wish tasks to be routed to the agent best equipped to supply a context-aware response.

In technical terms, a handoff occurs when one agent transfers control, responsibility, or conversational context to a different agent to make sure continuity and relevance within the interaction.

The image below illustrates a three-agent architecture based on the supervisor pattern, wherein a central agent coordinates the specialized employee agents (a research agent and a document-authoring agent).

Each employee gains its specialization through integration with a particular set of tools and customised prompts.

Suppose the user query is “”.

The supervisor agent, being aware of the nature of the user query and the employee agents at its disposal, will hand off the duty to the research agent to perform the subsequent turn.

Here is the flow:

1. Supervisor agent analyzes user intent and decides that it needs assistance from the research agent
2. Supervisor passes control (and state*) to the research agent
3. The research agent performs the duty and decides whether to handoff back to the supervisor agent or end the conversation.

(3) Example Scenario

Let’s have a look at the instance scenario to anchor our walkthrough.

We’ll arrange an actual estate assistant able to answering queries related to properties in Singapore. It’s designed as a three-agent system based on the favored supervisor pattern.

On this scenario, we have now an actual estate manager (supervisor) with access to 2 specialized employee agents:

• Property profile agent: Handles queries related to housing property details.
• Transaction history agent: Handles queries related to property transactions and market trends.

The routing has been simplified to be one-way i.e. once the employee agent completes its task, the conversation ends.

For the coordination to work, the supervisor agent must concentrate on its role, overall workflow, and agents at its disposal. We do that with a prompt like this:

The code for the supervisor node for conditional routing is as follows:

While multi-agent systems can follow different design patterns and scale to much more nodes, this straightforward example allows us to consider the concept of agent handoffs.

The next screenshot shows the output of our real estate multi-agent system for a user query:

setup code (e.g., prompts, nodes, LLM calls). Nonetheless, yow will discover the code implementation in this GitHub repo.

(4) Handoffs in LangGraph

There are two mechanisms for agent handoffs in LangGraph:

• Conditional edges 
• Command object

(4.1) Conditional Edges (Static Routing-Based Handoff)

A conditional edge is the classic graph-routing method for handing off control between agents.

In a graph, nodes do the work while edges inform what to do next. 

Edges are functions that resolve the routing logic (i.e., which node to execute next). This routing may be direct fixed transitions or based on specific conditions (aka conditional edges).

Put simply, the flow in a conditional edge is as follows: 

1. A node generates an output
2. Output is passed to the conditional edge as input
3. The function within the conditional edge evaluates it and chooses the subsequent node to run

In LangGraph, we define conditional edges by calling add_conditional_edges on an StateGraph instance:

graph.add_conditional_edges(source="start_node", path=routing_function)

• source argument refers back to the starting node. It implies that after this node finishes, the conditional routing kicks in.
• path argument takes the conditional function, and its return value controls which node the graph moves to next.

Allow us to first explore the routing function (should_continue) of our real estate example:

Here’s what the routing function is doing:

1. Read the supervisor’s latest response and judge what to do next.
2. Check whether the supervisor explicitly asked at hand the duty off to either of the 2 employee agents.
3. When the supervisor names a employee agent, the function returns that agent’s name as a string, triggering a handoff to that agent.
4. If the supervisor didn’t request any employee agent, the function returns "end", meaning the supervisor has responded and the workflow ends.

With the routing function arrange, we next define the conditional edges:

• The supervisornode serves because the source entry point of the flow, where it first receives and analyzes the user query.
• After the supervisor completes processing, the routing function should_continue comes into play, examining the supervisor’s response to find out the handoff decision.
• The path_map dict translates the routing function’s return values into graph targets. This is required as should_continue may return “end”, which path_map converts into END, LangGraph’s stop signal.

The above essentially shows how agentic handoffs work: the supervisor outputs specific strings that the conditional function uses to path to the subsequent agent or terminate.

(4.2) Command Object (Dynamic Handoff)

Conditional edges work well for easy, predictable flows, but once the logic becomes more complex, wiring together many conditional edges can grow to be tedious and unintuitive.

To make multi-agent workflows more flexible and easier to design, the Command type was introduced to mix state updates and control flow.

It simplifies things by letting nodes return a Command object that updates the graph state specifies the subsequent node to execute.

As an alternative of counting on predefined edges, the node can itself directly and dynamically determine the subsequent step based by itself logic at runtime.

This allows edgeless graphs, where routing lives within agents reasonably than in a clutter of conditional rules, leading to a cleaner, more flexible technique to orchestrate handoffs.

Here’s a minimal code for using Command in a router node:

Within the above, the router agent node reads the state, decides what should run next, and returns a Command that updates the graph state and points to the subsequent node. 

For the reason that node chooses the subsequent step using the goto argument, there isn’t a have to define conditional edges with add_conditional_edges.

Command makes it such that the handoff logic sits within the nodes reasonably than the sides. Hence, we expect the code in our supervisor node to be more lengthy:

• The supervisor node calls an LLM to return aSupervisorDecision structured output object containing two key things: which agent at hand off to, and any relevant context, just like the property name extracted from the user’s message.
• If no employee agent is required, the supervisor responds directly. The node returns a Command that updates the messages with the response and ends the graph.
• If a handoff is required, the node builds an update dictionary. It features a routing message from the supervisor and the extracted context (e.g., the property name) within the graph state, in order that the subsequent agent can use it immediately.
• Finally, the node returns a Command that specifies the subsequent agent using goto and applies state updates (i.e., update property_name).

Literal["transaction_history_agent", "property_profile_agent"]

With Command, the nodes directly resolve which agent runs next and what to pass along. It eliminates separate routing rules and keeps the handoff logic clean.

(4.3) When to make use of conditional edges or Command?

Here is tips on how to select conditional edges versus Command for handoffs:

Use conditional edges when:

• You simply need to determine which node runs next based on the present graph state, without changing it.

Use Command when:

• Your node needs to change its state and determine the subsequent node concurrently. 
• This is beneficial in multi-agent handoffs where routing to a different agent normally requires spending some information to that agent.

Wrapping It Up

Agent handoffs are the core mechanism that makes a multi-agent system work effectively. In this text, we covered how those handoffs work in practice, with LangGraph serving because the implementation layer to precise them using conditional routing or the Command object. 

Whatever framework we use, the concept stays the identical: clear, consistent handoffs are what enable agents to work together.

Try this GitHub repo for the code implementation.