The Scenario
A customer asks via WhatsApp about an order. The agent confirms via WhatsApp, opens a case in Salesforce Service Cloud, queries the warehouse system (typically SAP, Manhattan, or Blue Yonder) for status, escalates the shipping delay to a fulfillment exception queue, and follows up the next morning via email with the new tracking number. One agent logic, multiple channels (WhatsApp, email), multiple systems (Salesforce, warehouse, carrier API). The 2026 maturity standard is that the customer never has to re-explain the issue and never sees the seams between systems. Cox Automotive’s Claude-powered case study and the Heathrow Agentforce deployment both show this pattern in production.
State Management
Conversation state must persist regardless of channel. Unified identity resolution lives in Data 360, Segment, mParticle, or RudderStack — pick the platform that already holds the canonical customer identity. The agent’s memory of “we were discussing order O-99281, delayed by carrier issue, customer accepted Tuesday delivery” must survive a channel switch from WhatsApp at 11pm to email the next morning. Use a session store keyed on the resolved customer ID, not on the channel-specific handle (phone number, email, WhatsApp ID), and version it so the agent can tell what was said when. Context travels; the user does not repeat themselves.
Agent session record
session_id: sess-2026-04-28-aab12
customer_id: cust-77821 (resolved via Data 360)
channels: [whatsapp:+44...., email:[email protected]]
issue: order O-99281 shipping delay
state: awaiting carrier confirmation
last_action: confirmed Tuesday delivery option
next_action: email tracking number when carrier emits scan event
ttl: 14 daysIdempotent Actions
Agent retries are inevitable — the network drops, the LLM times out, the orchestrator restarts mid-step. Actions must tolerate replay. Upsert operations, idempotency keys on every external call (Stripe-style Idempotency-Key headers), and explicit compensating actions on partial failure. The classic failure: an agent retries a “send refund” tool after the first call timed out; the tool actually succeeded; the customer gets two refunds. The fix: every state-changing tool call carries an idempotency key derived from the session and the action; the tool’s server deduplicates.
Failure Handling
What happens when the warehouse system is down? The agent queues the request, notifies the user with a realistic expected delay, retries autonomously with backoff, and escalates to a human queue if the outage exceeds the SLA. The customer experiences a slight delay, not an outage. Build a circuit breaker per downstream system so a flapping warehouse API does not pin every agent in the fleet on retries. Patterns: Polly (.NET), resilience4j (JVM), tenacity (Python). For LangGraph and CrewAI deployments in 2026, the orchestrator’s checkpoint feature is the right place to persist mid-failure state.
Common Failure Modes
The recurring failures: state stored in the channel adapter (so a switch loses context), shared session keys across customers when identity resolution misroutes, tools without idempotency keys producing duplicates on retry, and missing circuit breakers leading to cascading retry storms during downstream outages. A subtler failure: the agent confirms an action that succeeded silently in one system but failed in another, leaving the customer thinking it worked.
Implementation Sequence
A defensible build order: first the identity resolution layer (Data 360, CDP), then the session store, then the orchestrator (LangGraph, Agentforce flow, Microsoft Copilot Studio), then per-channel adapters with the same agent backend, then the tool surface with idempotency keys, then the failure-handling and SIEM telemetry. Skipping the identity step is the most common error; the rest of the stack works only when “this is the same customer” is reliably true.
What to do this week
Trace one real cross-channel session end to end and produce a sequence diagram. The diagram will likely reveal one channel that lost context or one tool that lacks an idempotency key — that is the next sprint.
