I've been running AI agents in production since 2026, and I'm tired of hearing they're going to replace sysadmins. They won't. But they will replace a lot of the busywork that makes sysadmin work feel like busywork.
Here's what I've learned actually working with them, not reading about them in a vendor's press release.
What AI Agents Do Well
The best use case for AI agents right now is stuff that bores you to death but follows patterns. I'm talking log parsing, ticket categorization, basic report generation, monitoring alert correlation. Things where the rules are fuzzy enough that scripting is painful, but the decisions aren't that hard.
I run an agent that triages our infrastructure alerts. It looks at the alert, checks the affected service against our runbooks, and routes it to the right on-call person with context already pulled. Before that, someone was manually doing that for 20 minutes every morning. Now it's done in seconds, and the on-call engineer gets a Slack message with links already opened.
Another solid use case: first drafts of repetitive content. If you're running a tech blog (like I am with this site), an agent can knock out first drafts of routine posts—product updates, routine tutorials, release notes. You still need a human to fact-check and add the actual insight, but the boilerplate gets handled.
The pattern is consistent: high volume, low stakes, clear enough input format. Agents excel at being a really fast junior employee who doesn't need supervision for the stuff that doesn't matter.
Where You Need a Leash
Now here's where it falls apart. AI agents have two big problems: they hallucinate confidently, and they have no skin in the game.
Anything with financial, legal, or security implications should never be fully automated. I've seen agents "helpfully" change firewall rules to resolve a ticket, except they opened a port that shouldn't have been open. The agent wasn't wrong based on the ticket—it's just that the ticket was wrong, and the agent didn't know the broader context.
The leash isn't about distrust. It's about accountability. When something goes wrong, you need a human who can say "I approved this" or "I missed this." An agent can't be fired. An agent can't be held liable. That means the human always owns the decision, which means the human needs to be in the loop for anything that matters.
Another place agents struggle: context that lives outside the digital world. An agent can tell you your server is running out of disk space. It cannot tell you that the reason it's running out of space is because the marketing team is doing a physical office move next week and someone's going to plug a legacy backup drive into that server to "temporarily" hold files. That context lives in conversations, in org knowledge, in institutional memory that isn't in your monitoring system.
The Maintenance Reality Nobody Talks About
Here's what the AI vendors don't tell you: agents break. Not in obvious ways, either.
I had an agent that was working fine for three months, then started producing subtly wrong outputs. The logs looked okay. The error rates were within normal range. But it had developed a pattern of cutting corners on a specific type of request—something about how the prompt was being interpreted that shifted over time as our data changed.
You need to monitor agents the same way you monitor servers. Check their outputs regularly. Set up random audits. Have a human review a sample of agent decisions every week. This is operational overhead, and if you're not accounting for it, you're going to get burned.
Also: prompts degrade. Your initial prompt worked great in January. By March, the agent's behavior has drifted because your system changed or the model updated or the edge cases accumulated. Plan to revisit your prompts every few months. This is maintenance work, and it's not optional.
The Real Cost Is Context Window
A lot of people talk about model capability like it's the bottleneck. It's not. Context is.
Agents work well when they have everything they need in the prompt or can fetch it reliably. But IT environments are messy. Your CMDB doesn't match reality. Your documentation is outdated. Your runbooks assume knowledge that isn't written down.
An agent can only work with what's available. If your operational data is a mess, the agent will make confident decisions based on messy data. Garbage in, confident garbage out.
Before you automate anything, clean up your data. I know that's not the exciting answer. It's the right answer.
What I Would Do First
If you're thinking about adding an agent to your workflow, start with something low-stakes that already has good data:
- Pick a repetitive task that wastes 10-15 minutes a day
- Make sure the inputs are structured (tickets, alerts, form submissions)
- Build the agent to handle 80% of cases and flag the rest
- Monitor the output for a month before you trust it
- Set a calendar reminder to review and update the prompt quarterly
Don't start with the critical path. Start with the annoying path. Let the agent prove itself on boring work before you give it anything that matters.
The leash isn't a constraint. It's how you get the benefit without the disaster.