Set Reply Delay
Use this action when a contact writes in fragments — one thought split across several rapid messages — and the agent should wait for the last fragment before answering, so all of them get one reply instead of one reply each.
Best for
- Contacts who send "split messages" (three or four short lines in a row)
- Letting the agent tune its own pace mid-conversation, through a tool
- Going back to fast answers once the contact wants them
How it works
Every channel has a reply debounce window (replyDebounceMs in the channel options). After a contact's message arrives, the agent waits that long; if another message arrives inside the window the wait restarts, and the agent answers everything at once when the window closes.
This action stores a per-conversation override of that window. It stays on the conversation until it is changed or cleared — it is not per run and not per message.
Main fields
| Field | What it does |
|---|---|
| Delay in seconds | A CEL expression that evaluates to the wait, in seconds, after the contact's last message. 0 replies immediately; values above 60 are clamped to 60. Leave it empty (or evaluate to null) to clear the override so the channel setting applies again |
The field is a CEL expression on purpose: an agent tool reaches an action only through its actions[] steps, and the step binds the tool's arguments. A plain number could only ever hold a static value.
What later steps can use
| Output | Meaning |
|---|---|
replyDelayMs | The override now stored on the conversation, in milliseconds (0 = reply immediately), or null when it was cleared |
Read it with get(step(N), 'replyDelayMs'). This action publishes at the step root — there is no data object.
Giving it to an agent as a tool
Create a tool named ajustar_ritmo_de_resposta with one parameter:
| Parameter | Type | Description |
|---|---|---|
delay_seconds | number | Seconds to wait after the contact's last message before answering (0 to 60). Omit to go back to the channel default. |
Add one step to the tool with the action Set reply delay and bind its field to the argument:
delay_seconds: args.delay_seconds
Then tell the agent when to use it. A prompt that works:
If the contact sends their message in several short fragments in a row, call
ajustar_ritmo_de_respostawithdelay_secondsbetween 8 and 10 so you can answer all fragments at once. If they ask for faster replies or start writing complete messages, call it again with a small value (or without a value to reset). Do not mention the tool to the contact.
Tips
- 8–10 seconds is a good window for fragment writers; anything above 20 seconds starts to feel like silence.
0is a valid value and means "reply as soon as the message lands" — useful for contacts who complain the agent is slow.- The override survives across runs. If the contact's habit changes, reset it; nothing resets it for you.
- Inside a manual workflow run there is no conversation, so the step fails with
agent_set_reply_delay_no_conversation. It is meant for agent tools and conversation-bound workflows.