Flow Builder, Action Flows, Advanced, or Custom Agent: what goes where
If you want to automate in Zendesk today, you face four tools that overlap and call one another: the classic Flow Builder, Action Flows, AI Agents Advanced, and the new Custom Agents. The docs explain each one, but not which one holds up when. This map comes from running seven agents in production, not from the brochure.
The four tools, one paragraph each
Flow Builder is the conversation-based classic. Entry is keyword-based: free text gets matched to an intent by similarity. From there it runs predefined paths, step by step, fully deterministic. It can make API calls mid-conversation and show responses, but it can’t reshape data. The moment you need more than passing data through, you hit the wall that the blueprint Flow Builder at the product’s edge describes. That’s no reason to write it off; more on that shortly.
Action Flows are the workflow layer behind it: deterministic sequences with everything you need for them. Loops and while-loops, conditions (no nesting yet), Custom Code (synchronous only), API calls, and standard connectors into systems like Outlook. The connectors have rough edges. You can’t wire up a different Outlook account per flow, for instance; testing is where you find out whether you need a separate API connection via Custom Actions. And their remit no longer stops at the deterministic: a Custom Agent can be dropped in as a step and takes over the point in the flow where something has to be interpreted.
AI Agents Advanced (formerly Ultimate) is the most powerful of the four inside a conversation: it runs deterministic dialogs and generative ones, searches knowledge with AI (RAG), can embed Custom Agents, and with the Action Builder plus JSONata it brings along the data transformation the Flow Builder needed a detour for. On top of that, by far the best auditability of the whole lineup: every session variable and every API call is inspectable, and every decision an LLM makes comes with a reason. Its turf is conversations. Backend and back-office processes with no dialog behind them belong to Action Flows and Custom Agents.
Custom Agents, finally, aren’t chatbots but specialized workers on the Resolution Platform: they get instructions in natural language, actions, and knowledge sources, expect defined input, and deliver defined output, but the path in between is theirs to decide. They can’t set off on their own. They’re called from Action Flows or procedures, and Action Flows let you chain several of them together. That makes them the missing link on the road to an Autonomous Workforce. They’re still young, though: the logging doesn’t come close to Advanced, a ticket ID is required input, and any change to inputs or outputs drags along changes in the calling flow.
One more word on Flow Builder
Don’t underestimate it. For narrow, clearly recurring requests it’s still strong; you just have to use it deliberately instead of for everything. Nail a handful of those use cases cleanly and you can pull 50% Automated Resolutions out of it. The key is understanding how it matches free text.
Not by exact keyword, but semantically. An intent’s example phrases get turned into vectors (embeddings), the incoming message too, and what’s compared is their proximity in meaning-space, usually via cosine similarity, put simply the angle between two vectors: the smaller it is, the closer the meaning. So what’s measured is closeness in meaning, not sameness of words. That’s the strength, «account locked» matches even when nobody writes it exactly that way, and the same mechanism is the trap.
A telling detail sits in Zendesk’s own recommendations: you should drop filler words like «I» or «you» from the training phrases. That only makes sense if vectors are being averaged and compared behind the scenes: common words that show up in nearly every phrase across all intents, pull every sentence vector toward the shared center, and squeeze the differences between intents together. Throwing them out sharpens things. For a model that «understands» the sentence, you wouldn’t need to recommend that in the first place.
How far the matching reaches, you find out fastest with deliberately absurd inputs: a black-box stress test instead of realistic input. Two from my own operation. A use case I’d trained with «Biology» fired on «deoxyribonucleic acid»; in meaning-space DNA sits right next to biology, which is almost still logical. Harder: I typed just «bear», and «gambling block» triggered, not a «didn’t understand», a genuine match. No human contacts support like that, sure; but that’s the point of the stress test. Whether «bear» sits next to «block» in the embedding (conceivable via a «trail closed due to bear» line from newspaper text) or whether the threshold simply sat too low and a context-free word landed on the nearest available intent, I’ll leave open; from the outside you can’t prove it. What’s interesting isn’t the cause but that the system reaches this far off the mark at all.
That turns into craft: keep an intent’s example phrases broad and sharply separated, filler words out, and after launch analyze the false triggers, not just the hits. That approach lifted my rate of correctly recognized intents from 25% to 75%, three times as high. I never had to prove which metric does the math at the core; it was enough to read the behavior off the absurd case and build from there. The operational result is what counts, not the architecture diagram.
One caveat remains, and for many it settles the question anyway: in new Zendesk instances the old Flow Builder is gone entirely. Start today and you begin one level up; this section then only applies to existing setups.
The rule of thumb
As long as the task is deterministic, use Action Flows. The moment it turns non-deterministic, reach for a Custom Agent.
Deterministic means: the sequence can be written out entirely as if-then, fetch data, reshape it, check it, pass it on. That’s the everyday case, and it’s what Action Flows are built for. Non-deterministic means: somewhere in the sequence something has to be interpreted, understand free text, recognize intent, derive a decision from unstructured input. That’s where agentic reasoning earns its keep, and not a step sooner: an agent doing an if-then job is just a more expensive and less predictable version of a flow. And because the Custom Agent fits into the flow as a step, it’s not an either-or question: the frame stays deterministic, only the one interpreting spot goes agentic.
And Advanced? Whenever the conversation is the center: that’s where it’s the most powerful tool, from deterministic dialogs to AI search to an embedded Custom Agent. For processes with no conversation behind them, the rule of thumb above applies.
The decision matrix
| Criterion | Flow Builder | Action Flows | AI Agents Advanced | Custom Agents |
|---|---|---|---|---|
| How it runs | deterministic, keyword-based dialog | deterministic, workflow | deterministic and generative, dialog | agentic, task |
| Data transformation | no | yes (Code synchronous only) | yes (Action Builder, JSONata) | yes (within its instructions) |
| Interpret free text | intent matching only (similarity-based) | yes, via Custom Agent step | yes (incl. AI search/RAG) | yes |
| Traceability | medium | medium | very high (session variables, API calls, reasoned LLM decisions) | medium |
A case for the Custom Agent: from production
An example from a regulated environment, where the rule of thumb flips: certain accounts get checked every 24 hours. Rarely, but not never, Compliance leaves a free-text note in the system along the lines of «if this account is opened before date X, please contact Compliance». Too rare to check by hand every day; too unstructured for an if-then rule.
So a Custom Agent takes over: it gets the account data and analyzes the note. Is it from Compliance? Is it about an account opening, a closure? What actions were taken on the account? From that it derives whether a report is needed. If so, it creates the Zendesk ticket to Compliance. The deterministic frame (daily run, defined data in, ticket or no ticket out) stays a flow; only the one spot where something has to be interpreted is agentic.
public/werkstatt/bauplaene/agent-typen-entscheid/custom-agent-builder.png
Taking it further: same pattern, new cases
Once you see the pattern (deterministic frame, interpreting core), you quickly find more candidates:
Ticket reviews. A webhook sends closed tickets to an Action Flow, the Custom Agent evaluates them for quality and anything that stands out, and the result lands as a Custom Object or directly on the ticket. The evaluation is interpretation work, everything around it stays flow.
AI monitoring on a 24-hour cycle. This one’s on my workbench right now: every 24 hours, all AI tickets along with their conversation logs get pulled and handed to an Action Flow; a Custom Agent rates the conversations and sends the bot manager suggestions for improvement. That automates the quality assurance of the automation itself: the agent keeping an eye on the agent.
What’s still outstanding
Flow Builder, ZIS, and Advanced have been running in production for me for years; these assessments are operational experience. Custom Agents, on the other hand, are still young for everyone, me included: the Compliance case is running, the ideas from the last section are at the workbench stage, and a long-term verdict on maintenance and limits is still outstanding. The moment there is one, it gets added as its own blueprint.