How I Automated L2 Support

The problem

I am an engineer at a startup, and every other week I am on call for support issues. We have a customer-facing support team, but when a question needs someone to check internal systems, understand recent product changes, or dig into account state, it usually lands on engineering.

As new features are shipped and the product gets more complex, more tickets and questions are escalated. A good amount of those are just people trying to understand a behavior that had changed a few days earlier. Another good amount of those are internal behaviours that are not trivial to understand. And another portion (smaller than I initially expected) are real bugs. Having several teams shipping constantly has this consequence, it is hard, even for our own support team, to keep up to date with every change, which translates into engineering interruptions.

The problem for me was not only the time spent doing investigations and typing the answers. It was also the way the work arrived. I would be in the middle of something, then a Slack message would come in, then another, then another, etc. Most of them required the same first steps from my side: find the user email, check the database, inspect recent activity, compare what they expected vs what actually happened, check the code logic and reply. That constant interruption made it hard to focus on the work I was actually supposed to be doing.

To me, the manual process was almost always the same. I would connect to the database from my terminal, type the query to find the user ID from the email address, and then start querying other database tables. One of the most annoying parts to me was crafting the SQL queries, I needed to check the model relationships and write complex queries to fetch the information I needed. It was not hard work, it was just what I like to call monkey work. It was tedious, and it kept breaking my focus.

A solution for myself

Eventually, I wrote a small script that connected to the production database in read-only mode, and I wired it into Claude Code. I used Claude Code because it could query the database and also read the code when the answer was not obvious from data alone. A lot of support questions were like that. The database helped, but sometimes the real answer was in the code path, a feature flag, or a recent change.

That first setup worked better than I expected. For a few days, I became the middle layer. Support would ask me something in Slack, I would pass it to my script, it would investigate, and I would copy/paste the answer back.

That was already better than doing every lookup myself, but I got tired of the copy/pasting too. I had removed one repetitive step and replaced it with another. So I got hands on a next version.

The goal was simple: let people ask the system directly in the place where the questions were already happening. I.e. in Slack. I created a Slack application, built an AI agent with access to our database, our codebase, our logs, etc. An annoying part was code search. The GitHub search API was not good enough for the kind of digging I needed, so I created a service that kept a synced copy of the repo and exposed search to the agent. I was just trying to give it the same basic ways of investigating that I used myself.

I was ready to present the new tool to the team, and 10 minutes earlier something amazing happened. We had a critical production issue where the database had become really slow. Several people on the team had already spent about 25 minutes looking into it and still had not found the source. Given I didn't have yet a god demo, I decided to ask the agent to investigate the issue. About two minutes later, it replied with the root cause: something was trying to ingest five million phone number records.

That was the first moment when it felt bigger than a personal productivity hack. It was not just saving me the tedious work, it literally saved us from a critical issue we couldn't find ourselves.

The team went crazy using it

During the next few days, I kept using it in our public support Slack channels so people could see how it worked and get curious to test it themselves. Within the first two weeks, it helped with more than 300 support tickets. All of them were the kind of tickets that previously would need escalation: what happened with this account, what changed for this user, is this expected behavior, or does this look like a bug.

What surprised me most was who started using it. At first I thought this was mainly a tool for the support team, because I had built it from the pain of support escalations. But usage kept growing in a way I did not expect. Our support team was only five people, and the volume was already much higher than that alone could explain. It was ingesting around 56 requests per day.

Then I started noticing who was asking questions. It was not just support. Engineers were using it. PMs were using it. Founders were using it too. People across the company were using it for questions that normally meant either spending 20 minutes digging around data and dashboards, or interrupting somebody else.

And eventually, some team members started to ask me about implementing an API, callbacks, and other functionalities they wanted to integrate the agent on their own workflows.

Productization

Accidentally, I built a tool that brought autonomy to the team. They were no longer blocked asking to someone else, and that other person was no longer interrupted. It became something critical for the team very quick, to the point that if I added 2 minutes of downtime to make an update they would complain. At that point it was clear this was not only my problem and I felt the need to build a product.

I had to rebuild it properly from scratch and turn it into Lumen.

I have built many products during my life, most of them failed, and for the first time, something that I built just as a tool for me seemed to be worth becoming a product on it's own. All of it started with a very small problem: I didn't want to assemble SQL queries to investigate support tickets.