WhatsApp AI Replies After 24 Hours: A 16-Case Send-Permission Gate

Posted on Nov 5 • Originally published at agentic-whatsup.com

Decision in one sentence: never let an AI decide whether a WhatsApp message may be sent; evaluate permission from timestamped conversation state, approved-template status, purpose-specific opt-in, suppression records, and an available human escalation route, then let the model draft only within the permitted envelope.

If your team is building the underlying assistant, the business-chatbot automation guide on Agentic WhatsUp gives the broader workflow context; this article narrows the problem to the last control before a message leaves your system. That distinction matters. A model can write a polite, accurate answer and still produce an impermissible send because it used an old inbound timestamp, treated an approved template as universal permission, or missed an opt-out recorded in another channel.

The reusable asset here is a 16-case synthetic acceptance fixture and a small Python pre-dispatch gate. It is a design exercise, not a production benchmark: no customer conversations, real sends, delivery logs, or template approvals were measured. Its purpose is to make the policy boundary testable before an integration reaches customers.

The current WhatsApp Business Messaging Policy says that a business may message people who gave the business their mobile number and opted in to receive subsequent messages. It requires businesses to respect requests to block, discontinue, or otherwise opt out, including requests made outside WhatsApp. For the WhatsApp Business Platform, a business may reply without a Message Template during the 24-hour customer service window. The window opens and resets with each user message. Outside it, the policy says businesses may send messages only through approved Message Templates. The policy also permits automation during the window but requires a prompt, clear, direct path to human help.

The recurring operational question is simple: “The customer asked us something yesterday, we did not answer in time; can the bot continue in free text today?” A public Front community support discussion records a user asking how to contact a customer after the window expires. A Front product-education representative explains that a vendor cannot override Meta’s window and that an approved template is required. This is one support exchange, not evidence of how common the problem is. It is useful because it exposes the decision teams need to encode: a delayed response is still outside the window unless the customer sends another message or an eligible template is used.

The failure often begins earlier. A ticket is assigned to a queue, an assistant generates a response, a retry is delayed, and a scheduler wakes after the window has closed. If the send service only stores last_message_at on a ticket snapshot, a newer message may exist in a different event stream. If the AI itself chooses a template based on semantic similarity, it can select an approved template for a purpose that does not fit the message. If opt-outs are stored in a marketing CRM but not in the messaging service, the dispatch layer may not see them. These are architecture gaps, not writing-quality defects.

The send decision should therefore be recomputed immediately before dispatch, against a consistent state version. A decision made when the draft was generated is stale as soon as a customer replies, opts out, changes channel preference, or a template is paused. Treat draft creation and send authorization as separate transactions.

The gate can be expressed as a sequence:

The time calculation is not “24 hours after the last agent message.” The policy describes a user-message window. Store timestamps in UTC, preserve the source event identifier, and compare using a single trusted clock. The exact platform boundary and delivery behavior should be verified against the live product documentation and your provider integration; do not infer success from a local API request returning accepted.

This is an operator matrix, not a substitute for Meta’s complete policy or legal review. It intentionally separates the platform window, contact permission, template qualification, and automation handoff. If your product has a business-initiated conversation path with additional eligibility rules, encode those explicitly rather than adding exceptions to an “open window” boolean.

The table below is the article’s original reusable asset. The 16 rows are synthetic test cases drafted on 5 November 2026. The sample size is 16 scenarios; it is not a sample of customer behavior, and no rates, accuracy, or operational outcomes are claimed. The cases deliberately test state changes and boundary conditions, rather than estimating how often each failure occurs. Excluded: real WhatsApp API calls, actual template approval records, jurisdiction-specific legal analysis, media messages, pricing, and account-quality effects.

The “exactly 24 hours” row is deliberately conservative. The policy says a window lasts 24 hours and resets with each user message, but systems can differ in timestamp precision, rounding, queue delay, and the moment they validate eligibility. A local implementation should test the provider’s boundary behavior and keep a safety margin; it must not claim that one millisecond edge behavior is guaranteed by this fixture.

The most important implementation choice is the source of truth for latest_user_message_at. Use the event that represents a customer-originated message accepted by the platform, not an agent reply, outbound template, webhook retry, or ticket update. Deduplicate events by provider event ID. Persist both the event timestamp and ingestion timestamp: the former describes when the message happened, the latter helps diagnose late arrival. If your provider’s timestamp semantics are unclear, document the uncertainty and validate with test events before relying on it.

The check and send are vulnerable to a time-of-check/time-of-use race. Suppose the gate sees no opt-out, returns allow, then an opt-out event arrives before the outbound request is committed. A naïve service still sends. Reduce this risk by serializing sends and suppression updates per recipient/business-number pair, or by checking a monotonic state version at the dispatch boundary. If the version changed, cancel the send and evaluate again. If the provider call itself cannot be atomically coordinated with your database, write an outbox record containing the authorization version, recheck immediately before network dispatch, and make the outbox worker reject stale records.

Retries deserve their own policy. A network timeout does not tell you whether the platform accepted the first attempt. Use provider message IDs and idempotency mechanisms where available; do not generate a second message just because your client did not receive a response. A retry after a delay may cross the 24-hour boundary, so reauthorize at retry time. A template approved when the first attempt began could have changed status before retry. Store the attempted payload classification and permission evidence, then fetch current eligibility before each external attempt.

Suppression should be a high-priority deny signal with defined precedence. If a customer says “stop” in WhatsApp, a marketing list removal in email, a privacy preference center, or an agent records a phone request, the send gate needs a consistent policy for whether that request suppresses one purpose or all business messaging. Meta says to honor opt-out requests even when received outside WhatsApp; local laws may impose additional requirements. Never let the language model reinterpret a suppression event as “they probably only meant this campaign.” A human may resolve ambiguity through a permitted channel; the automation should not guess and send.

Templates are often treated as content artifacts: someone gets one approved, then teams reuse it for many flows. For a robust send gate, a template record should contain immutable ID, current platform status, approved language, locale, category or declared purpose, variable schema, owning workflow, approval timestamp, last verification timestamp, and the policy or account context in which it was approved. The sending workflow should reference a specific version. If the message body can be materially changed by AI after approval, you may no longer be sending the approved template in the intended form.

Do not let the model author a free-form paragraph and wrap it in a template-shaped shell. Bind variables to typed fields with maximum lengths and allowed sources. If a variable is populated from a model, validate it against the template’s intended meaning and reject unbounded generated content. Avoid putting sensitive information into a template variable unless that purpose and data use have been reviewed. Keep a human review route for novel or ambiguous template situations.

An approved template also does not prove the recipient opted into that purpose. Template approval is platform content eligibility; contact permission is recipient and jurisdiction eligibility. The gate must require both where applicable. Conversely, a valid opt-in does not permit a non-template message outside the platform’s service window. Treat these as conjunctive checks, not substitutes.

The WhatsApp policy allows automation in the 24-hour window only when a prompt, clear, direct human escalation path is available. A hidden email address in a terms page is not a useful operational handoff. The user should have a straightforward way to reach a person from the automated interaction, and the service should route the conversation with enough context for the human to act. The policy lists examples such as in-chat transfer, phone, email, web support, a store, or a support form.

For an engineering acceptance test, define what “available” means. Is a human queue staffed now? Is there a callback or ticket path outside staffed hours? Does pressing “talk to a person” stop the model from continuing to send? Does the human see the conversation and the reason the automation escalated? Is there a timeout that tells the customer what will happen next? These are design questions, not extra words in Meta’s policy, so label them as recommendations.

The OECD AI Principles call for human agency and oversight, transparency, and accountability across AI system lifecycles. They are high-level recommendations, not a WhatsApp compliance checklist. They support a governance inference: an escalation path should be testable and traceable, rather than existing only in product copy. BCG’s discussion of generative AI in customer service describes human-in-the-loop patterns and recommends starting with bounded use cases; BCG is a consulting perspective, not an independent controlled evaluation. Use both as design context, not proof that one architecture will achieve a performance result.

Create a decision log that answers why a particular send was allowed or denied without retaining a shadow copy of every conversation indefinitely. A useful record includes a pseudonymous recipient key, business phone number key, request ID, purpose, template ID and version, latest inbound event reference and timestamp, opt-in evidence reference, suppression lookup result, escalation configuration version, state version, decision, reason code, policy reference version, and dispatch outcome. Store content only when your privacy and retention analysis justifies it.

Monitor the shape of decisions, not only delivery volume. Track counts of allows, denies, holds, stale-state rechecks, unknown provider outcomes, and human escalations by workflow. These are operational counters, not proof of compliance. A low deny count could mean a well-designed workflow or a broken suppression integration. Review a sample of records against source events and configuration changes. Do not present a synthetic test suite or internal count as an industry benchmark.

The wrong timestamp wins. An agent message updates the ticket’s updated_at, so the system mistakes it for a customer message and opens the window. Store the provider’s customer-message event separately and test event types. A webhook arrives late. The scheduler sees a closed window, but a valid customer message is in transit. Hold briefly or refresh from the authoritative provider state where available; never assume missing means open. A retry crosses the boundary. Recheck at each attempt and do not reuse the initial authorization.

The assistant keeps talking after handoff. Escalation is displayed but does not disable further automation. Make handoff a state transition that stops the bot’s outbox worker for that conversation until a defined release condition. The human route is unavailable. Pause autonomous replies or offer a direct alternative that satisfies the product’s intended handoff. The provider accepted the request but delivery is unknown. Mark outcome unknown, reconcile using provider IDs, and avoid a duplicate retry. The AI generates a new template. Never treat a generated message as approved simply because it resembles approved copy.

For reproducibility, record fixture revision, test code revision, policy page retrieval date, timezone assumptions, and expected reason codes. The 16-case set is a starting checklist, not comprehensive coverage. Extend it for your account’s template lifecycle, supported locales, provider semantics, regulatory markets, and multi-number architecture. When an official policy changes, update the source note, review the decision table, and rerun the fixture. Do not update a threshold just to make tests green; establish why the requirement changed.

decision, reason = authorize ( request_with_opt_out ) assert decision is Decision. DENY assert reason == " recipient_suppressed " assert dispatch_calls == [] Enter fullscreen mode Exit fullscreen mode Also test the gate itself for missing fields and malformed data. A naïve timestamp parser can turn None into “now,” a timezone-naive value can be interpreted in the server’s local timezone, and a stale template cache can outlive an approval change. Keep parsers strict, inject the clock in tests, normalize to UTC, and reject unknown enum values. These are ordinary software correctness controls that matter because a successful API call has an external recipient.

Meta’s policy is the source for the platform boundary in this article. The exact live wording should be checked before implementation and after policy changes. The OECD AI Principles provide broad governance concepts around oversight, transparency, and accountability; they do not specify WhatsApp message eligibility. The ICO direct-marketing guidance illustrates that direct-message marketing can fall within electronic-marketing rules in the UK, but it cannot determine the legal result for every country or every service message.

UK ICO guidance is not a global rule, and the applicable legal result depends on market, subscriber type, purpose, and facts. Its value here is to show why the product must classify service and marketing purposes rather than treating the platform window as a legal permission. A service response about an existing order and a promotion embedded in the same response may require different analysis; if the message includes promotional content, have the responsible privacy or legal owner review the classification.

The BCG article is useful as a consulting viewpoint on bounded customer-service automation and human involvement, but it is neither a neutral benchmark nor a measured evaluation of this gate. The Front discussion and other public help/forum material show that users ask how to continue after the window closes; they do not establish prevalence, and forum advice can be incomplete or stale. Video search was performed for current demonstrations and implementation explanations, but a caption transcript could not be obtained for a potentially relevant video during this research pass. No video is used as evidence here. The gap is explicit so that lack of transcript access is not mistaken for evidence that no useful video exists.

If any answer is “unknown,” do not make the AI more autonomous to compensate. Hold the outbound action, resolve the missing state, and keep the model in a drafting role until the deterministic permission gate can explain its decision.

Next, introduce a shared authorization service or library at the dispatch boundary. Do not rely on each product team to reproduce the window formula. The service should accept a typed request, retrieve current state, return a decision plus reason code, and provide a short-lived authorization token tied to an event version. The sender must reject an expired token or one bound to a different recipient, number, purpose, template, or content classification. Keep permissions narrow: a token for an order-status template should not authorize a promotional send.

Roll out in observation mode only if this does not accidentally send. Observation mode should calculate and log what the gate would decide while existing human-controlled dispatch remains in place. Compare decisions with source records and investigate disagreements. Do not collect full message bodies by default just to make debugging convenient. Once the state mappings and reason codes are stable, enforce the gate for one bounded workflow and monitor held and denied cases with a named operational owner.

The model layer should receive an explicit allowed action description, not raw authority to call a send tool. In an open window it may propose a relevant support reply, but the authorization service still decides. Outside the window, it may draft a permitted template variable or suggest a handoff; it must not create or choose an unapproved free-form workaround. If your assistant has tool use, the send tool itself must enforce authorization. Prompt instructions alone are not access control.

Several systems may show different conversation times: Meta webhook time, provider receipt time, CRM update time, agent activity time, and local database write time. Do not choose whichever timestamp makes more messages eligible. Define event semantics. For the window rule, the important input is the customer message event recognized by the platform. Store the raw provider timestamp, parsed UTC value, provider event ID, and ingestion timestamp, and make the derived window state traceable to that event. If two events arrive out of order, recompute from the latest valid customer-message event under the provider’s ordering semantics.

For template status, cached approval can disagree with the current provider state. The system should have a freshness policy and a failure response. If current status cannot be obtained, hold a campaign send rather than assuming approval persists. The business may choose a cached status for a narrowly defined period if the provider guarantees its semantics and the risk is assessed, but that is a documented engineering assumption, not a fact supplied by the synthetic fixture.

The asset uses 16 manually designed cases, prepared on 5 November 2026 from the policy boundary and common integration failure patterns. It includes no production data, no measured acceptance rate, no API test, and no statistical inference. There is no random sampling frame and no denominator for “how often” a WhatsApp business encounters a closed-window send. The expected outcomes are design recommendations grounded in the stated policy, not observed system behavior. The test set excludes legal analysis outside the UK example, nuanced template categories, policy enforcement outcomes, and every provider-specific webhook edge case.

The recommendation is strongest where it mirrors explicit platform-policy language: customer-service window, approved templates outside the window, opt-out handling, and human escalation for automation. It is an engineering inference to use a separate deterministic gate, immutable event references, reason codes, and state-version checks. The 30-second buffer in the code is an illustrative safety margin, not a policy requirement; replace it with a documented choice informed by your queue latency and provider validation behavior. A strict API integration may expose a different boundary mechanism, so test against current official documentation and a controlled account.

An AI reply pipeline should answer two different questions in order: “What response would help?” and “May this response be sent to this person through this channel now?” A language model can help with the first. Permission, template eligibility, suppression, purpose, current time, and handoff availability answer the second. Keep those decisions independently testable.