Fifteen years in the operator chair, compressed into ARANO

What you don't see in the screenshot

What people see when they open ARANO is the polished surface: the map, the agents, the recommendation queue, the personas. What they don’t see is the accumulated engineering underneath it.

The vendor parsers built across inconsistent data models. The SON logic refined over years of optimisation work. The detector heuristics born from real outages, real escalations, and real network failures. The edge cases that only appear at scale. The operational scars that eventually become software.

That hidden layer is where most of the work lives.

ARANO itself is about eighteen months in the making. But the system behind it is really the product of fifteen years spent inside networks, building, breaking, testing, tuning, and learning how operators actually work.

So when someone asks, “How long would it take to build something like ARANO?”, the honest answer is: it depends which fifteen years you already have.

What I carried forward

By the time I started writing ARANO, I had a large code library. Not in any organised sense; most of it lived on different machines, in private repos, Excel sheets, PowerPoint decks, and Jupyter notebooks I'd forgotten about, and of course a lot of it was in my head.

Roughly:

• PM parsers: For Ericsson and Nokia, written and rewritten across multiple operators. I knew the silent-drop failure modes for both. I knew that one Nokia release emits a typo'd MO class that would drop the entire NR mobility layer if you trusted the schema. (You don't.)
• CM parsers: Nokia RAML, Ericsson ENM XML, the VES events from O-RAN R1. The MO hierarchies are different shapes. The translation between them is the bit nobody documents
• FM: The X.733 alarm model, the vendor-specific severity mappings, the lifecycle states, the reasons the alarm count on a NOC wall is almost always wrong
• SON optimisation logic: ANR neighbour-list pruning, MLB load steering, MRO handover classification, geo-load balancing. Each of these is a paper. Each of these is also a piece of working code I had shipped before
• Issue detector heuristics: Every one started life as an incident in some operator's network at some hour I would rather not remember
• The seam knowledge: Nokia's NRCELL is not Ericsson's NRCellDU. The counter that means "RACH success" in Ericsson means something subtly different in Nokia. The handover event that the spec calls A3 is reported by one vendor as A3 and by the other as a flattened single-item list buried inside a nested XML tag

None of this is interesting on its own. It is interesting in aggregate, because it is the boundary condition every agentic system in telecom is going to run into and lose to if it does not know it exists.

What didn't change in fifteen years

The thing that surprised me most going back to operator data after a few years away was how little had moved. New generations arrived. New vendor releases came and went. But the shape of the problems, the failure modes, and the root causes mostly remain the same.

A counter is silently dropped because a parent MO got renamed. A handover fails because a neighbour relation was provisioned in one direction only. A cell shows healthy aggregate KPIs but a particular QCI is degraded on the per-flow view. A network is "optimised" for a metric that turns out to have been measured at the wrong granularity for years. Even more fundamental to the above is that most RAN network problems begin with poor site propagation planning, poor layer management strategy, and an inability to project issues geo-spatially.

These are not new problems. They have been the same problems for years.

This is the moat. It is not a moat anyone can build by reading the spec. The spec describes how it should work. The fifteen years describe where it actually fails.

What did change, in eighteen months

The thing that did move, and the reason ARANO exists at all, is the model side.

For most of those fifteen years, the bottleneck on doing anything useful with operator data was not the data. It was the cost of reasoning over the data. You could write a parser. You could write an issue detection algorithm. You could write a SON algorithm. You could run ML workflows. What you could not do, at any reasonable cost, was put a system in front of thousands of cells worth of PM, CM, FM, and trace data and have it actually think about them the way a senior engineer thinks about a single cell when they have the time to do so.

About eighteen months ago that changed. Reasoning over the accumulated artefacts became cheap and efficient. For instance, a well trained agent can read a Nokia RAML and an Ericsson CM XML side by side and tell you, with high accuracy, what is equivalent and what is not. That was a huge unlock. Everything else, the agent hierarchies, the digital twin, the persona-aware dashboards follow from that type of reasoning capability becoming affordable.

Where ARANO sits today

ARANO is built as eight components. I will describe what each one does but not exactly how each one does it, because the how is the part that took fifteen years and I am not yet ready to give it away.

• Data simulators: Synthetic operator datasets with injected faults, used to test the system end-to-end. Important because real operator data has NDAs attached
• Data parsers: Multi-vendor ingest of PM, CM, FM, trace, and CDR data. Lossless, vendor-neutral, with full provenance back to the source file
• Geolocation: Turning per-cell trace measurements into per-cell coverage grids, with advanced location modelling
• PM/CM/FM/Customer insights: Counter trends, configuration deltas, the read layer that everything above reasons over
• Issue detectors: SON-like deterministic algorithms, each scoped, each scheduled, each emitting issues into a queue that downstream agents can reason over
• Agentic layer: Domain-scoped reasoners that hold context across thousands of cells, in parallel, and produce ranked recommendations
• Digital twin: A model of the network you can write changes into, score, and review before any of them touch the real network
• Frontend: Three persona-aware surfaces (Managers, Operations, Optimisation), providing the correct level of insights and knowledge to each, all driven from the same data

That is the shape. Each component has thousands of decisions behind it that are not in this post. The decisions are the product.

"Could you do this in six months?"

Yes, if you have spent years in the operator chair. The model is the cheap part. The seam knowledge, the failure-mode catalogue, the vendor-versus-vendor translation, the muscle memory for which counter to suspect when the KPI moves the wrong way, that is the expensive part.

If you do not have those years of experience, you can still build something, but it will not be ARANO. It will be a system that demos well but explodes the first time a vendor release silently renames a parent MO.

If you are six months in with a strong AI background and a green-field telecom build, what I would tell you is one of two things. Find an experienced engineer who has seen the failure modes and pay them whatever they want. Or be that engineer for the next five years and then come back. Either path works. There is no third option.

What the agentic build didn't compress

A few things genuinely did not get any shorter:

• Vendor doc reading: Specs are still long, still ambiguous, still occasionally wrong. The model helps you read them faster; it does not let you skip them
• Test data: You need real operator data, with real failure modes in it, to know your system holds together. It can be simulated, but the simulations need grounding in reality
• Trust: Operators are not going to let an agentic system write to a live network because the demo was impressive. The trust ladder is years long and goes one rung at a time. Earning it is its own project. So the product roadmap has to evolve in line with that trust, not race ahead of it

These are the parts where the fifteen years still costs fifteen years.

Closing remarks

Agentic AI does not replace years of domain knowledge. It compounds it. Without the domain it is a fast way to be wrong with confidence. With the domain it is the first technology in twenty years that meaningfully changes what a small team can do with operator data.

That is what ARANO is.

Next in this thread: Two shifts agentic AI has made in telco (and the ones it hasn't).