Preventing Agent Ping-Pong With a Routing and State-Machine Escalation Pattern

Define the problem in operational terms

“Agent ping-pong” happens when a customer is bounced between an AI agent and a human agent (or between multiple AI agents) across channels like email, web chat, and WhatsApp. The symptoms are familiar: duplicated questions, lost context, inconsistent answers, and reopened tickets that never fully stabilize. The root cause is usually not model quality—it’s system design. Specifically, escalation is treated as an ad-hoc event instead of a controlled transition governed by routing rules, durable state, and explicit ownership.

A reliable fix is a combined pattern: (1) a routing layer that decides who should handle the next turn and through which channel, and (2) a state machine that decides what phase the case is in, what actions are allowed, and what evidence is required before moving forward.

A routing layer that is separate from “the agent”

When routing is embedded inside a single agent prompt (“If you’re unsure, hand off to a human”), you get inconsistent behavior and difficult-to-audit outcomes. Instead, treat routing as a first-class system component with deterministic inputs and outputs.

Core routing inputs

• Customer identity and account context: tier, contract, language, region, prior escalations.
• Channel constraints: WhatsApp message length, email thread latency, chat concurrency, business hours.
• Risk and policy signals: PII presence, refund thresholds, compliance categories, sensitive topics.
• Confidence and completion signals: retrieval coverage, tool-call success, missing fields, ambiguity score.
• Operational load: human queue depth, SLA class, skill-based availability.

Routing outputs that prevent thrash

• Owner: AI, human, or “hybrid” (AI drafts, human approves).
• Next channel: keep on current channel, or switch to email for long-form, or move to chat for real-time clarification.
• Allowed actions: read-only, suggest-only, execute-with-approval, execute-autonomously.
• Escalation reason code: structured labels that power analytics (e.g., “missing entitlement,” “policy exception,” “payment dispute”).

By making routing explicit and inspectable, you stop accidental “AI returns to the conversation” after a human has taken ownership, and you eliminate silent channel flips that confuse customers.

The state machine that governs the case lifecycle

The second half of the pattern is a finite state machine for each case (ticket, conversation, order issue). The state machine is the single source of truth for what has happened, what is pending, and what can happen next. Crucially, it persists across channels, so email follow-ups and WhatsApp replies are not treated as separate flows.

Recommended states for seamless AI-to-human escalation

• Intake: capture intent, identity, and channel metadata; create or attach to an existing case.
• Clarification: AI asks bounded questions; required fields are tracked explicitly (order ID, last 4 digits, device type).
• Execution: AI performs tool actions (CRM update, refund initiation, password reset) subject to policy.
• Human Review: AI drafts a proposed resolution; human approves/edits; customer is notified consistently.
• Human Takeover: a human owns the case; AI is constrained to background support (summaries, suggested macros).
• Resolved: resolution communicated; follow-up window and reopen rules defined.
• Reopened: routes back to the right owner with preserved context, not a fresh “start over.”

Transitions must be guarded

Each transition should have criteria. For example, Clarification → Execution requires “all mandatory fields present,” and Execution → Resolved requires “tool action succeeded” plus “customer confirmation sent.” Guarded transitions are what prevent ping-pong: the system can’t bounce back to AI execution if the case is explicitly in Human Takeover.

Ownership rules that eliminate back-and-forth

Ping-pong often appears when ownership is fuzzy. Define ownership as a durable field on the case with strict rules:

• Single owner at a time: AI or a named human queue/user. “Hybrid” is still an owner mode with constraints.
• AI cannot seize ownership once a case is in Human Takeover unless a human explicitly returns it.
• Channel replies do not change ownership: a WhatsApp reply on an email-originated case stays with the same owner unless routing changes it.
• Time-based returns are explicit: if a human doesn’t respond in X hours, the state changes to “Human Review (AI draft)” rather than silently reactivating full AI autonomy.

These rules are simple, but they force every escalation to be a tracked state transition rather than a conversational accident.

Context packaging for escalation without losing fidelity

Escalation fails when humans receive a wall of chat logs or a vague summary. A good escalation package is structured and minimal:

• Customer objective and current status.
• Timeline: key events with timestamps and channels.
• What the AI tried: tool calls, knowledge sources, and outcomes.
• Open questions: exactly what’s missing to resolve.
• Policy flags: why the AI escalated (limits, compliance, uncertainty).

If you already use QA or governance workflows for customer interactions, the same structured packaging aligns well with a transcript-to-quote governance workflow, because both depend on traceability and unambiguous attribution.

Channel-specific escalation behaviors that still share one state

Email

• Prefer AI drafting with human approval for sensitive cases; keep thread integrity and reference IDs.
• Use explicit “next steps” lists so customers don’t restart the conversation in a new message.

Web chat

• Escalate to a human in-session when possible; otherwise, convert to an owned case with a promised follow-up window.
• Pin the case state visibly in the agent console to prevent duplicate questioning.

WhatsApp

• Minimize repeated identity checks; store verification level in state.
• Use short clarifying questions and avoid multi-step instructions unless confirmed.

The key is that the channel UX differs, but the state machine remains the same. That is what makes escalations consistent across touchpoints.

How Typewise supports this pattern in practice

Platforms that treat AI as an “overlay” across systems make it easier to enforce routing and state centrally rather than rebuilding it per channel. typewise.app is designed around multi-agent orchestration with supervised flows and Hybrid Intelligence controls, which fits naturally with guarded state transitions, explicit ownership, and partial handoffs. That helps teams keep business control—approvals, takeovers, and tracked partial resolutions—without relying on brittle prompt-only escalation logic.

Implementation checklist for reducing ping-pong quickly

• Define 6–8 states for your top workflows (returns, billing, access, cancellations) and make them channel-agnostic.
• Codify ownership rules and enforce them in routing, not in agent text.
• Add guarded transitions with mandatory fields and success criteria for tool actions.
• Standardize escalation packages so humans get the same structured context every time.
• Instrument reason codes to see why escalations happen and which states cause churn; pair this with evaluation/simulation before rollout.

Once routing and state are explicit, you can improve model prompts and knowledge quality iteratively—without reintroducing ping-pong as the system evolves.