Evaluate the system around the model
Claude can help developers build agents and workflows. That does not settle the customer-support design. The difficult parts remain: which policy is authoritative, which data the agent may access, what action is allowed, how an error is surfaced, and who owns a case that needs a person.
Start with one job, such as explaining a published return policy. Keep the answer grounded in a maintained source. If the job needs an order lookup, test identity, missing data, a provider error, and a request for a human before offering it to customers.
The 2025 releases relevant to support teams
On September 29, 2025, Anthropic released Claude Sonnet 4.5, alongside the Claude Agent SDK, API context editing and memory, plus Claude Code checkpoints and a VS Code extension. Those are building blocks for custom agents, not a finished support queue, policy source, permission system, or escalation operation.
On October 15, Claude Haiku 4.5 was released as a faster, lower-cost option, with Anthropic naming customer-service agents as a low-latency use case. On November 24, Claude Opus 4.5 became available in Anthropic apps, API, and major cloud platforms. These are dated 2025 release facts, not current plan promises. Verify today’s model, region, cloud, and account availability before choosing a production configuration.
| Change | What it can help build | What remains your work |
|---|---|---|
| Sonnet 4.5 and Agent SDK | Custom agents and tool use | Support UI, knowledge, permissions, monitoring, handoff |
| Haiku 4.5 | Lower-latency high-volume work | Quality thresholds, routing, costs, exception review |
| Opus 4.5 | More capable selected tasks | Whether its cost and capability fit the job |
Anthropic also introduced Agent Skills on October 16, 2025: reusable folders containing instructions, resources, and sometimes scripts. A support team might package its article-writing process or return-request checklist as a skill. Skills are not limited to engineers; Anthropic describes assisted skill creation in Claude apps as well as developer use. Review any included executable code and keep policy references maintained. A checklist helps define the work, but the connected system must still enforce who can read an order or issue a refund.
Measure the actual rollout
Do not turn a model benchmark or announcement into a predicted automation rate. Sample the conversations your team actually receives. Review correctness, policy compliance, the quality of escalation, repeat contact, customer feedback, operational response time, and the account's usage terms. A resolution rate without those checks can hide a confident wrong answer or an unresolved handoff.
Turn release questions into an eesel test plan
When a release prompts your team to revisit support automation, eesel's CLI gives you a practical way to inspect the job you already operate. Ask Claude Code, Codex, or Cursor to review the eesel teammate's instructions and connected sources, then prepare a small acceptance-test plan. A person or script can use the same commands and JSON output. The CLI works on the same teammate and workspace as the dashboard.
For example, test whether the teammate distinguishes an ordinary return from an exception. With the owner's approval, inspect connected sources and instructions through the CLI, and confirm actual action permissions in the dashboard and connected service. The integration list alone does not establish those permissions. Select a teammate suitable for the review and replace returns-support with it. Node.js 18.17+ is required. Chat is real, billed workspace work; fictional cases and no-action wording do not create a sandbox or change permissions.
npx @eesel/cli instructions --agent "returns-support"
npx @eesel/cli integrations --agent "returns-support"
npx @eesel/cli new --name "returns-acceptance-plan" --agent "returns-support"
npx @eesel/cli chat "Fictional policy: returns within 30 days require an order number; older requests and explicit requests for a person go to a human. Propose four test cases: normal request, missing order number, expired window, and human request. For each, state the expected answer and evidence to inspect. Do not send messages, change configuration or tickets, or approve actions." --agent "returns-support"
The returned plan should distinguish asking for missing information from granting an exception. The coding agent can compare it with existing instructions and propose a specific correction, rather than replacing the whole configuration. The support owner reconciles the fictional exercise with actual policy and approves the exact edit before it is applied. Use command help and --dry-run where supported to inspect the write; held-action approvals are not universal approval for CLI operations.
Run the approved cases in fresh conversations and inspect responses and activity. Preserve the inputs and expected outcomes so later changes can be compared against the same cases. Check actual helpdesk routing separately. This evaluates the configured support teammate, not a controlled benchmark of one Claude model against another.
Use model releases to identify questions worth testing, then use the CLI to gather evidence about the support job your team owns. Learn about eesel for Zendesk or try eesel.
Frequently Asked Questions
Can Claude support customer automation?
Claude can be part of a custom support automation system, but the team must still provide approved knowledge, tools, permissions, testing, monitoring, and a human handoff.
What should a support team test first?
Test one defined job with normal, missing-information, failed-action, human-request, and repeat-contact cases.
Do model improvements remove support risk?
No. Better model capability does not make an outdated source, unsafe action, or unstaffed escalation safe.
Who should own Claude support permissions?
The person accountable for the customer workflow should approve data access, action boundaries, and the exception path before use.
How should teams measure an automation rollout?
Review sampled conversations, correctness, escalation quality, repeat contacts, customer feedback, and the cost model for the actual account.
When is eesel a better fit?
eesel is a fit when the desired outcome is a ready-to-work helpdesk teammate rather than a custom agent system the team must build and operate.
How can eesel CLI help with this support workflow?
A person, script, or coding agent can inspect the same eesel teammate as the dashboard, propose instruction changes, and review JSON test results. An owner approves changes and checks action permissions first; chats use real workspace resources, and actual helpdesk delivery needs separate testing.
