Pre-Made SendMessage Classes
Agency Swarm contains multiple commonly requested classes for communication flows. Currently, the following classes are available:| Class Name | Description | When to Use | Code Link |
|---|---|---|---|
SendMessage (default) | This is the default class for sending messages to other agents. It uses synchronous communication with basic COT (Chain of Thought) prompting and allows agents to relay files and modify system instructions for each other. | Suitable for most use cases. Balances speed and functionality. | link |
SendMessageHandoff | Enables unidirectional delegation of tasks or entire interaction flows to specialized agents. When a handoff occurs, the receiving agent takes over the interaction. | Use for routing queries to specialized agents or sequential workflows where control should transfer completely. | link |
Agency-level
Agent-level
Communication-level
SendMessageHandoff tool will be used specifically for ceo -> worker communication and nowhere else. If there were other agents in the agency connected to ceo, they would be using regular SendMessage for agent-to-agent conversations. This setting overrides both agency and agent-level custom send message tools within this particular thread.
Choosing the Right Communication Method: SendMessage vs. handoffs
Agency Swarm supports two primary paradigms for inter-agent communication: direct messaging usingSendMessage tool variants (native to Agency Swarm) and handoffs via the SendMessageHandoff tool class.
Direct Messaging (SendMessage tools)
- Purpose: Use Agency Swarm’s
SendMessagetools (e.g.,SendMessage) when one agent needs to request information or a discrete action from another, expecting a response to continue its own work. Unlike in handoffs, control returns to the calling agent, making this suitable for true collaboration and agent orchestration. - Data Exchange: Primarily string-based messages, with support for file attachments.
- Analogy: An orchestrator agent assigning a sub-task to a worker agent and awaiting the result to proceed.
- When to use:
- Implementing orchestrator-worker pattern.
- Collaborative tasks requiring back-and-forth dialogue (evaluator-optimizer pattern) or result aggregation by a calling agent.
- When an agent needs to retain control of the overall workflow while delegating specific parts.
Handoffs (via SendMessageHandoff)
- Purpose: The
SendMessageHandofftool class enables an agent to unidirectionally delegate a task or an entire interaction flow to another specialized agent. When a handoff occurs, the receiving agent takes over that specific interaction; control does not automatically return to the initiating agent for that particular interaction thread. - How it Works: From the perspective of the underlying language model, a handoff is treated like a special tool (e.g.,
transfer_to_BillingAgent). To enable handoffs, you configure an agent with thesend_message_tool_class=SendMessageHandoffparameter. The agent’s description will be used as the handoff tool instructions. SeeSendMessageHandoff.create_handoff()for implementation details. - Configuration: Set
send_message_tool_class=SendMessageHandoffwhen creating the agent. The framework will automatically detect this and configure handoffs using the OpenAI SDK internally. - Analogy: Transferring a customer in a call center to a specialized department (e.g., Billing). The Billing specialist handles the customer’s request from that point forward for that specific issue.
- When to use (handoffs):
- Routing Use Cases: Such as an initial customer support agent routing a query to a specialized support agent (e.g., for billing, technical issues). A new, focused interaction begins with the specialist.
- Sequential interaction flows: Where a task must pass through a series of different specialists, and each specialist completes their part and passes it on, without the original agent resuming that specific flow.
- Further Details: For comprehensive information on configuring and utilizing handoffs, consult the Hybrid Patterns Documentation.
Creating Your Own Unique Communication Flows
To create your own communication flow, you will first need to extend theFunctionTool class from the agents SDK. The SendMessage class is built on top of FunctionTool, providing a flexible foundation for creating custom communication patterns tailored to your specific needs.
Custom SendMessage Class
To customize SendMessage parameters, extend theSendMessage class and declare additional fields using a Pydantic model:
Key Components
In general, allSendMessage tools have the following components:
- FunctionTool Base: Extends the
FunctionToolclass from the agents SDK, providing async execution and standardized tool interfaces. - Dynamic Initialization: Tools are created dynamically for specific sender->recipient pairs with custom parameter schemas.
- JSON Schema: Parameters are defined using JSON schema for validation and type safety.
- Async Communication: Uses
async/awaitfor non-blocking communication between agents.
SendMessage tools, extend FunctionTool and implement the on_invoke_tool method with your custom communication logic.
If you are planning to create an agent that has access to multiple SendMessage tools (using communication flow pattern), each tool must have a unique name, which must start with
send_message.
For example, name="send_message_formatted" or name="send_message_custom" and so on.Custom Handoff Class
By default, whenever a handoff occurs, prior to transferring the chat, a special system message will be added to the chat history to remind the recipient agent that a handoff has happened. This helps to reduce the amount of hallucinations and agent confusion whenever a chat transfer happens. You can customize the reminder message or disable it entirely by defining a custom Handoff class as follows (seeadd_reminder and handoff_reminder parameters). Set handoff_reminder on the agent that receives the handoff so the message appears in its context: