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 behavior that changed a few days earlier. Another good amount are internal behaviors 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 with every change, which translates into engineering interruptions.

The problem for me was not only the time spent investigating and typing 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. 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 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 and paste the answer back.

That was already better than doing every lookup myself, but I got tired of the copying and pasting too. I had removed one repetitive step and replaced it with another. So I got started on the 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 and built an AI agent with access to our database, our codebase, our logs, etc. One 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 that I did not yet have a good 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 enough to try 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 have needed 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 out of 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 handling 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 through data and dashboards or interrupting somebody else.

Eventually, some team members started asking me about implementing an API, callbacks, and other functionality they wanted in order to integrate the agent into their own workflows.

Productization

Accidentally, I built a tool that brought autonomy to the team. They were no longer blocked waiting on someone else, and that other person was no longer interrupted. It became critical for the team very quickly, to the point that if I added two 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 in my life. Most of them failed, and for the first time, something that I built just as a tool for myself seemed worth becoming a product on its own. All of it started with a very small problem: I did not want to assemble SQL queries to investigate support tickets.