Groups
Groups are a new feature in Letta and the specification is actively evolving. If you need support, please chat with us on Discord.
Groups enable sophisticated multi-agent coordination patterns in Letta. Each group type provides a different communication and execution pattern, allowing you to choose the right architecture for your multi-agent system.
Choosing the Right Group Type
Working with Groups
All group types follow a similar creation pattern using the SDK:
- Create individual agents with their specific roles and personas
- Create a group with the appropriate manager configuration
- Send messages to the group for coordinated multi-agent interaction
Groups can be managed through the Letta API or SDKs:
- List all groups:
client.groups.list()
- Retrieve a specific group:
client.groups.retrieve(group_id)
- Update group configuration:
client.groups.update(group_id, update_config)
- Delete a group:
client.groups.delete(group_id)
Sleep-time
The Sleep-time pattern enables background agents to execute periodically while a main conversation agent handles user interactions. This is based on our sleep-time compute research.
For an in-depth guide on sleep-time agents, including conversation processing and data source integration, see our Sleep-time Agents documentation.
How it works
- A main conversation agent handles direct user interactions
- Sleeptime agents execute in the background every Nth turn
- Background agents have access to the full message history
- Useful for periodic tasks like monitoring, data collection, or summary generation
- Frequency of background execution is configurable
Code Example
RoundRobin
The RoundRobin group cycles through each agent in the group in the specified order. This pattern is useful for scenarios where each agent needs to contribute equally and in sequence.
How it works
- Cycles through agents in the order they were added to the group
- Every agent has access to the full conversation history
- Each agent can choose whether or not to respond when it’s their turn
- Default ensures each agent gets one turn, but max turns can be configured
- Does not require an orchestrator agent
Code Example
Supervisor
The Supervisor pattern uses a manager agent to coordinate worker agents. The supervisor forwards prompts to all workers and aggregates their responses.
How it works
- A designated supervisor agent manages the group
- Supervisor forwards messages to all worker agents simultaneously
- Worker agents process in parallel and return responses
- Supervisor aggregates all responses and returns to the user
- Ideal for parallel task execution and result aggregation
Code Example
Dynamic
The Dynamic pattern uses an orchestrator agent to dynamically determine which agent should speak next based on the conversation context.
How it works
- An orchestrator agent is invoked on every turn to select the next speaker
- Every agent has access to the full message history
- Agents can choose not to respond when selected
- Supports a termination token to end the conversation
- Maximum turns can be configured to prevent infinite loops
Code Example
Handoff (Coming Soon)
The Handoff pattern will enable agents to explicitly transfer control to other agents based on task requirements or expertise areas.
Planned Features
- Agents can hand off conversations to specialists
- Context and state preservation during handoffs
- Support for both orchestrated and peer-to-peer handoffs
- Automatic routing based on agent capabilities
Best Practices
- Choose the group type that matches your coordination needs
- Configure appropriate max turns to prevent infinite loops
- Use shared memory blocks for state that needs to be accessed by multiple agents
- Monitor group performance and adjust configurations as needed