Skip to content

Agentic AI#

When an alarm fires or a KPI drifts, Unryo opens an investigation. An agent takes the topology around the affected element, works out what could be producing the symptoms, and checks each possibility against live data: counters, logs, the dependency chain, a device poll if it needs one. It does not stop at grouping related alarms. It identifies which fault started the incident, and why.

Unryo reads from the assurance and monitoring systems already in place, and from the raw telemetry underneath them. It does not replace them. It works across mobile and fixed access, transport, core, cloud, and the service layer on top.

How it reasons#

An investigation is not a runbook with fixed steps. The agent holds state, proposes a cause, tests it, and either continues down that branch or drops it and tries another. A dead end sends it back to an earlier point with whatever it learned on the way. It stops when the evidence actually points somewhere.

This is where it parts ways with alarm clustering. Grouping by time window or message similarity tells you events showed up together. It does not tell you that the UPF session drops are downstream of an IGP flap two hops away. Reasoning over the live topology does.

Two things hold no matter the incident.

The topology is read at investigation time, not pulled from a CMDB whose last sync was hours ago. If a link went down ten minutes back, the agent sees the link down, not the inventory's older view of it.

The model is yours to choose and can run on your own hardware. Telemetry, topology, and prompts never have to leave the operator network, which is what makes Unryo workable when data residency is a contract term rather than a preference.

Components#

Component What it does
Topology graph The live dependency map: mobile RAN, fixed and FTTH access (GPON/XGS-PON), IP and optical transport, mobile core (5G SA/NSA and the legacy estate), data center, cloud, and the services and slices riding on top. Connectors keep it current, and everything else reasons against it.
Connectors Pull and normalize fault, performance, and config data over the interfaces that exist in the field: SNMP, gNMI, NETCONF/YANG, 3GPP SBI, GPON/XGS-PON EMS, OTN/DWDM NMS, and third-party assurance, OSS, and inventory (TMF638/639). Every signal lands on a topology entity.
Reasoning engine Runs the multi-agent investigation: generates hypotheses, chooses the next tool to call, weighs what comes back, and decides whether to dig further or conclude.
Tools What an agent can actually do. Traverse the topology, query metrics, logs, and alarms, poll a network element on demand, call a vendor or OSS API. Each call returns evidence the agent cites, and that evidence stays attached to the result.
Model runtime Commercial API or self-hosted open model. Set once for the platform, then override per agent or per tool.
Interface Ask in plain language, read back the investigation with its evidence, compare against past incidents, approve a fix.

Inside one investigation#

Something starts it: an alarm, an anomaly, an SLA breach, or an operator asking a question.

  1. Locate the affected NEs and NFs in the topology, then pull their neighbors, current state, and recent signals.
  2. List the causes that could produce these symptoms given what sits upstream and downstream.
  3. Test them, using PM counters, logs, traversal up and down the chain, on-demand polling, and an SBI or OSS query where it helps.
  4. Drop what the data rules out, sharpen what survives, and repeat until one cause holds.
  5. Separate the fault that started it from everything reacting to it, then follow it outward to the affected services, slices (S-NSSAI), subscribers, and SLAs.
  6. State what to do, with the reasoning behind it, and run the fix if it was pre-authorized.
  7. Hand back the trail: hypotheses tried, tools called, data seen.

The agents are not left to free-associate. Each carries diagnostic patterns for the technologies it covers, the fault signatures worth checking first, and a set of hard anti-patterns that stop it from settling on a cause the evidence does not support.

Where correlation fits#

Correlation still runs, and it runs first. Deduplication, topology grouping, tying symptoms together: that work is high volume and deterministic, and it belongs in a deterministic engine. The agents start from the incident correlation hands them and take it from "here is the incident" to "here is the cause, the impact, and the fix." Mechanical work stays mechanical. The model only gets involved where the answer cannot be derived with a rule.

Configuration#

  • Pick the model. Commercial API or self-hosted. A default covers the platform, and you can override it per agent and per tool, so a small local model takes the frequent or sensitive tool calls while a heavier model handles the top-level reasoning.
  • Connect the sources: fault, performance, and config feeds, inventory, ticketing.
  • Turn on topology discovery, or bring your own inventory and reconcile it into the graph.
  • Tune correlation and anomaly rules so the agents get clean triggers instead of noise.
  • Set who can use which tools, and who can authorize remediation.