AI agents in IT operations: where they work today

The word "agent" is used for almost anything today: from a chatbot with access to a search engine to a system that makes production changes with no human involvement. For an IT operations team that ambiguity is a problem, because the useful question is not whether agents are the future, but which specific tasks they already help with, under which controls and with which data. This article offers a practical answer.

What an agent is, and how it differs from a script or a chatbot

An AI agent combines four elements:

• Model: a language model that interprets the situation, reasons about it and decides the next step.
• Tools: functions or APIs the agent can call, such as querying metrics, reading a ticket, searching the CMDB or opening a change request.
• Memory: the context it keeps during the task (what it already checked, what it ruled out) and sometimes persistent information across tasks, such as runbooks or past decisions.
• Goal: a bounded objective ("classify this alert and suggest who should own it"), not a step by step instruction.

The difference from a script is that a script follows a fixed path: if condition A holds, run B. It is predictable, cheap and auditable, which is why it remains the right choice for any stable, well defined process. An agent chooses its path at run time. That lets it handle variations nobody programmed, but it also makes it less predictable.

The difference from a chatbot is action. A chatbot answers questions with what it knows or what you paste into the conversation. An agent queries real systems, chains several queries and produces a result someone can act on. That ability to act is exactly what forces you to think about permissions, traceability and limits.

A useful rule: if you can draw the process as a flowchart with no ambiguous branches, automate it with a script or a tool such as Ansible. Save agents for tasks where the work consists of reading scattered signals, interpreting them and summarizing.

Where they add value today

The tasks where an agent performs best share a pattern: a lot of data to read, a result a person can review quickly, and a low or containable cost of error. In IT operations, that describes several areas.

Monitoring with context

An agent can review an anomaly, pull related metrics, logs and traces, cross them with recent changes and hand the command center a readable summary. It does not replace the observability platform; it works on top of its data. It is a topic that deserves its own analysis.

Incident triage

Enriching an alert with telemetry and CMDB data, proposing a classification, a probable cause and a resolver group. It is repetitive work, it takes time from experienced analysts, and the result is easy to validate. It is one of the use cases that most deserves detailed design.

Rightsizing

Reviewing actual compute, memory and storage use against what is allocated, and proposing adjustments with their rationale. The agent analyzes and recommends; the change goes through the normal change enablement process.

Architecture and documentation

Reading configurations, repositories and inventories to generate or update diagrams, service sheets and runbooks. Documentation is one of the most common debts in operations, and an agent can detect when what is documented no longer matches what is deployed. Human review is still required before publishing.

Other supporting tasks

Drafting a post-incident report from the ticket timeline, reviewing a change request for missing fields or undeclared dependencies, or answering team questions from the internal knowledge base while citing the source.

Where they are still risky

Language models can produce plausible but wrong answers, and they do so with the same confident tone they use when they are right. That defines where autonomy is not advisable:

• Production changes without approval. Restarting services, changing firewall rules or scaling infrastructure autonomously requires a level of trust that few organizations can back with evidence today.
• Irreversible security actions. Locking accounts, isolating machines or deleting data can have a larger impact than the original incident if the cause was misidentified.
• New or rare incidents. When there is no history and no runbook, the agent tends to force the situation into familiar patterns.
• Decisions with regulatory or customer impact. In banking, insurance and healthcare, accountability for those decisions must stay with identifiable people.
• Sensitive data without governance. If the agent reads logs containing personal or financial data and sends them to an external model, the problem stops being technical and becomes a compliance issue.

Agents also have their own attack surface. Prompt injection (malicious text inside a ticket or log that the agent interprets as an instruction) and excessive permissions are two of the risks the OWASP Top 10 for LLM Applications describes explicitly.

Task, value and risk

The following table summarizes a reasonable starting point. Risk refers to use in recommendation mode, with a person approving the action.

Task	Expected value	Main risk	Recommended initial mode
Anomaly summaries for the command center	Less time spent reading dashboards and logs	Incomplete or biased summary	Read only
Incident triage and routing	Faster, more consistent assignment	Invented probable cause, wrong assignment	Read only, suggestion to the analyst
Resource rightsizing	Less spend on idle capacity	Undersizing a service with seasonal peaks	Recommendation with approval
Documentation and diagrams	Documentation in line with what is deployed	Errors published as fact	Draft with review
Change request review	Fewer changes rejected for missing information	False sense of a complete review	Comments to the requester
Automatic remediation in production	Shorter recovery time for known failures	Wrong action at scale	Only after sustained evidence and with a narrow runbook

Moving from "recommends" to "executes" should be an explicit decision per task type, not a side effect of the tool allowing it. That decision is best made with an explicit scale of autonomy levels, agreed with the risk and compliance areas.

Prerequisites

An agent does not make up for a disorganized operation; it amplifies it. Before putting one to work, check these points:

1. Reliable observability data. Metrics, logs and traces with consistent names, correlation identifiers and enough retention. If your teams cannot reconstruct an incident from the available data, neither can the agent. OpenTelemetry is a good starting point to standardize instrumentation.
2. A reasonably current inventory and CMDB. The agent needs to know which service depends on which component and who owns it. An outdated CMDB produces wrong routing with high confidence.
3. Written runbooks. They are the reference the agent uses to propose actions and the reference you use to evaluate its proposals. If the knowledge lives only in two people's heads, start there.
4. APIs and tools exposed in a controlled way. Every tool the agent can call should have a clear purpose, parameter validation and usage logging.
5. Least privilege permissions. Dedicated service accounts, read only at first and separate from human accounts. That way every agent action is attributable and revocable.
6. Traceability. Record which data the agent queried, what it concluded, what it recommended and what the person decided. Without that record you can neither audit nor improve.
7. Evaluation criteria. Define upfront how you will measure whether the agent is right, for example by comparing its classifications with the analysts' during a trial period.

How to start without betting the operation

A prudent path is to pick a single task with high volume and low cost of error, typically alert summaries or initial triage. Deploy the agent in shadow mode: it works in parallel with the team, and its results are logged but not used. Compare for a few weeks. If accuracy is acceptable and the errors are understandable, move to suggestion mode, where the analyst sees the proposal and decides. Only after that, and for narrow cases, consider automatic actions.

To prioritize which tasks to tackle first, use the same criterion we apply to any automation: value against complexity. A high value, low complexity task (few systems, data available, low change risk) is a quick win. A high value, high complexity one is best split into smaller deliveries.

Finally, remember that the goal is not to take people out of the process. It is to take reading and classification work off their plate so they can apply their judgment where it is needed: new incidents, risk decisions and service improvement.