Skip to main content

Overview

Deploying multi-agent systems in production requires careful attention to error handling, retries, logging, monitoring, and system design. This guide covers the essential best practices for running Swarms agents reliably at scale.

Error Handling

Agent Error Hierarchy

Swarms defines an exception hierarchy under AgentError. Every class is exported from the top-level swarms package: run() raises ValueError before any LLM call when the task is empty and interactive is False.
In 15.0.3 and earlier, an agent whose retries were all exhausted logged the failure and returned an empty string, and fallback_models were never tried. run() now raises AgentLLMError, after first handing the task to each fallback model. The agent also removes the turns the failed run added to its memory, so a fallback model does not see the task twice.

Graceful Error Recovery

Retry Strategies

Built-in Retry Configuration

Retries run back to back, with no delay between attempts. Wrap run() in your own backoff, as below, when you need to wait out rate limits.

Exponential Backoff

Fallback Models

Use fallback models for resilience:
Each model gets the full retry_attempts before the agent moves to the next one. When the last model fails, run() raises AgentLLMError.

Fallback swarms

SwarmRouter can fall back across swarm architectures. When the primary swarm_type raises, during construction or during run(), the router builds the next type in fallback_swarms from the same agents and configuration and gives it the same task. The first one to complete wins:
Without fallback_swarms, the original exception propagates unchanged. Including "AgentRearrange" in the list requires rearrange_flow. See SwarmRouter for details.

Logging

Structured Logging with Loguru

Swarms uses Loguru. Out of the box it logs to the console and to {WORKSPACE_DIR}/logs/: a combined swarms_YYYY-MM-DD.log rotated daily and kept for 10 days, plus one <module>.log per Swarms module that logs. Calling logger.remove() drops those handlers too, so add back any file sinks you still want:

Agent-Specific Logging

Contextual Logging

Monitoring

Tracing

Swarms emits OpenTelemetry spans for every agent and swarm run by default. See Telemetry for what is captured, where it is sent, and how to opt out with SWARMS_TELEMETRY_ON=false.

Token usage

Every Agent keeps a running total of the token counts its provider reports, and SwarmRouter sums them across its agents:
Totals are lifetime totals for the instance, so record the difference between two readings to cost a single request. See Token usage for the structures that report usage and how streaming calls are counted.

Performance Metrics

Health Checks

Configuration Management

Environment-Based Configuration

Configuration Validation

Security Best Practices

API Key Management

When the provider’s standard variable (ANTHROPIC_API_KEY, OPENAI_API_KEY, …) is set, you can omit llm_api_key.

Input Validation

Safety Prompts

Resource Management

Memory Management

Concurrent Requests

An Agent instance keeps one conversation. If several threads call run() on the same instance, their turns land in the same history. For independent requests, give each request its own agent:

State Management

Autosave

A relative saved_state_path is written inside the agent’s own workspace directory, {WORKSPACE_DIR}/agents/<agent-name>-<id>/. An absolute path is used as given.

Manual State Management

load() opens the path exactly as given, so use absolute paths for state you plan to restore. Passing load_state_path to the constructor only sets the default path for a later load() call; it does not load anything by itself.

Testing

Unit Testing

Integration Testing