Customer support was always going to be one of the first places AI agents landed at scale. The inputs are natural language. The tasks require judgment. The volume is high. The cost of manual handling is significant. It’s a near-perfect fit.

A year into seeing teams deploy support agents on Korelos, a few patterns have become clear about what separates the deployments that work from the ones that don’t.

What’s working

The teams getting the best results are treating agents as a first-pass resolution layer, not a full replacement for human support. An agent handles the 70% of tickets that follow recognisable patterns: order status, refund requests, password resets, account questions. It escalates cleanly when it encounters something outside its scope.

This approach consistently achieves 60-70% ticket deflection without degrading CSAT scores, which was the fear going in for most teams. When the agent escalates well, users don’t feel like they’ve been stonewalled. They feel like the agent tried and knew its limits.

What isn’t working

Two failure modes come up repeatedly. The first is over-scoping the agent’s initial capabilities. Trying to make one agent handle everything creates a system that handles nothing particularly well. Starting narrow and expanding beats starting broad every time.

The second is poor escalation design. An agent that can’t gracefully hand off to a human, complete with the context of what it tried and why it failed, creates a worse experience than no agent at all. Escalation is a feature, not a fallback.

The tools that matter most

Across all the support agent deployments we’ve seen, there are four tool integrations that show up in every high-performing setup:

• Order/account lookup (read access to your core data)
• Ticket creation (for creating support records and escalating)
• Knowledge base search (for policy and product questions)
• Action execution (refunds, cancellations, plan changes — with appropriate guardrails)

The last one is where most teams are cautious, and reasonably so. Giving an agent write access to take actions on behalf of users requires careful scoping and robust logging. But it’s also where the biggest resolution rate gains come from.

Getting started

If you’re considering a support agent deployment, the fastest path to something useful is to pull your last 500 tickets, categorise them by type, and identify the three highest-volume categories that follow a predictable pattern. Build an agent that handles exactly those three categories well. Ship it. Measure. Expand from there.

The teams that try to solve every ticket type in the first version rarely ship. The teams that start with a narrow scope almost always do.

Korelos has been in private early access for six months. In that time we’ve worked closely with about a dozen teams across customer support, internal operations automation, and research. The common thread across every successful deployment hasn’t been the model or the prompt. It’s been how the team thought about tools.

Lesson 1: Most teams ship with too many tools

The instinct, when you sit down to build an agent, is to expose every API your company has. “The agent can do anything.” In practice, the more tools you expose, the worse the agent’s planning gets. We saw one team with twenty-eight tools whose agent was getting confused about which to use, even on simple requests. They cut it to seven and accuracy jumped immediately.

Start small. Add tools when you can point at a specific failure that the missing tool would have prevented. Not before.

Lesson 2: Tool descriptions are prompt engineering

The descriptions you write for each tool are not documentation. They are part of the agent’s prompt, and the model is going to make routing decisions based on them. A tool described as “Looks up order status” will be reached for very differently than one described as “Retrieves the current shipping status, last carrier event, and delivery ETA for an existing order. Use this when the customer is asking where their package is.”

The teams that took this seriously got measurably better routing. The teams that didn’t kept blaming the model.

Lesson 3: Tool inputs should look like commands, not API requests

Models are good at producing natural-sounding intent. They are bad at producing the kind of nested, optional, type-strict JSON that REST APIs from 2018 expect. The teams that got the best results designed tool input schemas that read like how a human would describe the action: find_order(query) instead of orders.search({"filter":{"order_id":{"eq":...}}}).

If your real API needs the second shape, write a thin adapter. The agent never sees it.

Lesson 4: Outputs need a budget

Tools that return five-megabyte JSON blobs will eat your context window. Every tool needs to either return a small, summarized result, or return a handle that the agent can choose to expand. The default of “return everything the API returned” is the single most common reason agents fall over after a few turns.

The single biggest predictor of agent success isn’t the model. It’s whether the team treated tool design as a first-class problem.

What we’re doing about it

Most of what’s gone into the Korelos tool layer over the last six months has been about making these patterns the easy default. Tool schemas are validated against best practices when you create them. Output sizes are budgeted automatically. Tool descriptions are linted for the things we’ve seen go wrong in production. None of this is glamorous, and none of it is what an agent demo on day one cares about. All of it is the difference between an agent that works for a week and one that’s still working in six months.

We’re going to keep writing about what we learn. If you’re an early-access partner, expect this kind of post to be the norm. If you’re not yet, the waitlist is open.