What changed in the current experience
Zendesk’s creation guide says newly created agents use agentic AI by default. It documents Messaging, Email (including API and web form), and Voice creation flows. Each agent has one channel type; an account that needs both messaging and email needs separate agents.
The 2026 package change expanded formerly Advanced capabilities, including dialogue builder, use cases, generative procedures, and richer automation. That does not mean an old configuration automatically migrated. Zendesk’s migration guide applies to Essential and legacy bot builder, answers, and intents; it says manual recreation is available now and an in-product tool is planned later in 2026.
Build the first job deliberately
For Messaging, the path is AI agents workspace > Dashboard > Create AI agent > for Messaging. Choose the brand and connected knowledge base; a brand without active knowledge needs a knowledge base or crawler before the flow can continue. Add a crawler only for current, appropriate pages. Then set business profile, tone, languages, and system replies.
| Control | Decision to make |
|---|---|
| Knowledge | Which exact policy is approved for this job? |
| Procedure or dialogue | What order of questions and checks is required? |
| Action | What lookup is allowed, and what change remains human-owned? |
| System reply | What should happen at greeting, uncertainty, error, and escalation? |
| Handoff | Which team receives the case and what happens when it is unavailable? |
Save and close preserves the configuration without making it live. Go to activation opens channel selection; choose the intended channel and confirm activation there. The creation flow is not evidence that the job is safe.
Test the channel, not just the prompt
Before activation, test a routine request, missing or conflicting knowledge, an action failure, a request for a person, and the customer-facing fallback. Inspect the visible copy, source or procedure used, ticket state, receiving team, and failed-escalation path. For email, test the acknowledgement and the team’s actual response expectation; for messaging, include availability and an after-hours path. A result in a test pane does not prove native routing works.
Use eesel to propose a narrow test plan
eesel’s CLI controls the same workspace teammate as the dashboard, not a separate sandbox. A support owner can ask Claude Code to prepare a test plan from the teammate's current instructions and an approved brief. Before a chat, get the workspace owner's permission and inspect connected sources and action permissions; chat is real, billed work. Use a fictional order-status case; do not use it to create a Zendesk agent or alter a customer record.
npx @eesel/cli status --agent "Zendesk support"
npx @eesel/cli integrations --agent "Zendesk support"
npx @eesel/cli instructions --agent "Zendesk support"
npx @eesel/cli new --name "order-status-test-plan" --agent "Zendesk support"
npx @eesel/cli chat "Fictional test brief: delivery-status answers require verified identity and an order reference; a missing reference or failed lookup goes to Support Operations, and order changes require a human. Propose a test plan for a normal request, missing order number, failed lookup, and human handoff. State expected customer wording and evidence to inspect. Do not send a message, change an order, or modify configuration." --agent "Zendesk support"
Node.js 18.17+ is required and commands return JSON. A support lead can use it from a terminal, while scripts and coding agents such as Claude Code, Codex, and Cursor operate that same eesel workspace with its existing permissions. Have the owner compare the plan with the policy, permission boundary, and receiving team before testing the real Zendesk channel. The coding agent can turn differences between the plan and the current eesel instructions into a proposed edit. An owner checks that change and tests the revised teammate before rollout. The CLI proposal itself does not activate or validate Zendesk's native agent. Use --dry-run where supported for a later owner-approved write.
Roll out one job at a time
Use eesel CLI to prepare and review the teammate's test plan, then verify the actual customer channel. Start with a request that has current knowledge and a clear exception path. Add an action or another channel only after the first job is accurate, safe, and inspectable.
Frequently asked questions
What is the current Zendesk new AI agent experience?
New Zendesk AI agents use agentic AI by default and support Messaging, Email including API and web form, and Voice.
How do I create a Zendesk Messaging AI agent?
Go to AI agents workspace, Dashboard, Create AI agent, then for Messaging. Connect knowledge, configure the agent, and review it before activation.
Is the Zendesk Essential migration tool available now?
Manual recreation is available now; an in-product tool is planned later in 2026.
Do all former Advanced customers need to migrate?
No. The removal notice concerns Essential and listed legacy functionality, not every previous Advanced buyer.
What should be tested before activation?
Test normal and exception cases in the actual channel, including failed actions and handoff.
How can eesel CLI help with this evaluation?
A person, script, or coding agent such as Claude Code can inspect the same eesel teammate and workspace as the dashboard, prepare a topic-specific review, and propose configuration changes. Owners approve writes and test outcomes; a CLI proposal does not prove Zendesk-native routing or resolution rates.
