Every WhatsApp Enquiry, Answered In Seconds, Not Tomorrow Morning.

A full agent turn (retrieval, a tool call, a second model round trip) routinely took 15 to 30 seconds. The provider's own webhook rules call anything over 10 seconds slow and retry on a 10s / 30s / 5min ladder, and nothing in the handler recognised a retry as a delivery it had already seen, so every retry re-ran the entire pipeline from scratch.

The provider's own delivery id became a database primary key, claimed before any work starts. A second delivery of the same id fails the insert and is dropped immediately. The actual reply now runs after the HTTP response is already sent, so the provider gets its fast acknowledgement and stops retrying, while the agent still gets its full 15 to 30 seconds to think.

Replaying the identical delivery id twice through a signed test webhook produced one inbound row, one AI reply, and one email on the first call, and a no-op response with zero further writes on the second, checked directly against the live database.

Tool calls are not part of the conversation memory the system persists, so every reply was built from scratch with no record the lead tool had ever been called before. The rule was 'submit once everything is present,' and once that became true it stayed true on every following turn.

The submission decision moved out of the model's memory and into an append-only leads table in the database. Every reply is now told, in plain language, exactly what was last submitted for that contact and instructed not to submit again unless something has actually changed.

A fresh conversation was qualified, submitted once, told 'no changes needed' twice with zero further sends, then had its budget changed, which correctly produced a 'why did this change' question with no send, and only sent again once a reason was given.

Retrieval returned the numerically closest chunk to the question, which happened to be a caution rule about never stating an unlisted detail, written to guard a licence number or a direct line. The prompt never stated the company's own name as a plain fact, so the model generalised that caution to cover its own identity.

The company's name now sits directly in the system prompt as a known, always-safe fact, with an explicit note that the 'don't state unlisted details' rule governs licence numbers and direct phone lines, not the company's own identity.

The exact question that failed was re-sent through the live pipeline after the fix and answered correctly.

The conversation-memory table stored each turn as a flat object with the message text directly on one field. The code reading it assumed a more commonly documented nested shape one level deeper, so every read silently returned empty history with nothing to point at the cause.

Writes were checked against the table's actual real rows rather than a documented convention. Reads now accept either shape, so both the existing rows and any newly written ones work uniformly.

Confirmed by inspecting the table's live rows directly, not by trusting the shape that was assumed at first.

The authentication layer's route matcher did not exclude API routes, so an unauthenticated call to the webhook endpoint, which is every call, since the provider never carries a login session, was silently redirected to the login page instead of ever reaching the handler.

An explicit early-return guard for any API path was added inside the authentication check itself, plus a matching exclusion in the route matcher, so the same failure cannot come back if either safeguard alone is later reverted.

Found by calling the endpoint directly and noticing the redirect rather than the expected response, ahead of production use.