SocialAlgorithms framework provides complete flexibility for defining custom communication patterns between agents. Upload any arbitrary social algorithm as a callable that defines exactly how agents interact and communicate.
When to Use
- Custom communication patterns: Unique agent interaction requirements
- Research implementations: Test novel multi-agent algorithms
- Specialized workflows: Domain-specific communication protocols
- Flexible orchestration: Full control over agent interactions
- Algorithm experimentation: Compare different social patterns
Key Features
- Accept any callable as social algorithm
- Communication history tracking (optional)
- Execution timeout management
- Multiple output formats
- Agent lifecycle management
- Async execution support
- Parallel execution options
- Detailed logging and monitoring
Basic Example
Custom Algorithm Patterns
Debate Algorithm
Hierarchical Review
Consensus Building
Key Parameters
str
default:"SocialAlgorithm"
Name for the algorithm instance
str
Description of the algorithm’s purpose
List[Agent]
required
List of agents that will participate
Callable
default:"None"
Function defining the communication pattern (agents, task, **kwargs) -> Any. Optional at construction time, but
run() raises InvalidAlgorithmError if it is still None when called.str
Unique identifier for the algorithm instance. Auto-generated as a UUID if omitted.
float
default:"300.0"
Maximum execution time in seconds
OutputType
default:"dict"
Format for output (dict, list, str)
bool
default:"False"
Enable detailed logging
enable_communication_logging, parallel_execution and max_workers were removed.
Agent messages are now always recorded into conversation, and the two parallel
options were stored but never used. Passing them is still accepted and ignored,
so existing call sites do not break.Methods
run()
Execute the social algorithm.add_agent() / remove_agent()
Dynamic agent management.remove_agent(agent_name: str) scans self.agents for a matching agent_name and deletes that entry. If no agent with that name exists, it raises AgentNotFoundError instead of silently no-op’ing.
get_communication_history()
Every agent message produced while the algorithm runs, oldest first. Recording is always on — there is no flag to enable.This returns message dicts, not
CommunicationStep objects. That dataclass was
removed when Conversation took over the transcript.clear_communication_history()
Empties the recorded messages. The conversation otherwise accumulates across runs, so call this if you are reusing one instance for unrelated tasks.SocialAlgorithmResult
Detailed execution results:Use Cases
Multi-Stage Pipeline
Collaborative Writing
Expert Panel
Communication Logging
Every agent call made while the algorithm runs is recorded automatically — the algorithm itself reports nothing. The task lands asUser, each agent’s output
under its own agent_name, and the final result under the algorithm’s name:
talk_to calls record the receiver in the message metadata. The conversation
accumulates across runs, so call clear_communication_history() between
unrelated tasks.
Execution Timeout
Output Formatting
Algorithm Requirements
Your social algorithm must:- Accept agents and task:
def algorithm(agents, task, **kwargs) - Return results: Any structure (dict, list, str, object)
- Handle errors: Exceptions will be caught and logged
Best Practices
Algorithm Design: Keep algorithms focused on communication patterns, not complex logic
- Clear Signatures: Always accept (agents, task, **kwargs)
- Error Handling: Handle agent failures gracefully
- Timeout Awareness: Set appropriate max_execution_time
- Communication Logging: Enable for debugging and analysis
- Documentation: Document your algorithm’s communication pattern
Error Handling
Agent Management
Related Architectures
- Agent Rearrange - Predefined flow patterns
- Graph Workflow - DAG-based workflows
- Group Chat - Conversational patterns
- Hierarchical Swarm - Director-worker pattern