AI agents are quickly becoming a standard layer in customer-facing SaaS products, and AI agent workflows are becoming an important part of how these experiences are designed. But the interesting UX problem isn’t the chat window customers see. It’s everything that happens before and after the conversation.

Someone has to create the agent, define its personality, give it knowledge, decide what it can do, test its responses, determine where it should appear, decide when it should hand a conversation to a human, and continuously improve it once real customers start using it.

That makes AI agents fundamentally different from traditional SaaS features. A conventional feature might follow:

Configure → Save → Use

An AI agent is closer to:

Configure → Test → Deploy → Observe → Improve → Test again

We looked closely at how Zendesk and Sobot structure this experience, and compared their approaches with the broader direction of AI-agent products such as Intercom’s Fin.

The result is a useful picture of where AI-agent UX is heading, and what product designers can learn from it.

AI-agent UX starts long before the customer sends a message

When we think about AI-agent UX, the conversation interface is usually the first thing that comes to mind. But for the person building the agent, the experience starts somewhere else.

They need to answer questions like:

• What should this agent be?
• What should it know?
• How should it speak?
• What should it be allowed to do?
• What happens when it doesn’t know the answer?
• Where should customers encounter it?
• How do I know it’s ready?
• How do I improve it when something goes wrong?

These questions create an entirely different product surface. Zendesk and Sobot approach that surface in noticeably different ways.

Zendesk: Guide users from creation to deployment

Zendesk takes a relatively guided approach to AI-agent creation. The journey moves through a sequence such as:

Create AI Agent → Name → Voice/Tone → Brand → Test → Advanced Settings → Channels → Publish

The sequence is important. Instead of presenting users with one enormous configuration screen, Zendesk asks for a few fundamental decisions at a time:

Who is the agent?
How should it sound?
Which brand does it represent?
Does it actually work?

Only then does the user move into more advanced configuration and deployment. This is a strong example of progressive disclosure. AI agents can have dozens of settings, and exposing them all immediately would create unnecessary cognitive load. 

Zendesk gives users a relatively narrow path into a complex system. But creation isn’t the end of the experience. Once the agent exists, users can continue refining things such as personality, messaging behavior, supported languages, greetings, follow-ups, and human handoff messages. They can also test the agent while making these changes.

This changes the mental model. The user isn’t configuring a static feature. They’re shaping the behavior of something that will act on their behalf.

Sobot: Treat the agent as an operating system

Sobot takes a different approach. Instead of opening with a simple creation wizard, its AI Agent experience feels more like a broader operational workspace. The surrounding experience includes areas such as:

• Chat Details
• Answering
• AI Copilot
• Operations
• Customer Questions
• Suggestions
• Batch Testing
• Reception Records
• Settings

That distinction matters. Sobot’s mental model is less: “Let’s create an AI agent.”

And more: “This is an AI system that we need to operate.”

Its operational environment is part of the product. For example, Chat Details provides visibility into customer conversations, with filtering across factors such as date, channel, bot, and business type. The agent isn’t isolated from the conversations it handles. And that’s where Sobot introduces one of its most interesting ideas.

Let customer conversations improve the agent

Sobot can use historical conversations and tickets to identify knowledge gaps and recommend or generate knowledge for the knowledge base. The workflow can draw from sources such as:

• Historical conversations
• Live chat
• Tickets
• Call-center data

This creates a different relationship between the agent and its knowledge. The knowledge base isn’t simply something an administrator creates once.

Instead:

Customer conversations → Knowledge gaps → Generated knowledge → Better knowledge base → Better responses

For designers, this raises a more interesting question than: “Where should we put the knowledge-base settings?”

The better question is: How can the product help users discover what their AI doesn’t know?

Two different mental models

The difference between the products becomes clearer when we look at their creation flows.

Zendesk

Create → Define → Test → Configure → Publish

The user is guided toward a functioning agent.

Sobot

Choose bot type → Define → Configure capabilities → Configure behavior → Test → Operate

The user is given an environment for constructing and managing the agent. Neither approach is inherently better. Zendesk reduces complexity at the beginning. Sobot exposes more operational depth.

The real design challenge is: How much of an AI agent’s complexity should users see when they first create it?

For new users, too much configuration can be overwhelming. For experienced operators, hiding important controls can become frustrating. The strongest approach may therefore be neither “simple” nor “advanced,” but progressive complexity: reveal more control as the user’s needs grow.

The configuration problem: an AI agent has multiple layers

Across these products, another pattern becomes clear. An AI agent isn’t one configuration object. It has several distinct layers:

1. Identity

Who is the agent?

Name, brand, tone, personality, voice.

2. Knowledge

What does it know?

Help content, business information, documents, FAQs, and historical conversations.

3. Behavior

How should it act?

What should it say, ask, do, and when should it stop?

4. Capabilities

What can it actually perform?

Workflows, integrations, external actions, data retrieval, and transactions.

5. Escalation

What happens when the AI shouldn’t continue?

Ask for information, transfer to a human, route to a team, or end the conversation.

These layers are related, but they aren’t the same thing.

One of the biggest UX risks is putting all of them under one giant “AI Settings” experience.

Intercom’s Fin, for example, separates areas such as content, guidance, attributes, escalation, procedures, testing, deployment, and analysis.

The lesson for designers is simple:

Design the mental model before designing the settings screen.

Testing isn’t a final QA step anymore

This may be one of the biggest differences between traditional software and AI systems. In traditional SaaS, testing often happens after configuration. With AI, testing becomes part of configuration itself.

Zendesk allows agents to be tested throughout their lifecycle. Sobot incorporates testing into its bot-configuration experience. Intercom takes this further with Fin, allowing teams to generate test questions from previous customer conversations, add their own scenarios, and inspect responses before customers see them.

This creates a much better model:

Change something → Test a realistic scenario → Inspect the response → Understand the problem → Change the configuration → Test again

Testing is no longer simply: “Does the feature work?”

It’s: “Does the AI behave the way I intended?”

That’s a fundamentally different UX problem.

From bad answer to actionable fix

Testing also reveals another important requirement: AI failures need to be explainable.

If an agent gives a bad answer, telling the operator only that the answer was incorrect isn’t particularly useful. They need to understand why.

Was it:

• Missing knowledge?
• Incorrect guidance?
• An outdated source?
• A behavior problem?
• A workflow issue?
• An escalation rule?
• A misunderstanding of the customer’s intent?

Intercom’s testing experience allows operators to inspect the sources, guidance, and settings contributing to responses and provides recommendations for improving poor answers.

This creates a much more useful debugging loop:

Bad answer → Why? → Source/instruction / behavior → Fix → Retest

Instead of: Bad answer → Edit AI

For AI products, debuggability is becoming part of UX.

Deployment shouldn’t feel like flipping a switch

Traditional SaaS often has a simple deployment model: Draft → Published

AI agents introduce more risk. What if the agent works well for one audience but poorly for another? What if it performs well on web chat but poorly on email? What if the team wants to test internally before exposing it to thousands of customers?

Intercom’s Fin deployment experience demonstrates a more nuanced model, with controls around audiences, channels, handover behavior, and rollout conditions.

The model becomes: Build → Test → Internal rollout → Small audience → Monitor → Expand

Rather than: Build → Publish to everyone

This turns deployment into a confidence problem. The product shouldn’t simply ask: “Are you ready to publish?”

It should help users answer: “How confident are we that this agent is ready for this audience and context?”

Human handoff isn’t a failure state

AI-agent products also need to answer a critical question: What happens when the AI shouldn’t continue? The answer isn’t always “try harder.”

Sometimes the correct behavior is to involve a human. Intercom’s deployment experience, for example, includes handover configuration and can collect additional information before transferring the conversation to a teammate.

This reflects a broader principle: A good AI agent isn’t one that never asks for help. It’s one that knows when to ask for help. Human handoff should therefore be treated as a first-class flow, not an error state.

The handoff should be intentional, contextual, and preserve the conversation history so customers don’t have to start over.

The real product begins after launch

Publishing isn’t the end of an AI agent’s lifecycle. It’s where the real learning begins. Once an agent is live, teams need to understand:

• Which questions is it handling?
• Where is it failing?
• Where are knowledge gaps appearing?
• Which conversations are being escalated?
• Are customers satisfied?
• Is resolution improving?
• Did the latest configuration change help or hurt?

Intercom’s Fin experience connects performance analysis, topics, optimization, and conversations. Sobot’s operational and knowledge-suggestion workflows point in a similar direction.

The emerging model is:

Train → Test → Deploy → Analyze → Improve

The agent isn’t a feature that gets finished.

It’s a system that continuously evolves.

The emerging AI-agent workflow

Looking across Zendesk, Sobot, and more mature agent platforms, a broader pattern emerges:

1. Define: Give the agent an identity and purpose.
2. Ground: Give it the knowledge and context it needs.
3. Configure: Define behavior, capabilities, and boundaries.
4. Test: Challenge it with realistic scenarios.
5. Deploy: Choose where, when, and for whom it operates.
6. Observe: Understand what happens in real conversations.
7. Improve: Turn failures, gaps, and feedback into changes.
8. Test again: The important part is the final step. The workflow isn’t linear. It’s a loop:

Build → Test → Deploy → Observe → Improve → Test

And that changes what product designers need to design.

What product designers should take away

The biggest lesson isn’t that Zendesk has a better wizard or Sobot has more settings. It’s that AI agents are creating a new category of product UX. Designers aren’t only designing the interface customers use to interact with AI. They’re designing the interface through which humans manage a system that makes decisions on their behalf.

That creates a few important principles:

Don’t design one giant “AI settings” page

Separate identity, knowledge, behavior, capabilities, and escalation into understandable concepts.

Don’t make testing an afterthought

Let users test while configuring, not only after everything is finished.

Don’t just show that something went wrong

Help users understand why an AI response failed and what they can change.

Don’t make deployment binary

Give teams control over audience, channel, and rollout.

Don’t treat human escalation as failure

Make handoff intentional, contextual, and easy to manage.

Don’t stop at “Published”

Help teams understand what is happening after launch and turn those observations into improvements.

Most importantly, design the improvement loop

AI agents will encounter situations their creators didn’t anticipate.

The product should make those situations visible—and help users turn them into:

Knowledge → Guidance → Workflow changes → Better tests → Better behavior

The real shift in AI-agent UX

Zendesk’s guided setup shows how an AI agent can be made approachable.

Sobot’s operational model shows how much complexity appears once an agent becomes part of everyday customer support.

And products such as Intercom demonstrate where the category is moving: toward systems where knowledge, behavior, testing, deployment, analysis, and optimization are connected rather than treated as isolated settings.

We’re not simply designing a better chatbot. We’re designing the control plane around an autonomous system. The chat interface may be what the customer sees. But for the product team, the real product is everything behind it:

What the agent knows. How it behaves. What it can do. How we test it. Where we deploy it. When humans intervene. And how the system gets better over time.

That’s the real shift in AI-agent UX. The future of AI-agent UX isn’t just about designing better conversations. It’s about designing better systems for creating, controlling, testing, and improving those conversations.

………………….

Want to see how other SaaS products are solving similar problems?

On Watobu, you can explore real product screens and feature flows from leading SaaS products and see how these ideas are actually designed in the product.

Explore AI-agent and CX product flows on Watobu →