Case study

Automating 70 Percent of Support Tickets with an Agentic Memory System

Outcome

70.2% of tickets resolved fully automatically, and rising

Client

B2B SaaS company, internal support operations (name withheld)

Industry

SaaS customer support, internal operations

Status

In production

My role

Architecture and implementation lead

Published

September 1, 2026

The client is not named under contractual confidentiality. Where this write-up says "we", it refers to the delivery team I led; the architecture decisions described are mine.

Context

The client’s support team was spending essentially all of its time on ticket triage and resolution, which left no capacity for the higher-value work a support organization is supposed to grow into over time. The deeper problem was not ticket volume by itself, it was that the team had no institutional memory carried forward between shifts or between people. The same categories of problem got re-investigated from scratch by whoever happened to pick up the ticket, because nothing captured what had already been learned the last time a similar issue came through.

That is an expensive way to run a support function. Every recurring issue costs the same investigation time the first time it was ever seen, indefinitely, unless someone writes it down somewhere people actually look. Nobody had built that “somewhere.”

The Problem

Technically, this is a routing and memory problem before it is a generation problem. The team already knew how to resolve most of their recurring tickets once someone correctly identified what was going on. The bottleneck was diagnosis, not fix authorship: finding out, quickly and correctly, whether an incoming ticket matched something already solved, and if it did not, giving the human who picked it up a running start instead of a blank page.

There was no existing automation here at all, so the constraints were less about legacy system limits and more about the risk of getting it wrong in the other direction: an agent that resolves recurring tickets correctly is a huge win, but an agent that confidently misdiagnoses a novel problem and takes the wrong action is worse than doing nothing, because it can update production systems or communicate incorrect information to a customer before anyone catches it.

Architecture

We built a multi-agent support system centered on a structured event memory of past incidents, their root causes, and their resolutions. When a new ticket arrives, the system first searches this memory for similar past incidents rather than starting reasoning from zero.

From there, the system branches on confidence. For well-understood, recurring issues that match memory closely, it automatically generates and executes the resolution: updating the ticketing system and notifying the relevant team directly, with no human step required in the loop. For anything new, ambiguous, or unfamiliar, instead of guessing, it hands the ticket off to a human, but does so with a clear, ranked summary of the most likely causes and the relevant supporting documentation already assembled. That handoff package is the difference between a human starting an investigation cold and a human starting a review with most of the groundwork already done.

Underneath this sits a controller architecture that keeps the routing decision, the retrieval step, and the execution step as distinct, auditable stages rather than one opaque model call, so we can see exactly why a ticket was auto-resolved versus escalated. Every resolution, human or automatic, feeds back into the event memory, so the system’s diagnostic accuracy compounds over time rather than staying static.

Results

70.2 percent of tickets are now resolved fully automatically, and that number keeps improving as the system accumulates more resolved cases in memory. The support team’s day shifted away from repetitive triage toward the higher-value problem solving that had previously been squeezed out entirely.

The result I did not fully anticipate going in: the team began routing even simple tickets through the system anyway, not because they needed the automation, but because the context it assembled, the likely cause, the relevant history, the supporting documentation, was a better starting point for an investigation than starting from scratch, even when a human was going to do the actual work. That is a stronger trust signal than the automation percentage on its own, because it means the team chose to use the system rather than being routed through it by policy.

What I Would Do Differently

I would have instrumented “recidivism” from day one: tracking not just whether a ticket was auto-resolved, but whether that resolution actually held, meaning the same underlying issue did not resurface from the same customer within some window afterward. We added that tracking a few weeks after launch once we realized the automation rate alone could hide a resolution that technically closed a ticket without actually fixing the underlying problem. It would have been better to treat “did this stay fixed” as a first-class metric from the start rather than retrofitting it once the system was already live.