Case study

How Astreya Scaled Network Capacity 7x With AI and Automation

Over the two years ending May 2026, the network capacity sustained by each Astreya engineer supporting this client grew 5.7x, and total capacity under the team's management grew more than 7x, against headcount growth of just 24%.

At the same time, monthly ticket volume climbed 164% — from roughly 7,500 to nearly 20,000 — and tickets handled per engineer more than doubled. Astreya's response, live in production as of July 2026:

  • An AI recommendation engine for root cause coding, running at 95% accuracy against client-adjudicated ground truth (versus 50% for manual coding)
  • An AI agent for Tier 1 ticket resolution, expected to close ~95% of routine tickets without human intervention

Because growth in demand doesn't need to mean growth in support cost.

The challenge: Demand was growing faster than the team

Astreya provides operational support across the client's global optical and IP network infrastructure. On a network this large, many faults trigger an alert, then clear on their own before an engineer can investigate. But a cleared alert still requires work. An engineer has to verify that the link is healthy, document what happened, assign the correct root cause, and close the ticket. These necessary steps take time, and too much time leads to backlogs.

But just closing tickets quickly isn’t enough. Teams also need to restore as much capacity to service as possible.

Astreya tracks restored network capacity per engineer: the amount of network capacity, measured in terabits per second (Tbps), that each engineer returns to service through incident resolution. Capacity data is recorded directly on tickets, covering more than 90% of capacity-affecting incidents.

Typically, the relationship between demand and headcount is almost 1:1. As demand increases, more engineers are brought on to support the added capacity. But between May 2024 and May 2026, demand spiked and headcount couldn’t keep pace. Monthly ticket volume nearly tripled, from approximately 7,500 to nearly 20,000, a 164% increase. Restored capacity per engineer grew 5.7x and total capacity supported by the team grew more than 7x, against headcount growth of just 24%.

Where the network support model started to break

The surge exposed two problems.

  1. Engineers were spending capacity on confirmation work

As ticket volume increased, engineers had less time to perform the repetitive checks required to confirm that self-resolving network events were truly clear, creating a backlog. As the backlog grew, high-value incidents became harder to distinguish from thousands of routine, transient events.

  1. Root cause data could not be trusted

Every resolved ticket also requires a Root Cause Code. Over time, the client's taxonomy had become difficult to use at scale, with duplicate codes, unused codes, and too many choices for engineers working through high ticket volumes. When measured against client-adjudicated ground truth, manual root cause coding was only 50% accurate. That meant the problem wasn't simply how quickly tickets could be closed but also how to improve the underlying operational data.

The AI strategy: Automate the work that doesn't require human judgment

Instead of asking how many additional people were needed, Astreya asked which network tickets actually require an engineer. Many didn't. Tickets associated with self-resolving conditions still required verification and closure, but they didn't necessarily require human judgment. That distinction became the foundation of Astreya's AI automation strategy.

Using AI agents to automate Tier 1 network support

Astreya developed an AI agent to help automate network ticket resolution. The agent continuously checks link status and can close tickets associated with self-resolving issues without human intervention.

Automation is governed by predefined conditions rather than a simple elapsed-time rule. A ticket becomes eligible for automated closure only after it passes every required check. If a check fails — or if the AI cannot confidently complete the workflow — the ticket is routed to an engineer.

Astreya also determines automation scope empirically rather than assuming that an entire ticket category is safe to automate. The system analyzes ticket classes, attempts automation against defined criteria, and uses those results to determine where automation is appropriate. Straightforward workflows, such as status verification and certain configuration changes, are strong candidates. Tickets requiring expert diagnosis or complex fault isolation remain with engineers.

The AI agent can also execute changes from a pre-approved set. Authorization is established at the workflow level rather than requiring approval for every individual transaction. If a change cannot be completed successfully, the ticket returns to an engineer for review.

The goal isn't to remove engineers from network operations but to eliminate work that doesn't require an engineer in the first place.

Improving root cause accuracy with AI

Automating ticket handling solved only part of the problem. Astreya also needed to improve the quality of the operational data generated when those tickets were resolved. To do that, Astreya developed an AI recommendation engine for Root Cause Code assignment.

Against the same client-adjudicated ground truth used to evaluate human coding, the AI model achieved 95% accuracy, compared with 50% for manual coding.

As of July 2026, support engineers no longer assign Root Cause Codes manually. That improvement matters well beyond individual tickets because root cause data feeds:

  • Network capacity planning
  • Reliability and availability reporting
  • Vendor performance management
  • Failure trend analysis
  • Operational forecasting

A miscoded ticket doesn't stay isolated in a service management system. It can distort the decisions made from the data later.

How Astreya governs AI-driven ticket closure

At roughly 20,000 tickets per month, manually auditing every AI-generated decision would recreate the same scalability problem automation was designed to solve.

Instead, Astreya uses a sampling-based quality model. Approximately 5% of monthly tickets — roughly 1,000 tickets at current volumes — are selected for quality review. The objective is to identify errors and model drift without introducing another layer of manual work across the entire queue. Engineers can then spend more of their time on the work that genuinely requires expertise, like complex fault isolation, root cause investigation, and higher-value network engineering.

The first review cycle is scheduled for August 2026.

The results

Two-year view (May 2024 – May 2026)

Metrics Table
Metric May 2024 May 2026
Restored capacity per engineer, indexed 100 573 (5.7x)
Total network capacity supported, indexed 100 708 (7.1x)
Tickets handled per engineer, monthly 148 316 (2.1x)
Engineer headcount 51 63 (+24%)

Ticket volume (May 2024 – May 2026)

Ticket Volume Metrics Table
Metric May 2024 May 2026
Monthly network tickets ~7,500 ~19,900
Tickets per engineer, monthly 148 316 (2.1x)
Increase in ticket volume 164%

AI capabilities live as of July 2026

AI Accuracy Metrics Table
Metric Result Notes
Root Cause Code accuracy 95% vs. 50% for manual coding against client-adjudicated ground truth
Tier 1 tickets expected to close without human intervention ~95% First production month: July 2026; actuals pending
Quality review 5% sample of ~20,000 tickets/month First review cycle scheduled for August 2026

The business impact: A scaling model where demand outgrows the team

The most important result is what happened to the relationship between demand and engineering capacity. 

Hyperscaler Network Operations: May 2024 – May 2026
Hyperscaler Network Operations: May 2024 – May 2026

7x the network capacity. 24% more engineers. AI built for the next doubling.

Indexed: May 2024 = 100. Capacity measured in terabits per second (Tbps), recorded on 90%+ of capacity-affecting tickets. Source: client network operations data, May 2024–May 2026. Productivity gains shown were achieved by the operating model; AI capabilities entered production July 2026.

  1. Operationally: Under the previous operating model, growth of this magnitude would have required a much larger staffing increase simply to maintain the same workload per engineer.
  2. Structurally: That surge also revealed the ceiling of a people-only model — engineers consumed by confirmation work, and root cause data too unreliable to plan against. The AI capabilities now in production address both. Root cause coding is live at 95% accuracy, and the Tier 1 agent is expected to remove the routine verification-and-closure work from the queue entirely. The productivity gains already achieved were earned by the operating model; the AI is what makes the next doubling of demand absorbable without a matching increase in team size.

These changes create a different scaling model for network operations, one where demand can grow faster than the team supporting it, and where the value delivered is measured in network capacity returned to service.

Why the operating model matters as much as the AI

An AI team can automate a workflow, but without deep knowledge of the underlying operation, it can automate the wrong work, miss exceptions to the rules, or produce data that operators don't trust. Astreya built the automation with the people already operating the network and working the tickets. Their experience determined which workflows could be automated safely, what conditions needed to be checked, when a ticket should escalate, and what operational data could be trusted.

Astreya combined network operations expertise with enterprise AI to change the economics of the support model itself. The result is faster ticket closure and a network operations model in which productivity can scale faster than headcount.

Learn how Astreya's Enterprise AI services help organizations automate complex IT operations, improve service productivity, and scale without adding equivalent operational overhead.

Explore our Enterprise AI capabilities or contact an Astreya AI expert.

About the author

No items found.
AI & Automation
Networking & Data centers