AI Agent for IT Operations: Internal Tickets, Access, Monitoring, and Documentation

The problem

Internal IT operations never stop, but the team that handles them does. A Jitbit analysis covering roughly 1,000 companies, regularly cited in the support industry, put the average volume handled by a technician at 21 tickets per day back in 2017, with an average resolution time of 82 hours. This is dated data, presented by its own authors as a historical baseline rather than a current target, worth treating as an order of magnitude rather than an up-to-date figure.

On time spent per ticket, Endsight, a managed support provider, cites an average of 63 minutes across its own 10,923 tracked users over 12 months. That's internal data from a single company, not third-party verified: worth treating as a data point, not an industry standard.

The most solidly documented point concerns access. Research from Wing Security relayed by The Hacker News in 2024 estimates that 63% of companies have former employees who still retain access to organizational data, and 43% to code repositories on GitHub or GitLab. Every access or revocation request that lingers in an internal ticket queue is a direct candidate for exactly that kind of statistic.

This handling delay has a second consequence, less visible than the security risk: the ticket queue itself becomes unreadable. When urgent requests (blocked access that stops someone from working) mix with routine ones (a question already answered ten times in the knowledge base), the IT team spends as much time sorting as resolving. A good chunk of that queue should never reach a human at all: that's exactly the kind of triage an agent that reads existing documentation can absorb before a ticket waits its turn.

What the agent does, step by step

An autonomous AI agent dedicated to IT operations runs continuously, in its own isolated environment, and watches the ticket queue without ever sleeping.

It starts by categorizing each incoming ticket in Jira: a known question, an access request, a technical incident. For already-documented requests, it answers directly, citing the procedure found in the team's Notion base. For a request for access to a tool or repository, it opens a structured ticket with all the information needed for the decision, rather than executing it itself.

On the monitoring side, the agent watches alerts raised by Datadog and correlates them with recent commits or deployments visible in GitHub: a latency spike that closely follows a deployment isn't treated as an isolated incident. When the correlation is clear, it opens a documented GitHub issue, with context useful to the technical team. Any ticket left blocked, any critical alert, or any pending access request triggers a Slack notification to the IT team. Every action, ticket created, alert correlated, message sent, is logged in the agent's timeline, with its exact status.

A concrete example illustrates the mechanics well: an employee opens a ticket on a Friday evening to request access to a specific GitHub repository, as part of a cross-team project. The agent categorizes the request, checks that it's complete (target repository, justification, requested duration), then prepares a structured ticket ready for an IT lead to approve first thing Monday morning, rather than letting the request sit in a generic queue until someone happens to notice it.

The integrations involved

Jira stays the system of record for internal tickets. The agent searches requests there (search_issues), reviews details (get_issue), and can create a new structured issue, depending on the actions its grant covers.

GitHub helps correlate a technical alert with a code change: listing recent commits (list_commits), pull request details (get_pull_request), and creating a documented issue (create_issue) once the correlation is established.

Datadog provides the raw monitoring signal, which the agent reviews without ever replacing the monitoring tool itself. Notion hosts the procedures and runbooks the agent consults before answering a request, and Slack carries real-time notifications to the IT team.

What stays with the human

The agent prepares and alerts, it never executes an access or infrastructure change on its own initiative. Actually granting or revoking access stays a human action: the agent opens the documented request in Jira, someone on IT executes it and closes it out.

The real severity of an ambiguous alert, one that doesn't match any identifiable recent deployment, gets decided by a human before any escalation beyond a Slack notification. Deciding and applying a code or infrastructure fix stays, unsurprisingly, engineering work. And as with any Atako agent, an admin has to grant and adjust permissions on Jira, GitHub, and Datadog, action by action, with a read or read-and-write scope defined explicitly.

This boundary also applies to the agent itself: if it hits a situation outside what its business context covers, an unusual license renewal, an access request for an undocumented system, it doesn't force an approximate answer. It notifies the IT team and leaves the ticket open for human handling, rather than guessing at a procedure that doesn't exist in its knowledge base.

Measurable result

The most direct benefit is cutting the dead time between a ticket or alert arriving and its first handling. An agent running 24 hours a day can categorize a ticket opened on a Sunday evening and prepare the corresponding access request before the team arrives Monday, rather than leaving the request waiting in the queue.

The second benefit touches the problem Wing Security documented directly: by systematically opening a revocation ticket as soon as a departure is flagged, the agent shortens the delay between the triggering event and IT's action, which limits the window during which access stays needlessly active, a window that, without continuous monitoring, can stretch to weeks or even months according to the findings cited above.

Every ticket opened, every alert correlated, every message sent stays viewable in Atako's audit trail, exportable as CSV for the IT team up to 50,000 rows. This full traceability also makes internal security audits easier: tracing who requested access, when, and on what basis the request was formalized no longer requires piecing together a timeline from several different tools.

An IT agent runs on the Standard plan, 20 euros per month per slot, with 1,000 credits included each month to cover model calls. The number of tickets handled or employees interacting with the agent has no impact on this price, only the number of agents active at the same time counts. A lean IT team can therefore run a single agent across all its internal tickets, monitoring alerts, and access requests, without needing to multiply slots to cover each flow separately, which keeps costs predictable even as the agent's scope gradually widens to new tools or new internal teams over the months.