Why Zendesk's AI Agent Kept Asking Clarifying Questions

zendesk, ai-support, vendor-evaluation, ai-agent

Zendesk's September 2026 release notes fix two specific bugs in how its AI agent runs a conversation: it could ask clarifying questions indefinitely instead of ever handing off, and it kept talking with a generic prompt after finishing a task instead of going quiet. Neither is a model-quality bug. Both are about what the surrounding code does after the model answers, not about the model itself — which is exactly the layer we were writing this same month, building the AI agent whose rollout starts with our own workspace before it reaches paying ones plan by plan. Removing the two failure modes turned out to mean not building the mechanism that makes them possible, rather than patching around it once it exists.

What Zendesk actually shipped

Two fixes, both in Zendesk's own September changelog, both admissions about behavior that shipped and ran in production before somebody fixed it:

The clarifying-question loop. If a customer's request is still unclear after two rounds of clarifying questions, the agent now escalates to a human instead of asking a third. Before this release, apparently, it just kept asking.
The post-task chatter. When a procedure finishes, the agent now waits for the customer's next message instead of jumping back in with a generic "how can I help?" Before this release, it volunteered that line unprompted, every time.

Read together, they're the same underlying question asked twice: what does an agent do the instant it doesn't have a next thing worth saying? Loop, or stop and hand off. Fill the silence with a template line, or actually stay silent. Zendesk's answer, both times, is a rule bolted onto an agent that was designed to keep talking by default — a counter that trips after two rounds, a wait state after a procedure ends. The bugs existed because the agent's baseline behavior was "say something," and somebody had to go back in and carve out the two cases where saying something was wrong.

Why a clarifying loop doesn't have a natural exit

An agent that's allowed to ask a follow-up question before answering has to decide, every single turn, whether it now knows enough. That decision has no built-in floor. Nothing about "ask a clarifying question when the request is vague" tells the agent to stop asking when the third answer is exactly as vague as the first — from the model's seat, round three looks identical to round one. Zendesk's fix is a counter sitting outside that decision, watching it from above: after two rounds, stop asking regardless of what the agent itself would have decided.

Replium's agent doesn't have that decision to make, because it never gets a second turn. Retrieval runs once, against the workspace's own published knowledge-base articles, before the model is ever called. The model then gets exactly one instruction that isn't "answer the question": answer only from the excerpts, or if they don't cover it — or the visitor asks for a person outright — reply with exactly one fixed token, NO_ANSWER, and nothing else.

Visitor asks something the agent has no queued answer for

↓ retrieval over this workspace's own articles, once

One model call: answer from the excerpts, or the fixed token

(no box here asks the visitor a follow-up — nothing reads a reply to one)

Excerpts cover it → the answer is sent

Conversation stays open for the next question, same as before.

They don't, or the visitor asked for a person → one fixed sentence, once

The mark that keeps a person owed an answer is set in the same write. Nothing further from the agent in this exchange.

Two outcomes, decided once. The clarifying-question loop needs a third box between retrieval and the outcomes — one that asks again and waits. There isn't one to remove.

There's no clause that lets the model ask the visitor something back first. The application code that reads its reply looks for exactly two shapes — an answer, or that one fixed token — and there's no third path in the sense that matters: nothing routes a "can you clarify?" back to the model for a second pass, because that code was never written. A loop needs a state machine willing to go around twice, and this one has no edge that points back at itself.

The honest cost of that is real, not a rounding error: an agent that can't ask a follow-up also can't run anything that needs one. Order lookups that require an order number the visitor didn't mention, refunds that depend on which item, a procedure with branches — all of that needs at least one clarifying round, and ours doesn't have the round to spend. It answers what a published article already covers, in one shot, or it says a person is coming. The design that makes the loop structurally impossible is the same design that rules out the class of task the loop exists to serve.

Why an agent keeps talking after the job is done

The second bug is the mirror image: an agent that treats every idle moment as a cue to say something, because a state machine with no "done, stay quiet" state defaults to filling the gap. Zendesk's fix adds that state after the fact — wait for the customer's next message instead of volunteering a line.

Replium's agent has an explicit terminal state for this, and it was a deliberate call rather than an accident of scope: once a person enters a conversation the agent was answering, that conversation's agentState becomes PAUSED, and nothing moves it back for the rest of the conversation. The code comment recording that decision is dated 2026-09-19 — a few days before this article, and worth naming instead of glossing over, because "the agent stays quiet forever after a handoff" was itself a decision made once and written down, not a property that fell out of the architecture for free the way the missing clarifying-loop is.

What the agent is allowed to say when it can't answer is fixed, too — one sentence, written by us, not generated: it names that a person is coming and stops there. There's no follow-up clause, no "let me know if there's anything else," because the model isn't asked to write that sentence in the first place; it's a lookup, not a completion. That handoff is one-directional in the same way we described on the human side of a transfer in an earlier look at what actually moves when a conversation changes hands: nothing is copied into a summary and nothing is reconciled afterward, because the agent isn't writing to a second record — it's the same conversation, with one message added and one column flipped.

Two questions worth asking about any conversational agent, not just an AI one

Both bugs generalize past "AI agent," to anything that manages a back-and-forth with an unpredictable number of turns — a support bot, a wizard, a phone tree, a human process with a script. Two questions catch both shapes, in your own system or anyone else's:

Is there a hard stop on "ask again," or does the loop rely on the thing doing the asking to decide when to quit? A counter bolted on from outside is a patch; no second turn to spend is the fix that needs no patch. Either works, but only one of them needs maintaining.
What does the flow say the instant its job in this exchange is finished — nothing, or a line it says every time regardless of context? If the answer is a line, ask who wrote it and whether it changes if nothing changed since the last time it fired. A fixed sentence that fires once is a design choice; the same sentence firing on every idle tick is the bug Zendesk just fixed.

Where Replium stands on this

We should be precise about what shipped, because "we have an AI agent now" undersells how narrow it is. It answers a visitor's question from the workspace's own knowledge-base articles, or says once that a person is coming. That's the whole feature. One model, through one OpenAI key we hold rather than one per workspace. One channel: the chat widget, not email. Gated behind a feature flag rolling out plan by plan and a switch each workspace owner turns on themselves. It does not run procedures, does not take actions, does not ask a clarifying question, and does not choose a model or a region — a workspace's data goes wherever our one shared instance already lives, not to a region the customer picked.

That last point cuts against the two fixes this article is about, not just alongside them: the reason our agent can't loop on clarifying questions is that it can't ask one at all, and the reason it can't chatter after finishing a procedure is that it doesn't run procedures. If what you need is an agent that walks someone through a multi-step process — collecting an order number, branching on the answer, confirming before it acts — ours isn't that, and the same design that keeps it out of Zendesk's two bugs is exactly why.

What we can say plainly: every claim in this article is checkable against the same code it quotes from, not a roadmap slide — the same register we used when we read our own MCP server's tool contracts instead of describing them from memory. That's the actual trade a small vendor offers instead of a bigger one's release notes: not a better agent yet, just a shorter distance between asking for a fix and one landing.

If a retrieval-only agent that answers from your own articles, or says once that a person's coming, is what you're evaluating — create a workspace and turn it on for yourself. Self-serve, an email confirmation, no card.