In 2025, our support team was nine people serving 1,500 companies and handling roughly 3,700 tickets per month. Like many companies, we used an AI agent to autonomously resolve simple, routine customer questions, which made up around half of our incoming tickets.
Those simple tickets accounted for about 10% of our support team’s time. The more difficult tickets were escalated to our support team.
For those escalated issues, our support team jumped between five or six tools to gather account and product context, search past tickets and logs, determine whether an issue was a bug or expected behavior, draft a reply, and loop in engineering when needed.
At first, we used Claude for straightforward questions, like whether we supported a particular integration. As MCP became more common, we connected Claude to the systems we normally searched by hand. It could fetch a ticket from Pylon, check Linear to see whether a feature request already existed, or answer product-behavior questions by searching our codebase using Cursor.
We also built an internal MCP server that let Claude securely access our database, logs, and other internal tools.

With that access in place, the team packaged the process into a Claude Skill called /investigate, a single command that searched our codebase, issue data, and other systems.
It was a meaningful improvement. We estimated Claude made each person about 20% more efficient. Bringing those individual workflows to the whole team, though, created new problems:
Long story short, Claude was useful for prototyping workflows, but it wasn't production-ready. We needed something purpose-built for support teams that could make these workflows shared, always on, and part of how the team handled every ticket.
So we built Agentic Support
We brought what was working in Claude into Pylon, where it could run in the background instead of needing someone to manually kick it off. A Skill that once lived in one engineer’s Claude setup became something people and agents across the team could use and iterate on.
It changed how the team worked
Before
After
A ticket sat untouched until someone opened it
A ticket is pre-investigated the moment it arrives by a Background Agent
We moved between Pylon and Claude to continue an investigation
We continue the investigation right in the ticket with Assist Agent
Skills lived in the Claude setup of whoever built them
Skills live in Pylon, where the whole team can use, manage, improve, and measure them
Complex issues could only be solved by certain people on our support team
Everyone on our support team (and even other teams) can debug complex issues with reusable Skills
Other departments would ask the support team for help in our internal #support-helpdesk Slack channel
Anyone from Sales, Customer Success, Marketing, and more at Pylon can use Slack Agent to get answers to product or customer questions and take action without leaving Slack
What happens when a ticket comes in
It arrives pre-investigated, then we take it from there.
Let’s say a customer emails asking when a team with a specific ID was deleted.

Before, we’d log into AWS, figure out the right log group, write a SQL query to find the logs, confirm what happened, and write the reply.
Now, by the time we open the ticket, a Background Agent has already found the ID, run the search, and pulled the relevant log lines and timestamps.

It suggests next steps and drafts a response.

If that’s enough, we confirm it and send the reply. What used to be a 30-minute investigation now takes about two minutes to review and approve.
If it isn’t, we direct Assist Agent to dig deeper before we respond.
Say the deletion looks unusual and we want to know whether it has happened before. We ask it to investigate:
“Double-check whether this was a one-off. Look for similar team-deletion issues in the codebase and past tickets, and tell me how they were resolved.”
The agent checks the relevant code paths and past tickets for similar team-deletion issues and how those cases were handled, all without us leaving the ticket or opening a new tab.
We can ask follow-up questions, check another source, or take the investigation in a different direction. If it finds a bug, we can ask it to file a complete bug report for an engineer or coding agent in seconds.
While it works, we can move to other tickets and return when it has an answer.

The investigation above works because the agent doesn’t start from a blank prompt. Pylon turns our support history, account activity, product data, and internal work into Support, Account, and Product Intelligence.
For each ticket, the agent uses that intelligence to assemble the context that matters, then goes back to the underlying sources when it needs more.

By the time a support engineer opens a ticket, the agent already has:
When the context layer isn’t enough to resolve an issue, the agent uses it as a starting point for a deeper investigation across logs, account data, Linear, Notion, Slack, and the codebase.
Over time, the system can learn from each investigation. Every time someone uses Pylon agents to solve an issue, it captures the path it took, including where it looked, what it found, and even the dead ends. It’s as if the agent wrote down its approach for the next agent. That history helps future investigations start with a better understanding of how similar issues were resolved and can surface opportunities to improve the support process, such as updating a knowledge-base article or turning a repeatable workflow into a Skill.
So far, that context has lived in Pylon, where support could use it directly. But the rest of the company works in Slack, so we brought it there too.
Now, more than a third of the company uses Slack Agent every week, including Sales, Customer Success, Solutions, Product, Marketing, and leadership.
Someone might ask about a specific account or an entire book of business and get the full history back, instead of piecing it together from different tools or tracking down whoever has the answer.

They might also use Slack Agent to summarize a live customer issue or surface a workaround, with the relevant account and engineering context pulled together in one place.

Or they can put it to work. When a customer leaves feedback on a help article, Slack Agent surfaces it, and someone can jump in with the fix right from Slack.

What started as a better way to handle tickets changed how the whole company worked.
Support
The team moves through harder issues faster, even as ticket volume grew. Median first-response time fell 72%, from 19.4 to 5.3 minutes, and 62% of tickets involve substantive agent work, whether an accepted draft or an active back-and-forth during investigation.
Investigation processes that once lived in individual setups are now reusable as Skills the whole team builds on, meaning less time tracking down context and more time on decisions that need a person.
Engineering
When an issue needs engineering, the support team passes along the full picture, including ticket history, account context, relevant logs, and clear steps to reproduce it. Engineering can pick up where support left off instead of starting from scratch, so engineers spend more time fixing issues and less time reconstructing them.
The rest of Pylon
Across Pylon, team members no longer hunt down customer or product information, or track down someone on another team who might have it. Slack Agent pulls together what they need and lets them act on it in Slack.
More than a third of Pylon uses Slack Agent weekly, including Sales, Customer Success, Solutions, and leadership, getting questions answered on their own instead of tracking down whoever might know.
Metric
Before
After
Change
Median first response
19.4 min
5.3 min
72% shorter
SLA attainment rate
63.1%
73.3%
+10.2 pts
Responses within 1 business hour
50.5%
62.9%
+12.4 pts
The typical customer heard back more than 14 minutes sooner. Customers who waited the longest saw response times improve by more than 85 minutes. The share of tickets receiving a first response within one business hour rose from 50.5% to 62.9%.
During the measured period, ticket volume grew 3% while support headcount decreased 10%. Even so, response times improved across every measure we tracked.
Before Agentic Support, we planned to grow the support team to 18 people by year-end. After adopting it, we revised that plan to 11 while keeping the same growth forecast.
This changed our hiring plan, not the size of the existing team.
“Everyone’s technical floor has risen. Issues that once required two or three escalation steps can now be handled by nearly everyone on the team.”
— Jon Clark, Support Engineering Manager

(text under pic) - The Pylon support team
You can build pieces of it. The hard part was turning individual Claude workflows into something the whole support team could count on. That meant shared Skills, controls for the team, agents that run in the background, and a system that does not depend on everyone maintaining their own setup.
We review the work before anything reaches a customer or changes something important. Then we decide whether to use the result, edit it, or point the investigation in a different direction.
It can access the systems we connect, including ticket history (Pylon), account context (Salesforce, call recordings, emails with customers), engineering work (Linear), product specs (Notion), logs (AWS), internal conversations (Slack), codebase (Cursor), Knowledge Base (Pylon), and our internal product data (internal MCP). It can investigate an issue, recommend next steps, and take actions we approve. We stay in control of what happens next.
Within about a month, everyone on the support team was using Agentic Support every day. We measured response-time results by comparing the four weeks before rollout with the four weeks after.
No. The 39% figure comes from changing our year-end plan from 18 support team members to 11 while supporting the same projected growth. It does not mean we reduced the current team.
Results compare the four weeks before rollout, May 4–31, 2026, with the four weeks after rollout, June 8–July 5, 2026. Ticket volume grew 3% across the comparison period.
Move from doing the work to directing it.