Our NOC gets a steady stream of tickets every day, and a good chunk of them are routine: the same site issue reported twice, a ticket that just needs the right category to be organized clearly, a slow-connection report that needs proper network diagnostics. None of that requires real judgment. All of it eats time.
I'd already been using OpenCode to just mess around and test things for free while on shift, so I decided to wire up an autonomous agent to reduce some of the repetitive workload of managing our tickets.
What it actually does
Each separate task of the workflow basically lives in a skill file, loaded by the OpenCode agent in correct order with an AGENTS.md to orchestrate the entire workflow, pretty standard.
A webhook receives a new ticket, waits sixty seconds to see if more come in (batching saves a lot of redundant work), then hands the batch to OpenCode running in non-interactive mode. From there it checks for duplicates against other open tickets for the same site and issue, categorizes the ticket by type, and for anything flagged as a slow connection, kicks off a deeper network diagnostic and posts the result straight to the ticket. It pings the team in chat only for tickets that actually need a human, which is still most of them now as its main job here to start is simply take on 80% of the initial ticket analysis and investigation workload.
What actually took the day
The AI part was the easy part, weirdly. What ate the hours was the plumbing underneath it. Duplicate detection needed exact-match site names, and site naming in our system turned out messier than expected, learned that one the hard way. The network diagnostic tool uses different naming conventions than the ticket system for the same physical sites, so there's a whole lookup step just to translate between the two. The first version had a five-minute timeout on the diagnostic step; turns out some sites take seven-plus minutes to fully analyze especially if there is an issue causing network slowdowns on the way. I bumped the default timeout to ten and made configurable via the .env file so I'm not guessing next time. And there's a fallback notification for when the agent itself crashes or runs out of budget, because a ticket disappearing silently is worse than the ticket never being automated at all.
Where it landed
It's running as a systemd service now, processing real tickets. Duplicates get caught and routed without anyone touching them. The diagnostic runs automatically on the tickets that need it. The team only sees what actually needs attention, and the total ticket count is already trending down since it went live.
The part that surprised me most wasn't that an AI agent could do this. It's that the whole thing, idea to running in production, fit inside one shift alongside the other daily workloads I always have going. A year ago this would've been a sprint's worth of work for a team, and half of it would've gone to exactly the plumbing described above, not the interesting part.
If you're running a similar agent, curious what your batching and timeout setup looks like. Feels like the kind of dead simple thing everyone's probably independently reinventing right now.
Top comments (0)