The problem
A WhatsApp support agent looks simple until real traffic arrives. Users send three messages in a row and expect one answer; a reply that was already in flight becomes wrong the moment a newer message lands; and nobody could say what request rate the orchestration layer would actually sustain before it fell over.
What I built
A WhatsApp AI agent pilot on n8n — 22 workflows, 357 nodes, all mine. Twilio handles inbound, and the orchestration routes each conversation into a 5-tool agent. Conversation state lives in Redis in three parts:
- a debounce list, so a burst of consecutive messages produces one reply instead of three
- a durable attribute hash that survives restarts
- a 10-turn memory window for context
On top of that, a stale-reply guard drops an in-flight reply when a newer message from the same user has already arrived — the fix for the failure mode that makes an agent feel like it is arguing with the past.
How it works
Each inbound webhook is debounced, then dispatched into the agent graph with the conversation's Redis state hydrated. Tool calls are executed as n8n sub-workflows, so an individual capability can be changed without touching the orchestration. I also authored fleet sync and backup tooling covering 9 n8n instances and 5,558 workflows, because a workflow platform without a backup path is one bad edit away from being unrecoverable.
Evidence
I load-tested it to destruction: 30,300 requests ramped from 26 to 940 requests per second. The system holds a ~65 sustained req/s ceiling, with 70.7% timeouts beyond it. The diagnostic detail is that successful throughput stayed flat regardless of arrival rate — that flatness is what proves a saturated worker pool rather than a network limit, and it points remediation at concurrency rather than at bandwidth.
What I owned
I built this platform end to end: all 22 workflows and 357 nodes, the Twilio inbound orchestration, the 5-tool agent, the three-part Redis conversation state and the stale-reply guard, plus the load-test harness that found its ceiling and the fleet sync and backup tooling across 9 n8n instances. This system runs internally and has no public repository, so there is nothing to link.
Stack
n8n · Twilio · Redis · LLM tool calling · Python (load-test harness and fleet tooling)