A customer has a question for an online retail store. They go to their website, fill in a form and select their reason for contact. They enter some additional details, and submit the form. Triggers within Zendesk run based on the selected contact reason, and the ticket gets assigned to the right group, where an agent picks up the ticket based on the order it appears in a view.

Sounds familiar? This is the classic trigger-based approach thousands of Zendesk customers have been using for almost two decades now.

Today we have a customer who fires up WhatsApp and asks "Yo! Where's my delivery at!" An AI Agent senses the customers' agitated state, and detects an order status use case. It replies to the customer "I'm sorry your food delivery is taking longer than expected. I'm here to help. Do you have an order number for me?"
The customer can't immediately find the right number, but after a few back-and-forth-s, the AI Agent gets the right info and lets the customer know their food should arrive momentarily. Customer frustration turns into satisfaction, and the conversation resolves.

Notice a difference? Where the classic flow formed a very rigid structure of form fields and triggers, the second scenario takes a vague and angry input, reacts to the sentiment and guides the customer to a resolution.

These are two basic examples of two different strategies of setting up your customer care environment. On one side we have a rules based deterministic approach, and on the other side an AI-powered agentic approach.

Confused? Let's dive in!

Agentic vs deterministic.

Software traditionally has always been deterministic in its approach. A certain set of conditions lead to a specific outcome and the steps in between are clearly defined. They're logic steps of predefined elements that are executed in a certain order. Specific inputs lead to predetermined outputs and the logic follows a very linear path which you can't really deviate from. Any answer that's not mapped will result in a failure or, if you persist, a loop.

On the other side we now have AI models that can power our software. Three great capabilities of modern AI models is their capability to understand language (LLMs), their ability to reason and their ability to retrieve data and convert that data to fit the prompt.

This means that where deterministic models expect a fixed input (a 5-digit order number), agentic models understand the notion of an order number and can explain the customer what they should provide, or grab that number from a longer response.
Additionally instead of following an exact workflow from step A to Z, an agentic model understands the goal of a process. It can dynamically adapt to the context, take vague input and generate an expected output. Conversations don't need to be linear. It can piece together the full context and gradually works towards a resolution.

If this seems a bit high-level, no worries, we'll dive into specific examples soon!

It might seem that now that we can build these agentic approaches we no longer need our old deterministic flows. However, this is not entirely true. Some flows are enriched by running them on agentic models. Just think about gathering order numbers, describing issues you're having with your laptop, or booking a flight. Any time where the customer can be vague and descriptive, and the agent can derive concrete input from that, an agentic approach wins.

But other scenarios actually get better with deterministic flows. Authentication for example. Or the logic that decides if a customer is eligible for a refund. That logic should always react the same and should always be based on fixed and exact input.

So it's the combination of both agentic procedures and deterministic workflows that create the best experiences for customers and human agents alike.

Now that we've defined the two approaches, let's see how we can leverage them in Zendesk today!

Categories vs intents

For sales, press 1. For support, press 2. For other questions, press 3.

Please choose a contact reason from the dropdown.

Select your product issue from this list.

Traditionally we've put the burden on customers to select their contact reason from a list. Even though they might have described their entire problem at length in the comment field, it's that category dropdown or IVR option that decides where their ticket ends up.

For the customer this means they are expected to understand your internal business logic. And a lot of repetitive steps selecting the same options in drop downs that might have been part of their comments already.
A question like "why can't I do x in Zendesk" could be a support question (educate where the feature is), or a sales question (a different license tier is needed). And for agents and reporting this means miscategorized tickets and queues that are filled with wrongly assigned tickets. There's a lot of manual work to make sure tickets end up with the right team, and are tagged correctly.

Thanks to Zendesk's Intelligent Triage, we can remove this entire approach and rely on Intents instead. The system understands the customers' contact reason based on the written comments, and automatically assigns the right intent to the ticket. Omnichannel routing can pick up this ticket, assign it to the right agent, the right procedures can be activated, and your reporting reflects the actual contact reasons.

Deterministic hard-coded categories got replaced with automatic intent detection. Without any human effort a list of 10 categories is turned into dozens of nuanced contact reasons, your overloaded other category is now correctly mapped, and intent suggestions turn previously unknown contact reasons into opportunities for improvement.

Making the shift from hardcoded categories towards modern intent detection is not that complex. As long as you validate the mapping and add your initial set of missing custom intents, the process goes quite smooth. Most of the work lies in a one-time adaption of your triggers, queues and reporting.

Moving from manual ticket categorization to AI-powered intent detection in Zendesk

Migrating from ticket field categories to Zendesk Intents isn’t hard. By reviewing existing categories, refining and renaming intents, adding custom ones, and validating results, you can replace manual tagging with AI-powered triage for faster, smarter customer support.

Internal NoteThomas Verschoren

Forms vs conversations

Here's an example of a typical interaction a customer might have with a chatbot:

Chatbot: What do you want to do? [book a flight, modify a flight, cancel a flight]
Customer: Book a flight to Budapest on May 4th.
Chatbot: Where do you want to fly to?
Customer: Budapest
Chatbot: What day do you want to depart?
Customer: May 4th
Chatbot: please provide the data in DD/MM format
Customer: 04/05
Chatbot: How many days do you want to stay there?
Customer: three days

While the interaction might be conversational, in essence we're filling in a form with category, destination, start date, duration fields. It works, but it feels rigid and forced since the Chatbot ignores the customers' additional context and forces all answers into the predefined question-answer format.

Let's compare that to a conversation driven via an agentic procedure:

AI Agent: How can I help you?
Customer: I'd like to fly on May 4th to Budapest and three days later.
AI Agent: Great. That's the destination and departure date set. Just to make sure, before I can book your flight, you'd like to return on the 7th?
Customer: Yes that's right.

The above shows the power of an Agentic flow. We can detect all the required input for our flow in a customers' message (category, destination, start date), we can detect the duration, and just for safety we can validate our logic by asking the customer to confirm the return date.

For the customer, this leads to a way nicer experience. The more context they provide up front, the faster the AI Agent can help them. There's no need to restate previous information to fit the format, but the AI Agent will still validate any confusing input, or ask for missing context.

This logic can be build on top of both procedures for AI Agent Advanced, where you describe the required input, or via entity detection and procedures for Agent Copilot.

Zendesk Entity Detection for Intelligent Triage (EAP)

The new Entity detection for Zendesk Intelligent Triage allows you to now not only know why customers are contacting you, but also know what they are talking about.

Internal NoteThomas Verschoren

Workflow vs procedure

The previous example also highlights another difference. If our customer confused Budapest and Bucharest, the Chatbot example wouldn't be able to handle that.

Chatbot: How many days do you want to stay there?
Customer: three days, and also I wanted to go to Bucharest, not Budapest
Chatbot: I need a single digit.
Customer: 3
Chatbot: great. Here's a few options [...]
Customer: I want to go to Bucharest
Chatbot: Please pick an option [...]
Customer: I WANT TO TALK TO A HUMAN AGENT!

Whereas, if built correctly, an AI Agent would handle this as follows:

AI Agent: How can I help you?
Customer: I'd like to book a flight for May 4th to Budapest and three days later.
AI Agent: great. Just to make sure, you'd like to return on the 7th?
Customer: The 7th is ok, but I actually wanted to go to Bucharest.
AI Agent: Sure thing, here's a few options for Bucharest, departing on the 4th, returning on the 7th. [...]

Instead of not being able to handle a jump out of the logic, our AI Agent can update the context and continue the procedure while taking the new destination into account.

Towards automated resolutions #3: Procedures as the blueprint for automation

Procedures turn your support processes into automated workflows. Use them with an AI Agent for full automation, or as Agent Copilot procedures to guide human agents. Document your processes, identify repetitive steps, and build procedures that close the gap between knowledge and action.

Internal NoteThomas Verschoren

Predefined vs generated

Before AI Agents became capable of generating responses over email, we had auto-reply with hardcoded responses based on intents. Similarly, both Answer Bot and Ultimate had their respective flow and dialogue builders that contain hardcoded responses within flows. And similarly, human agents have macros at their disposal that contained canned responses, with {{placeholders}} being available for some limited customisation.

With the arrival of LLMs, we shifted towards AI Agents Essential and Advanced and Agent Copilot's suggested replies. They all have the capability to turn indexed knowledge sources into generated responses, catered specifically to a customers question, context and sentiment.
AI Agent Advanced' agentic procedures can generate custom responses to customers based on API integrations, knowledge sources or predefined steps.
Agent Copilot's auto-assist mode has those same capabilities on the agent side. Generated comments to customers that take previous tickets, knowledge articles and procedures into account.

Each answer is unique and personalised for that customer interaction, while still being guarded by the content on your Help Center, or the structure of your procedure. Answers feel more human, less automatic and often lead to better customer feedback.

There are use cases where you don't want these dynamically generated responses. Answers that contain terms and conditions for example. Or sensitive topics where exact language is important. So while most procedures will shift towards these generated responses, some will remain static and predefined. And you know? That's perfectly fine.

Concrete vs vague input

Zendesk triggers support webhooks to integrate with external systems. The trigger contains an action step that invokes a specific webhook, and within that step you also define a JSON payload.

{
  "order_number": "{{ticket.ticket_field_<field ID number>}}",
  "customer": "{{ticket.requester.externalId}}",
  "type": "cancellation"
}

These JSON payloads contain predefined inputs, often in the form of {{placeholders}} that reference user or ticket fields. And while having these hardcoded structures makes for a stable API, in reality this input is fragile. If an agent forgets to set the ticket field, or if the value is in the wrong format, the API call will fail.

When Zendesk developed their new custom actions and API integrations for Agent Copilot and AI Agent Advanced respectively, they did away with this hard link between the input and API call.

When we setup an integration for these new AI-powered processes, we define a set of input parameters.

These inputs are available to our procedures:

Ask for an order number and retrieve the status via /get order status

The procedure knows it needs to look for that 5-digit order number within the conversation context, and pass that along to the API integration. Vague input is turned into a concrete variable with no chance of human errors.

Similarly, these new custom actions for Agent Copilot also do away with hardcoded outputs. While we still need to define an output variable, we no longer need to define each key within an API calls output. The procedure can interpret a JSON output and as long as its keys are logically named, it'll be able to find e.g. an order status.

{
  "data": {
    "order_number": 42,
    "order_status": "shipped",
    "tracking_code": "THX1138"
  }
}

And if we later want to also share the tracking code with the customer, we can tell our procedure just that. No new variables to define, no new logic to build:

If a tracking code is available, share it with the customer.

As Zendesk's custom action platform grows, and we start adding support for MCP, this will become even easier. Instead of defining each API call manually, we can connect to a platforms' MCP service, and we get automatic support for any current, and future, actions that platform offers, once again moving us from predetermined setups towards dynamically defined AI-first setups.

Rebuild vs iterate

When you're defining use cases with a workflow-based solution like Action Builder, or Dialogue Builder, you're building out a predefined logical structure of your process. This means your workflow should take all scenarios into account, and provide graceful fallbacks for unexpected input (often: an escalation to an agent).

Making changes to these flows isn't easy either. If you've ever tried to move a logical branch of your workflow up a few levels, you'll know exactly what I mean. Updates to your logic often means rebuilding most of your entire decision tree from scratch again, making sure you handle each unique branch you create. You need to cut-copy-paste section of your flow, add new conditional steps, and handle all end-points to make changes.

Compared to the new agentic procedure builder in AI Agent Advanced or Agent Copilot, it's a whole different experience. Changing logic for these flows is as simple as changing the prompt. In the case of Agent Copilot that means editing the text and moving some paragraphs around. In the case of AI Agents Advanced it means telling the procedure builder what it should change.

Changing behaviour means editing prompts, not refactoring code - source

This seemingly small difference turns building procedures from something that requires a developer mindset, into something anyone can do as long as you know your company's processes and have some experience with prompting.

And although this difference might seem to be just an interface difference, one being text based, the other being diagram based, there's an underlying second difference. Where Dialogue Builder expects you to handle all branches and take all edge cases into account, agentic procedures can handle thesee edge cases with judgement.
For example, you don't need to write and build an entire logical loop to ask the customer for an order number, with all the retry logic written down. With agentic flows you can just write "ask the customer for an order number (5 digits long)." and the AI Agent will handle all retry and validation logic automatically.

Hybrid flows

As you might have read in between the lines, setting up a modern Zendesk is not a choice between deterministic or agentic approaches. In reality you'll end up with a hybrid setup where the process and conversations are driven by agentic systems, but where guardrails and important logic will be done with deterministic rules.

And it's that balance between agentic freedom and deterministic assurance that will allow you to build powerful systems you can trust.

Let's take two examples: Zendesk's Action Builder and Omnichannel Routing.

Action Builder

So far in our story we've been focussing on moving away from dialogue builders towards written procedures. They allow for easier iteration, more dynamic conversations and faster integration setups.

But as Zendesk is pushing their agentic procedure builders forward, it's also developing their Action Builder. A more rigid, workflow based tool that allows you to build logical decision trees.

At first glance this might sound backwards. We're pushing forward agentic logic instead of dialogue builders, while also investing in the same toolsets we're shifting away from with the workflow based Action Builder.

However, there's a catch. Not every procedure should and can be fully agentic. If a customer asks for a refund, the decision wither they're eligible is really well defined. Depending on the age, cost and type of order they are or aren't eligible. In most cases that logic will be able to clearly say yes or no.
In those cases, a procedure can take care of both the input (contact intent, order number, refund reason), as well as the output (yes, we can certainly refund your order, let me take care of that now..). Agent Copilot guides our team through the entire process, and no human decision making, aside from approving the suggested steps, is needed.
But in some cases an entirely automated flow isn't possible. Maybe an approval is needed and we need to escalate. Or the answer is no but since the attempt was fraudulent, we need to alert our Finance team.

So this a perfect example of a hybrid flow. The agentic procedure takes care of the entire conversation, and often even up to the resolution. The decision logic is wrapped in a deterministic Action Builder workflow, and when that fixed workflow detects specific escalation scenarios, it'll do so.

As Action Builders' capabilities expand, you can start seeing setups where Agent Copilot's procedures take care of the entire process, but where specific decisions or actions are offloaded to an Action Builder workflow. Use cases that require fixed logic like "Is this a VIP user", "Can we still change this booking", "Is this fraudulent or real?". They require predefined input, and output expected values. The agentic procedure are there to turn vague answers into that input, and turn API outputs into customer friendly responses.

Omnichannel Routing

A completely different part of Zendesk where we might benefit from a combination of agentic and deterministic logic is Omnichannel Routing.

Omnichannel routing is, in essence, a set of rules that determine which ticket should end up with which agent, and in what order. Each queue contains a set of conditions (intent, customer type, channel,...). Queues handle tickets based on a timed condition (SLA breach, date of creation, ..) and assign to agents based in skills, availability and capacity.

An introduction to Omnichannel Routing in Zendesk

This article will give you an overview of Zendesk’s Omnichannel Routing, Agent Availability and the brand new Queues features.

Internal NoteThomas Verschoren

The input for these routing rules is very specific, and the outcome is deterministic. Any french-speaking customer with an order intent will be assigned to our Paris-team, where Jacques and Annette have the required sales-inquiry skills. And since the customer is angry, the priority will be high.

What's not so specific is how we derive that context. Intelligent Triage reads a customers' comments and derives a sentiment, intent and language from that. Vague input turned into concrete output. Before we had these capabilities, that routing had to be done based on either a customer manually selecting a category field, or tickets only being routed correctly after someone manually assigned the right category as part of their triage role.

In the future we'll be able to take this one step further. Admin Copilot recommendations can detect intents with bad customer satisfaction and suggest a boost in priority to handle these quicker. Or it can detect that we always manually reassign Canadian customers to our Quebec team, and suggest we create a separate queue for these customers, splitting up our french queue into two.

Here too, our routing logic is still predetermined, but the intelligence and insights around it can use vague cues and undetected patterns to suggest improvements.

And if we move one step further, you could even imagine a future where we do away with hardcoded queues altogether. A system that dynamically routs tickets based on its predefined goals.
These goals could be "evenly balance complex tickets across agents", or "higher csat over lower handling time". Or "on average we want to handle sales inquiries first, support inquiries second, except if there's a serious incident".
Or, if we have a spike in a specific intent, make surewe provide decent reply times on all other queues too".

While we do not have these capabilities today, it's easy to see how we could, in theory, abstract away those predefined queues and replace them with prompts where we just tell our system how the routing should be adapted. Or where our system tells us what the best dynamic setup is based on the current conditions, and we just approve its ideas.

After all, we're just humans separated by screens

Agentic, deterministic or hybrid. No matter what solution you choose for your setup, in the end they still work towards a single goal and that is to assist us, humans, in getting or providing answers.

What I like about these new AI-powered approaches in the Zendesk platform is that they make everything more accessible.

For customers, being able to just describe an issue, and having an AI Agent detect use cases, entities is way easier than filling in fields and providing exact answers. There's a reason most of us prefer a call with a human instead of an email. Conversations is what we do as people. Filling in forms is what we do for governments and chatbots.

For agents, getting the right context from customers, having ticket fields automatically filled in, and next steps in a process suggested, gives them room to focus on the customer, while being sure that the process will move forward correctly.

For CX team leads, it gives them control over the tools they use. Instead of asking a developer to build a form, or bot-builder to build a dialogue flow, they can write their process down, and it'll just work. Yes, there's still the complexity of API integrations, but once those are build or connected, they become just building blocks for them to use.

That leaves us with two big elements that are currently not agentic yet. One is the whole experience of setting up the core of Zendesk itself. While the AI suggestions already propose ideas on what triggers, macros or procedures to modify, actually making changes to the platform itself still requires a dive into the Admin Center. And similarly, anyone who wants to get decent insights from the platform needs to build out reports via complex queries in our Analytics tool.

Readers who've seen my AI Summit overview already know what the future will bring. Admin Copilot and Zendesk's recent HyperArc acquisition will provide a solution for these last two elements. But while we've seen a preview of both in October last year, it's waiting till Relate 2026 to hopefully get more info.