Five AI Specialists Handle 987 Real Telecom Tickets, but Hardware Faults Trip Them Up

Instead of one large model reading a network outage ticket and writing a fix, the authors of a new arXiv preprint split the job across a team of five specialist AI agents. In a field test on 987 real, anonymized telecom fault tickets across seven product lines, that team averaged 4.13 out of 5 for report quality and correctly identified the fault area at the component-family level or better in 59.9% of cases. The same team loses ground by a wide margin whenever the fault is physical.

The result, from Mohamed Trabelsi's ASTRA: Agentic System for Ticket Resolution and Analysis (arXiv 2608.28790, v1 posted 28 Aug 2026, not yet peer-reviewed), is one of the first public field tests of a multi-agent setup for technical operations at this scale. It also names, in one number, where the setup stops working: hardware faults are harder than software or configuration faults with a Cohen's d of 0.80, an effect size the authors read not as a failure of the agents but as a limit of the text evidence channel they are reading.

A central OrchestratorAgent routes each ticket to three specialist information-gathering agents. TicketSimilarityAgent retrieves similar past tickets via dense retrieval, a search method that ranks documents by meaning rather than keywords, and reranks them with a language model. LogAgent filters device logs deterministically and then hands constrained slices to an LLM. DomainKnowledgeAgent pulls vendor documentation on demand through the Model Context Protocol, a standard that lets the agent call external tools and read their responses. A JudgeAgent scores the assembled draft against the original ticket, asks the orchestrator for targeted revisions, and the loop repeats.

Each claim in the final report is linked to the exact passage that supports it, with an explicit support level. That representation prevents a specific failure mode the authors call cross-attribution: a log line meant for one component getting borrowed and applied to another. Fabricated technical details appeared in under 3% of error cases.

The field-test corpus is narrow but real: 987 anonymized tickets from a single telecom operator, split across seven product lines. Two trained raters scored reports on quality, relevance, clarity, and accuracy. The team averaged 4.13 out of 5 overall, with relevance at 4.88 and clarity at 4.94. The 59.9% figure is the share of reports that localized the fault to the right component family or finer, a more demanding target than relevance alone.

The hardware gap is the finding that survives the preprint caveats. Stratified by fault type, hardware tickets scored substantially lower than software or configuration tickets, with an effect size of Cohen's d of 0.80. In the authors' read, the agents and the judge do what they were designed to do. What they cannot do is read physical evidence that does not appear in the ticket, the log, or the vendor manual: a failing power supply, a corroded connector, a marginal radio unit. When the fault lives in copper, silicon, or solder, the text evidence channel stalls and the multi-agent setup stalls with it.

Software bugs, configuration drift, and log-grounded diagnosis all live in text the agents can read, and the judge-orchestrator refinement loop catches the misattributed detail a single model tends to slip past. The team-of-five shape is also a copy-able architectural sketch: one orchestrator, three specialist readers, one judge, and an evidence-linked claim representation that other teams can adopt or adapt.

What the paper does not support is a deployment forecast. ASTRA was evaluated by its author on one operator's tickets, on one LLM stack, against a single rater protocol, before peer review. A reader who wants to know whether the same shape will hold on a different network, a different log format, or a different operator should treat the headline score as a hypothesis rather than a benchmark, and the hardware gap as a design rule rather than a footnote.