Skip to main content
The 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 a User 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.
The same messages are reachable through the standard Conversation API, which is usually the nicer way to read them:
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 as User, 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:
  1. Accept agents and task: def algorithm(agents, task, **kwargs)
  2. Return results: Any structure (dict, list, str, object)
  3. 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
  1. Clear Signatures: Always accept (agents, task, **kwargs)
  2. Error Handling: Handle agent failures gracefully
  3. Timeout Awareness: Set appropriate max_execution_time. The timeout uses signal.SIGALRM, so call run from the main thread, and not on Windows
  4. Fresh History: Call clear_communication_history() between unrelated tasks, because the conversation accumulates across runs
  5. Documentation: Document your algorithm’s communication pattern
Social algorithms have full control over agent execution - ensure proper error handling and timeout limits

Error Handling

Agent Management