Scaling Enterprise IT with Agentic AI - Engineering an Autonomous Service Desk

Every developer in the room at DevSparks Bengaluru 2026 knows what a ticket is. Most have raised one, worked on one, or watched one sit idle for longer than it should. Service management, which provides support to employees, operates quietly in an enterprise, often unnoticed until needed. An employee cannot log in, a new hire needs a laptop, and an expense that does not go through. Behind each of these moments is a team, a queue, and an SLA.

The numbers behind that queue are not flattering. Only four out of ten tickets move through the resolution chain without friction. The rest get escalated, reassigned, or simply wait. As many as 60% of help desk tickets are repetitive, and each one results in more than four hours of idle time on average. The people working those queues pay a price too: one in three service desk engineers report burnout and say they are likely to quit.

This was the context Nitish Jha, Head of Engineering at Atlassian, set for his closing session at the summit, before introducing Rovo Service, Atlassian's answer to the problem.

Not a chatbot

Nitish was deliberate about the distinction from the outset. "When I say AI agent, I'm not referring to a chatbot. I'm not saying it's a smart search bar," he said. Rovo Service is a fully autonomous AI agent embedded directly inside Jira Service Management, designed to pick up a ticket, build an execution plan, carry it through, and close it, without requiring a separate tool or context switch for the help desk team.

The architecture behind it is layered and intentional. When a ticket arrives, a supervisor agent takes over as the brains of the operation, breaking down the request and identifying which skills in the pipeline can resolve it. The first of those skills is a query understanding layer, built to get at what the employee actually needs, not just what they typed. From there, the agent pulls in two types of organizational knowledge: structured knowledge in the form of policy documents and SOPs, which Atlassian calls runbooks, and unstructured knowledge drawn from similar historical tickets, the kind of institutional memory that usually lives only in people's heads.

A planner then synthesizes this into an execution plan, grounded by Atlassian's Teamwork Graph, a universal map of enterprise entities and their relationships across people, teams, code, documentation, and services. "That's what helps the agent reason with context, not just with instructions," Nitish said.

The quality gate and the trust layer

Before any execution happens, the plan clears a hard gate. Nitish described it as "the agentic equivalent of the code review, not a suggestion". It checks whether the plan adheres to organizational policy, whether it is using the right tools, and whether it stays within the scope of the problem reported. Only plans that clear this gate move forward.

What follows is an execution mode predictor, the layer Nitish called his favorite part of the architecture. A deterministic classifier reviews the plan against historical performance and accuracy metrics. Separately, an independent LLM classifier critiques the same plan. Only when both layers independently return high confidence does the system proceed to autonomous execution. When they disagree, the ticket escalates to a human, who can review, modify, and approve the plan before it flows into the same execution path. Critically, every human edit feeds back into the agent's memory. "This is what makes it a learning system and not just an automation system," Nitish said.

At the execution layer, slim, permission-bound task agents interact with enterprise systems such as Okta, Workday, and Jira. "We don't hand API keys to the LLM," Nitish noted. Each task agent has one job and operates within tightly scoped boundaries.

Scaling in an enterprise is the harder problem

Building the product, Nitish was clear, is only half the work. Every CIO the team has spoken to raises the same set of concerns: accountability when the agent makes a mistake, governance and explainability in regulated industries, data security with roles that are thinly scoped and auditable rather than broad and permanent, and integration across enterprise tool stacks that are rarely uniform or well-documented.

The concern Nitish spent the most time on was workforce displacement. "Anytime we try to deploy an AI agent to the team and not with the team, adoption stalls," he said. The framing matters: Rovo Service is positioned as a force multiplier, not a replacement, and that distinction determines whether an enterprise actually gets value from it.

Atlassian's deployment playbook reflects this by moving customers through four stages of AI maturity: observe, where the agent only summarizes and drafts; assist, where it suggests plans but humans decide; supervised, where the agent leads, and humans oversee; and finally, delegation, where the agent operates autonomously and pulls in humans only when confidence is low. "You can't assume that you walk into an enterprise and turn on autonomy," Nitish said.

The goal at the end of that maturity curve is what Atlassian calls invisible service. "We believe that the best ticket is the one that resolves itself," Nitish said. Employees, he suggested, will not remember that an AI agent helped them. What they will remember is that things finally started working.