AI Reply

Getting here

Automate → Workflows, open a workflow, click + on the canvas, then pick AI Reply under Add Steps.

Before you start

• An owner, admin or agent can add this step and save the workflow. Publishing that workflow — the thing that makes it run on live conversations — is an owner or admin action.
• Building and running workflows depends on your plan; see pricing.
• An AI agent set up for this workspace. The step answers as whichever agent is currently assigned to the thread, or the workspace's default agent if none is.

Set up

1. Open the workflow and click + where the AI should answer.
2. Pick AI Reply.
3. Optional: write an instruction — extra direction for this one step, added on top of the agent's own persona, e.g. "keep it to two sentences".
4. Add a step after it for the path where the AI did not answer — an Escalate or an Assign To (human), or a Condition on AI sent a reply.
5. Save the step, then publish the workflow.

Fields

AI instruction

Extra direction for this step only, appended after the agent's own persona — it does not replace the agent's setup, knowledge base or guardrails.

Default: empty

How it works

• Before generating anything, the step checks the AI kill switches in order: platform-wide, then this workspace's own AI switch, then the channel's — the same order and the same switches an inbound auto-reply checks. Any one of them being on fails the step with no message sent and no model call made.
• It then checks thread-level holds: a Pause AI / Unassign step earlier in this or another workflow, or a person already holding the thread (a teammate took it over, or the customer asked for one) both fail the step the same way — the AI does not speak on either, no matter what a workflow's own steps are otherwise allowed to send there.
• It answers as whichever AI agent is currently assigned to this thread (by Assign To (AI), or automatic routing), falling back to the workspace's default agent only when none is assigned — so a thread that already belongs to a specific agent keeps that agent's voice and knowledge base rather than switching to the default mid-conversation.
• It reuses the exact generation and confidence-gate pipeline an inbound message's own auto-reply uses — the same retrieval, grounding and metering — rather than a separate model call, so token usage and guardrails are identical either way.
• Generation is metered (tokens and cost recorded) whether or not the reply ends up being sent — the spend already happened once the model answered.
• What the model decided is written to ai.action (auto_reply / suggest / escalate), ai.confidence and ai.replied (whether a reply actually went out) — readable by a Condition step placed after this one.
• Only a decision of auto_reply with non-empty text is sent; everything else — suggest, escalate, or an auto_reply with no text — is treated as the AI not answering (see When it fails), and ai.replied is left false.
• If the agent currently answering has its own Auto-reply toggle off, the decision is suggest whenever it would otherwise have qualified to send — but a message the model reads as sensitive or an explicit request for a human still decides escalate regardless of the toggle, and a confidence below the platform's hard escalate floor does too. Either way this step never sends on that agent.
• A sent reply still goes through the ordinary send path, so it needs the 24-hour messaging window to be open on a windowed channel the same as Send a Message does, and it is recorded under the agent's own name, not the workflow's.
• If the customer sends another message while the step is generating or about to send, the step stops rather than answering a question that is no longer the latest one — the run halts on this step instead of continuing with a stale answer.

When it fails

• Before generation ever starts, several checks can fail the step outright, and NONE of them attempt to notify a human — a kill switch on (platform, workspace or channel), the thread paused by Pause AI / Unassign or held by a person, no customer message to answer (a booking, an order, a scheduled trigger started the run), or the agent could not be loaded. Each fails with its own reason and nothing is generated.
• Generation itself throws (a model or infrastructure error): the step fails with AI generation failed, again with no notify attempt.
• The model chose suggest or escalate — a genuine decline, AFTER generation completed: the step fails, ai.replied stays false, with the reason AI did not answer (escalate, confidence 0.20) (or suggest, with the model's real confidence), and THIS is the case that tries to notify a human. The push notification is sent every time this happens, with no deduplication; the in-app notification row IS deduplicated whenever answer.asked_at is already set on the run — which happens after any earlier Ask a Question step in the same run, not only when this step is itself retrying that question's own failure arm.
• The model returned an auto_reply with empty text (the generation pipeline produced a decision but no usable words): the reason is AI returned an empty reply (auto_reply, confidence 0.85) — a distinct reason so this is never confused with a deliberate decline. The same notify attempt runs as for a decline.
• The human-notification attempt itself can under-deliver, but not simply because the push failed: the in-app row landing is enough to count as "paged" even if the push reached nobody. The reason only gains — human page failed on a decline (never on an empty auto_reply), and only when the push reached nobody AND no in-app row landed (no assignee or workspace admin to write one for, or the row write failed). Either one landing counts as paged.
• The customer's message changed — checked both right before generation starts and again right after it finishes: either way, the step fails (no notify attempt either) and the run stops entirely at this step — later steps in the same run are not attempted on top of a reply that would have answered the wrong question.
• None of the failures above (except the stale-message one) stop the rest of the run on their own — the flow continues to the next step, on a thread nothing was sent to, unless you place an Escalate or Assign step (or a Condition on AI sent a reply) right after it.
• The reason for any of the above is in the workflow's Activity tab, under Execution log, on this step's line.

Limits

• It answers as the AGENT currently on the thread, not necessarily the workspace's named default — an earlier Assign To (AI) step changes who answers here.
• The instruction field adds to the agent's persona for this one step; it cannot override the agent's knowledge base, guardrails or the confidence gate itself.
• A low-confidence or declined answer does not retry inside this step — it fails once, tries to notify a human, and moves on. A retry needs another AI Reply step reached some other way (e.g. after a customer rephrases).
• The human-notification push has no deduplication of its own — every declined run of this step sends one, even if the last one was seconds ago. The in-app notification row IS deduplicated, keyed off answer.asked_at — set by any earlier Ask a Question step in the same run, not only one this exact step is retrying on behalf of.
• An agent whose Auto-reply toggle is off never sends through this step. The decision is usually suggest, but a message the model reads as sensitive or a direct request for a human, or confidence below the platform's hard floor, still decides escalate regardless of the toggle.
• Most failures on this step — every kill switch, both thread holds, no customer message, an agent that could not load, and a stale customer message — notify nobody at all: no push, no in-app row. Only a genuine decline (suggest/escalate) or an empty auto_reply tries to notify, and "tried" is not "succeeded": the push alone reaching nobody does not on its own mark the attempt as failed — the in-app row landing is enough.
• It does not pause the run to wait for anything — the step already generated and, if it qualified, sent its one reply by the time the run continues.
• It does not stop the AI from answering on other, unrelated workflows or on plain inbound messages to this thread — only the specific kill switches and holds listed in How it works silence it, and only for the duration they are set.

Best practices

• Always follow it with a human fallback on the path where the AI did not answer — Escalate or Assign To (human) — rather than relying on the step's own human-notification: most of this step's failures never attempt it at all (every kill switch, both holds, no customer message, an unloadable agent, a stale message), so it is a best-effort page on the decline path only, not a guarantee someone was told about every way this step can fail.
• Use a Condition on AI sent a reply rather than assuming success when you need the flow to branch differently depending on whether the AI actually spoke.
• Keep the instruction short and specific to this one turn — it is not the place to redefine the agent's whole personality for a single step.

Use cases

• Let the AI answer a routine question mid-flow, with Escalate right after it on the path where it declined.
• Ask the AI to summarise or restate something in one sentence as a specific instruction, inside a flow that otherwise follows a fixed script.
• Branch on AI sent a reply to decide whether to close the conversation automatically or hand it to a teammate.

FAQ and troubleshooting

Does AI Reply check the same kill switches as a normal inbound reply?

Yes — platform, workspace, then channel, in that order, plus the thread-level holds (Pause AI / Unassign, or a person holding the thread). Any of them silences this step exactly the way it silences an inbound auto-reply.

What happens if the AI isn't confident enough to answer?

The step fails, ai.replied stays false, and it tries to notify a human that the AI did not answer. Nothing is sent to the customer. The push side of that notification is not deduplicated — a workflow that keeps re-running this step pages fresh every time; the in-app row is deduplicated whenever an earlier Ask a Question step already set answer.asked_at on the run. Put Escalate or Assign after this step so someone follows up regardless.

The agent I assigned has Auto-reply switched off. Does AI Reply still work?

It generates and evaluates the reply, but this step never sends on that agent. The decision is usually suggest, though a message the model reads as sensitive or a direct request for a human — or confidence below the platform's hard escalate floor — still decides escalate even with the toggle off. Either way, a human is who ends up notified, not the customer.

Which AI agent answers if I've pinned this thread to a specific one?

Whichever agent is currently assigned to the thread — by an earlier Assign To (AI) step or automatic routing — not the workspace's default agent, unless none is assigned.

Does the run continue if the AI didn't answer?

Yes, unless the customer sent a new message while this step was working, in which case the whole run stops here. Otherwise the flow moves to the next step regardless — which is why a human fallback right after this step matters.

Related

• Ask a Question — Ask, then pause the whole run until the customer answers or a deadline passes — with typed answers matched deterministically against a fixed set of choices, never guessed by a model.
• Escalate — Pause the AI on this thread and page a human right now — the safety net at the end of a path the AI could not, or should not, finish alone.
• Assign To (AI) — Pin the conversation to one named AI agent for its next replies, overriding whatever would otherwise decide which agent answers.
• Assign To (human) — Hand the conversation to one named teammate, or spread it across the workspace by round robin or fewest open contacts, with an optional timeout message if nobody answers.
• Pause AI / Unassign — Silence the AI on this conversation and clear its agent binding, with no page, no note and no message — a quiet, workflow-internal hold meant to be lifted by a later Assign To (AI) step.
• Workflows: how a flow runs — A workflow is one trigger, optional conditions and an ordered list of steps; only a published workflow runs, and this article explains how a run starts, forks, pauses, fails and stops.