Why per agent allowed handoff targets lists are the cheap fix for ping pong loops

Flashcard·Medium·4.0 · 0·~30s·Asked atBain Neptune Ai Runway

Attempt it

A ping-pong loop happens when agent A hands off to B and B's allowed targets include A. The model picks 'transfer back to A' as the next move (often because the prompt is ambiguous about which agent should answer), and the cycle continues until a turn limit kicks in.

The allowed handoff targets list is a declarative ACL: B's allowed targets simply does not include A. The handoff tool back to A is not even in B's tool list, so the model cannot emit it. The cycle is structurally impossible regardless of how confused the prompt gets. This is the same idea as 'do not give an agent a tool it should not call,' applied to the handoff graph. Combined with max_handoffs as a defence in depth cap, it eliminates almost all ping-pong cases in practice.

Your answer

A ping pong loop is the simplest multi agent failure: agent A hands off to B, B hands off back to A, A hands off back to B, and the cycle continues until something external stops it. It happens because both agents' prompts are ambiguous about who owns the final response, and the model picks 'transfer' as the easy move on each turn. The OpenAI Agents SDK lets each agent declare an allowed handoff targets list. This is an ACL: a declarative list of which other agents this one is allowed to transfer to. If A is not in B's allowed targets, the back transfer tool is not in B's tool list at all. The model literally cannot emit a transfer to A; the tool does not exist for B. This is structurally stronger than a prompt instruction ('do not transfer back to A'). Prompts can be ignored under context pressure; missing tools cannot be called. The pattern is the same as 'do not give an agent a tool it should not call.' Applied to handoffs, it makes the cycle impossible regardless of how confusing the situation gets. max_handoffs is a defence in depth cap that catches accidental cycles in graphs that should have been acyclic but were misconfigured. The ACL is the primary defence; the cap is the seat belt.

Ping pong loops are graph cycles in the handoff topology. The allowed handoff targets list turns the graph from one that contains cycles into one that is structurally acyclic, which removes the cycle as a possibility rather than as a probability. ### The mechanism When an Agent is constructed, the SDK examines its allowed targets list and exposes one handoff tool per allowed target in the model's tool list. If agent A is not in B's allowed targets, the transfer_to_A tool is not in B's tool list at all. The model has no way to emit a call to a tool that does not exist; the cycle cannot be initiated. ### Why this beats prompt level fixes The alternative defence is a prompt instruction: 'you are agent B; do not transfer back to A.' This works under good conditions but degrades under context pressure. A long conversation, an ambiguous user request, or a few shot example of a transfer in the history can pull the model toward the transfer, and the prompt instruction loses. The ACL removes the option entirely. ### The defence in depth pair max_handoffs is a per task cap on total handoffs. With the ACL as the primary defence, max_handoffs catches edge cases: graphs that have a cycle through three or more agents (A to B to C to A), graphs where the ACL was misconfigured, graphs that legitimately need a loop but should be bounded. The cap is the seat belt; the ACL is the road geometry. ### The broader principle This is one instance of a general rule for multi agent design: **prefer structural constraints over prompt constraints.** Prompts fail in surprising ways; tool surface is enforced by the framework and the model has no way around it. Any defence that can be expressed as 'this tool is not available' beats any defence that has to be expressed as 'do not use this tool.'

TL;DR

If the back transfer tool is not in B's tool list, the model cannot emit it; an ACL turns ping pong from a prompt problem into a structural impossibility.

Memory aid

Easy to grasp

Imagine a customer service desk where agent A passes a customer to agent B because B knows about returns. If B's only available transfer buttons are 'send to specialist C' and 'finish the ticket,' then no matter how confused the conversation gets, B cannot bounce the customer back to A. The button is not on the panel. The same logic applies to agent handoff tools: if the back transfer is not in B's tool list, the model simply cannot suggest it. The loop is not unlikely; it is impossible. A turn limit is the seat belt; the ACL is making the road have no U turn.

Key concepts

Multi agent systems Agents

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Ping pong loops are one of the most common multi agent failure modes in 2026 production systems, and one of the easiest to fix correctly once you see the right defence. The fix is not a clever prompt or a sophisticated runtime check; it is a declarative ACL that removes the back transfer tool from the agent's tool list.

This answer walks through why ping pong happens, why prompt level defences degrade, how the OpenAI Agents SDK's allowed handoff targets list closes the loophole at the tool layer, and why this is a specific instance of a broader principle that runs through good multi agent design.

Why ping pong loops happen in the first place

A ping pong loop is a graph cycle between two agents. Agent A is asked something, transfers to B, B looks at the conversation, decides A is better positioned to answer, transfers back. A receives the transferred conversation, finds itself in the same position as before, transfers to B again. The cycle continues until something external stops it.

The root cause is ambiguity

Ping pong is almost always caused by a prompt or routing setup that is ambiguous about which agent owns the final response. Both agents have plausible reasons to defer to the other: A says 'B is the specialist,' B says 'A has the full context.' The model picks the polite move (transfer to the other) on each turn.

Why the model picks transfer over answering

In the model's training distribution, transferring is a low risk move. It avoids committing to a possibly wrong answer; it defers to a teammate. Under context pressure, this is a strong attractor. Even a well written system prompt cannot fully compete with thousands of examples of polite deferral.

The cycle compounds quickly

Each transfer adds a turn to the conversation, which adds context, which makes the ambiguity worse. The longer the cycle runs, the more confident the model becomes that transferring is the right move (because that is what the recent history shows). Without an external bound, the cycle runs until the token budget triggers.

Why prompt level fixes degrade

How the allowed targets ACL closes the loophole

Defence in depth and the broader principle

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

from agents import Agent, handoff, Runner

# Specialist agents, terminals in the handoff graph
refunds = Agent(
    name="refunds",
    instructions="Process refund requests; finish the ticket when done.",
    handoffs=[],  # cannot transfer anywhere, DAG terminal
)

shipping = Agent(
    name="shipping",
    instructions="Answer shipping questions; finish the ticket when done.",
    handoffs=[],  # cannot transfer anywhere
)

# Triage agent, the only one allowed to dispatch
triage = Agent(
    name="triage",
    instructions="Route the user to the right specialist based on their request.",
    handoffs=[refunds, shipping],  # one way only, no back transfers
)

# refunds.handoffs is [] so transfer_to_triage is not in its tool list.
# The model cannot emit a back transfer. The cycle is structurally impossible.

result = await Runner.run(triage, "I need a refund for order 1234")

Defence	Mechanism	When it fires
Prompt instruction	System prompt asks the agent not to transfer back	On most turns; fails under context pressure
Allowed targets ACL	Back transfer tool is not in the agent's tool list	Always; structural impossibility
max_handoffs cap	Runtime aborts after N handoffs total	Only after the loop has wasted N turns
State sentinel	Manual check in code on each transfer	Brittle; depends on author remembering to check

Real products, models, and research that use this idea.

OpenAI Agents SDK ships allowed handoff targets as a first class field on the Agent constructor; production deployments in 2026 commonly enforce a DAG topology through this mechanism.
Customer support agent designs from teams using the OpenAI Agents SDK route triage to specialist agents with no back transfer, structurally preventing the most common ping pong case.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you handle a cycle that is legitimate, like a critic loop with bounded revisions?

Use a bounded counter in state and an explicit termination condition; the loop is part of the graph by design, but its iterations are capped explicitly rather than blocked by an ACL. The ACL prevents accidental cycles; the counter bounds intentional ones.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Treating max_handoffs as the primary defence against ping pong loops and letting the loop burn the cap before something stops it, when an ACL would have made the loop impossible to start.

60 second bullets to scan on the way to the call.

Why ping pong loops happen and what makes them structural rather than incidental
How allowed handoff targets translate to tool list entries the model sees

Primary sources. Browse if you want the original framing.