Application management and IT operations teams spend most of their time on work that never shows up in a product roadmap: triaging tickets, deciding which queue something belongs in, restarting the same processes, trimming the same logs, and scrambling to get the right people into a war room once something breaks. At the client engagements I was working from, that first-line triage was still done by hand — someone reads a ticket, decides if it’s AMS or infrastructure, and routes it, over and over, across thousands of tickets a month.

That’s not a small-team problem. Any organization running a service desk at scale has the same shape of cost: a Level-1 team absorbing repetitive classification and routing work, an incident process where the first 30-60 minutes before a war room even convenes are often pure coordination overhead, and monitoring alerts that sit in a gap between “pure infrastructure” and “pure application” knowledge, so nobody owns them cleanly. I wrote this platform design to put a number on that gap and propose a concrete architecture to close it, grounded in real data rather than a slide of AI aspirations.

I authored this as a full design specification (the AI Lab Italia team’s Intelligent Operations Platform, v1.0) covering functional use cases, architecture, the AI models behind each decision, and the security posture — built and validated against a real dataset of over 8,000 AMS tickets, not synthetic examples.

What the platform actually does: it pulls tickets off the main service-desk queue and an Intelligent Operations Agent decides, per ticket, whether to route it to the right team queue, whether it’s a candidate for fully automated resolution, or whether it needs to be marked fast-track. Fast-tracked tickets — the ones that would otherwise burn 30-60 minutes just getting the right people on a call — get handled by a separate Automation Agent that pulls diagnostic data from the affected servers, sends alerts over email, SMS and WhatsApp, opens the war room meeting in Outlook/Teams automatically, and drafts the incident report and meeting minutes. For tickets that are just routine service requests (create a user, remove a file, restart a process, apply a scheduled maintenance notice), the same agent extracts the required action and data from the ticket text, gets a human to confirm it, and fires the automation without anyone touching a terminal. A management console lets an operator see every routing and automation decision the AI made, adjust the underlying rules and thresholds, and review anything that failed.

Under the hood, the routing decision isn’t one model — it’s an ensemble. I tested classification by requester username (73% accuracy), classification by the ticket’s structured “request area” metadata (over 97% accuracy), and GPT-3.5 reading the free-text ticket body (under 90% accuracy on its own). The design combines these, plus NER, SVM, and text-classification models, into one ensemble decision with a reinforcement-learning feedback loop that improves routing over time. For the harder problem — deciding whether a ticket can be auto-resolved and extracting the parameters needed to do it — I used a two-stage LLM pipeline: one prompt turns the raw ticket into a clean summary, a second prompt extracts the action, target system, and required data as structured fields, all after the ticket data is anonymized (names, emails, tax codes, IPs, client names replaced with reversible tokens) so nothing sensitive reaches a non-self-hosted model.

The biggest lesson was that the flashiest model isn’t the best one for the actual decision. Classifying tickets by their existing structured metadata (the request-area/triplet field) beat both a username-based model and a raw LLM reading free text, by a wide margin — 97% versus under 90%. The generative model only became competitive once it had that same structured signal as a supporting input, which pushed me toward an ensemble instead of leaning on GenAI as a universal hammer.

The other lesson was about where the time actually gets saved. The single largest measurable win in this design isn’t a smarter classifier — it’s the fast-tracking mechanism, which collapses the 30-60 minutes normally spent on human coordination (verifying the problem, notifying the right people, opening a war room) into something the automation agent does the moment a ticket is flagged. That’s a workflow and orchestration win as much as an AI win, and it was easy to undervalue next to the model-accuracy numbers.

The spec was deliberately built ticketing-tool-agnostic (CA, Clarity, ServiceNow, or custom) and infrastructure-agnostic (on-prem, virtualized, cloud), because the intent from day one was to generalize past a single client’s AMS engagement. The natural next step is hardening the PoC into a production system — extending the dashboard, wiring it to a market-leading ticketing tool, and growing the automation library case by case.

The more interesting direction is applying the same pattern outside IT operations. Any large organization has a queue of inbound requests that get triaged by people reading text and deciding where it goes — customer support, internal HR or procurement requests, compliance intake, SRE on-call rotations. The architecture here — an agent that routes and prioritizes, a separate agent that only executes pre-approved actions, and a monitoring layer that catches the cases stuck between two teams’ ownership — doesn’t care whether the queue is full of IT tickets or support cases. The security chapter alone, with its anonymization rules mapped explicitly to GDPR and the EU AI Act, is the part I’d point any enterprise team toward first, since that’s usually the blocker that kills these projects before the routing logic ever gets discussed.