Skip to main content
Updated Oct 9, 2026

Channel options: reply debounce

What you'll learn
  • Why contacts who send "split messages" used to get several replies
  • How the per-channel Reply debounce window groups them into one answer
  • How runs are serialized per conversation, and how an agent can tune the window itself
  • How a reply from your team pauses the agent in that conversation, and what happens to a reply the agent is still working on

Many people write one thought as several short messages: "hi", "I have a question", "about my order". Before the reply debounce existed, every one of those messages started its own AI reply, so the contact received two or three answers that repeated or contradicted each other.

Every channel now has a Reply debounce window (milliseconds) option under its Options tab.

How the window works​

The window is trailing-edge: it starts again on every inbound message. The agent only starts its reply once the contact has been silent for the whole window, and that single reply covers everything the contact sent meanwhile.

  • Default: 3000 ms (3 seconds) on every channel type. On email channels an unset value means 0, because one mail is already one complete thought.
  • Range: 0 to 60000 ms. 0 replies immediately.
  • Text fragments are joined into one message for the agent. Media, option replies and other non-text messages are kept separate and handled in order.

The wait is short compared with the time the agent itself needs to think, so a 3-second window is rarely noticeable — and it is far less confusing than three overlapping answers.

One reply at a time, per conversation​

Independently of the window, AutoTalk now runs at most one agent reply at a time per conversation. If a contact sends another message while the agent is still working on the previous one, that message waits and is answered right after — by a run that has already seen the first reply. This holds even when the window is 0.

If the AutoTalk service restarts while a message is waiting, a background job picks it up within about a minute. Messages that waited for more than six hours are not replayed; they are marked as ignored with the reason stale_queue_expired so nothing stale is answered out of context.

Letting the agent tune the window​

An agent can notice that a particular contact writes in fragments and adjust the window for that conversation only, using the Set reply delay action (actions/agent/lifecycle/session/set_reply_delay). The override is stored on the conversation as Agent reply delay (milliseconds) and is visible in the conversation details; an operator can edit or clear it there too.

Precedence, highest first:

  1. the conversation's Agent reply delay override, when set;
  2. the channel's Reply debounce window option;
  3. the built-in default (3000 ms, or 0 for email).

Where the company-wide setting went​

The former company-level option "Wait time before the bot responds (milliseconds)" has been removed. It was a fixed delay counted from each message rather than a real trailing window, and it did not survive a service restart. Configure the window per channel instead, as described above.

Pause after a human reply​

When someone on your team replies by hand in a conversation — from the channel's own app (for example the WhatsApp phone connected to the channel) or from the Inbox — the AI agent pauses in that conversation so it does not talk over them. Two things happen:

  • The pause. By default the agent stays quiet for 60 minutes, and every further human message adds another 60 minutes. Set the channel's Pause after a human reply (minutes) option (1 to 10,080, i.e. up to a week) to change this: the agent then stays quiet for that long after the last human message, and later human messages restart the pause instead of adding to it. A longer pause that is already running, such as one the agent set with Pause agent replies, is kept. For example, 1,440 keeps the agent out of a conversation for a day after your team last wrote in it. To go back to the default, clear the field and save.
  • The reply in progress is held back. If your team writes while the agent is still working on an answer, the rest of that answer is normally not sent, and the agent stops working on it: it makes no further model or tool calls. This covers the agent's own answer, each message of a reply made of several messages (even when the agent waits between them), and the messages its Compose conversation response and Send message to contact steps send to this same conversation, whether those steps run in a tool, as a pre-action or after a structured output.

The hold-back is a safeguard, not a guarantee that the agent stays silent once your team has written:

  • Messages that reach the contact another way are not held back: those sent by a workflow the agent runs, by a function called on a record (for example the contact's sendMessage function through Execute function on document), or by an Execute code step.
  • If AutoTalk cannot read the conversation to check for a reply from your team, it lets the agent's reply through rather than silencing the agent.
  • Messages to other contacts, such as a notice the agent sends to a colleague, are not held back either. Because the agent stops working on the reply, though, a notice it would only have sent later does not go out.

Messages the contact sends during the pause are kept in the conversation but not answered by the agent, so make sure someone on your team follows the conversation. You can resume the bot at any time from the conversation's settings menu.

Notes:

  • The pause applies to the conversation where your team replied, not to the whole channel.
  • On the official WhatsApp Business API, AutoTalk does not process messages typed in the WhatsApp Business app, so there only replies sent from the Inbox pause the agent and hold back its reply.
Last updated on
On this page