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
- Automatic recording of every agent message into a
Conversation - Execution timeout management
- Multiple output formats
- Add and remove agents between runs
- Verbose logging and OpenTelemetry tracing of each run
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. Every element must be an
Agent instance; an empty list raises ValueError.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"
Shape of
final_outputs: "dict" wraps a non-dict result as {"result": ...}, "list" wraps a non-list result in a list, and "str" converts with 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. The task is recorded as aUser message, every agent call is recorded under the agent’s name, and the algorithm’s return value is recorded under the algorithm’s name. Each call is traced as a SocialAlgorithms.run span when telemetry is on.
algorithm_args and any extra keyword arguments to run are passed to your algorithm as keyword arguments. Extra keyword arguments win on a name conflict.
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.total_steps and successful_steps both count the agent messages recorded during the run. failed_steps is always 0 in a returned result, because a failing algorithm raises instead. metadata is currently always empty.
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 are logged and re-raised from
run, so catch agent failures inside the algorithm if the run should continue
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. The timeout uses
signal.SIGALRM, so callrunfrom the main thread, and not on Windows - Fresh History: Call
clear_communication_history()between unrelated tasks, because the conversation accumulates across runs - 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