Dal traceroute al routing loop: cosa vuol dire NOC agentico

Negli ultimi due anni abbiamo visto fiorire chatbot e "copilot" che rispondono a domande sui router. Funzionano bene per i casi facili: "come abilito DHCP server su MikroTik?". Ma un Network Operations Center non lavora così: non chiede manuali, indaga. Apre tab, lancia traceroute, controlla le route, confronta lo stato attuale con quello di ieri, formula ipotesi, le verifica. Solo allora propone un cambio.

ARIA — il prodotto evoseed che chiamiamo AI NOC Engineer — è progettato esattamente così. Non è un Q&A che pesca da una documentazione. È un agente che usa tool, ragiona in iterazioni, e tiene un protocollo preciso su cosa fare in lettura e cosa fare in scrittura. Vi raccontiamo la differenza con un caso reale, di quelli che abbiamo registrato durante la fase 4 di training, su CHR veri.

Lo scenario: "non capisco perché questa connessione è lenta"

Il prompt era banale: "il dispositivo aria-cpe1 ha una rete lenta verso il provider, prova a capire perché". È esattamente la richiesta che un cliente fa a un NOC alle 02:30 di notte. La differenza fra un copilot e un agente si vede qui. Il copilot ti dice: "controlla la routing table, controlla il firewall, fai un traceroute". L'agente lo fa. E continua finché non ha una risposta.

Cosa ha fatto ARIA, passo per passo

1. Ha eseguito un traceroute verso un host esterno (1.1.1.1). Tool calling diretto, nessuna richiesta di conferma — siamo in read-only.
2. Ha letto l'output. Hop 1 → 10.0.0.1 (gateway interno). Hop 2 → timeout. Hop 3 → 10.0.0.1 ancora. "Ho visto un loop", ha annotato nella catena di pensiero.
3. Ha ipotizzato: "potrebbe esserci una dual default route. Verifico le route attive." Ha chiamato il tool `inspect_device` con argomento `/ip route print where dst-address=0.0.0.0/0`.
4. Ha letto: due default route, entrambe via 10.0.0.1, con distance diversa. Una sola dovrebbe essere attiva.
5. Ha formulato la diagnosi: route ridondante non eliminata dopo un cambio. La seconda intercetta il traffico di ritorno e lo rimanda al gateway, creando il loop.
6. Ha proposto il fix in linguaggio naturale prima del comando: "propongo di disabilitare la route con .id=*2 (distance=2). Vuoi che proceda? È un'operazione di scrittura."
7. Ha aspettato la conferma. Solo dopo "sì, procedi", ha generato il comando `/ip route disable numbers=*2` e l'ha eseguito.
8. Ha verificato il fix con un nuovo traceroute. Nessun loop. Latenza tornata in target.

Perché "agentico" non è una buzzword

La parola agente è abusata. Quasi tutti i tool LLM nel 2026 chiamano se stessi "agenti". La differenza concreta sta in tre cose: il loop, la memoria di contesto, e il protocollo di sicurezza. Tre cose che, in produzione, decidono se l'AI sostituisce davvero un tier-1 di NOC o se è un assistente da demo.

1. Il loop di iterazione

Un copilot ti dà una risposta e si ferma. Un agente esegue un'azione, ne osserva il risultato, decide la successiva, e ripete. ARIA ha un loop con un massimo di 5 iterazioni di tool calling per ciclo conversazionale. Cinque iterazioni bastano: se non risolve un problema in cinque step, lo escalation a un umano. Il loop limitato evita il classico problema del runaway agent che continua a chiamare tool senza arrivare a una conclusione.

2. Memoria di contesto in-flight

Il NOC non lavora su singole risposte: lavora su sessioni. Se mezz'ora fa hai modificato una rotta, e adesso il traffico non passa, l'agente deve collegare le due cose. ARIA usa un context cache in-memory con TTL di un'ora, max 200 contesti contemporanei, eviction LRU. Ogni conversazione mantiene lo stato dei device interrogati, dei comandi lanciati, degli output ricevuti. Senza questa memoria, ogni domanda partirebbe da zero — esattamente come quando passi un ticket fra due turni di NOC che non si parlano.

3. Protocollo di sicurezza by design

La parte più importante — e più sottovalutata. ARIA classifica ogni comando come readonly o write. La logica è dichiarativa: una funzione `is_readonly_command()` analizza la sintassi RouterOS e decide. I write richiedono `confirmed=true` dopo richiesta esplicita. Non c'è modo di aggirare il protocollo via prompt injection: la classificazione avviene nel codice, non nel modello.

Cosa abbiamo imparato addestrando ARIA su CHR veri

La RAG knowledge base di ARIA conta 45 documenti YAML strutturati in 5 domini: mikrotik (firewall, vlan, vpn, routing, servizi), optiwize-syntax (formato comandi, errori comuni), error-patterns (10 famiglie di errori RouterOS), troubleshooting (slow connection, no internet, wifi issues), response-patterns. È molta meno documentazione di quanto sembri. La differenza tra una RAG che funziona e una che non funziona non è la quantità: è quanto i documenti sono modellati intorno ai casi reali.

Esempio concreto: il documento `optiwize-syntax/write-commands.yaml` non spiega la sintassi astratta dei comandi RouterOS. Spiega gli errori esatti che capitano quando dimentichi il prefisso `=` davanti al parametro, o quando usi la virgoletta dove non serve. È un manuale per evitare gli errori reali, non un manuale di riferimento del linguaggio. Il LLM lo legge una volta, e poi non li fa più.

Tre cose che un agente non deve fare

1. Non chiedere conferma per le read. Se il NOC fa traceroute, l'AI non deve fermarsi a chiederti "posso?". Sarebbe come un junior che chiede il permesso prima di ogni `ping`. Inutile e irritante.
2. Non eseguire write senza riassunto in linguaggio naturale. "Sto per disabilitare la route 2" è diverso da "sto per eseguire `/ip route disable numbers=*2`". Il primo è leggibile dall'umano in mezzo secondo. Il secondo richiede di fermarsi a tradurre.
3. Non simulare confidence quando non ne ha. Se il database non ha la risposta, deve dire "non ho riferimenti su questo, propongo di scalare". Il NOC umano fa così. L'AI deve fare altrettanto.

Cosa significa, per chi gestisce una rete

Se gestite una rete di MikroTik — ISP, WISP, MSP — il calcolo è semplice. Quante volte alla settimana il vostro NOC apre una sessione SSH per fare un traceroute o un ping diagnostico? Quanto tempo passa fra l'arrivo dell'alert e il primo comando lanciato? Quante diagnosi medie servono prima di trovare il fix? ARIA non sostituisce il vostro NOC senior. Sostituisce le tre ore di indagine preliminare che fa il tier-1 prima di scalare al tier-2. È esattamente lì che il NOC perde tempo, e dove il MTTR si gonfia.

Nei nostri benchmark interni — basati su scenari sintetici e CHR reali — il tempo di prima diagnosi passa da una media di 47 minuti a meno di 5 minuti per i casi che ARIA copre. Non vuol dire MTTR generale −89% su tutto: vuol dire che il tier-1 non è più il collo di bottiglia. E quel collo di bottiglia, in un NOC con 80.000 device, è quello che fa la differenza fra una notte tranquilla e una notte di allarmi rimbalzati.

Dove andiamo

L'architettura corrente di ARIA è basata su comandi RouterOS generati dal LLM e validati a runtime. Stiamo migrando verso un modello template-driven: il LLM non genera più comandi raw, ma seleziona template da un catalogo (firewall, vlan, vpn, routing) e compila parametri tipizzati. Quattro livelli di validazione — schema statico, validazione runtime, pre-check sul device, post-check del risultato — anziché uno. È la stessa idea che applichiamo da anni a OptiWize per il provisioning multi-vendor: la libertà del LLM dove serve (capire cosa fare), i rails industriali dove non si scherza (eseguire l'operazione).

Volete vedere ARIA al lavoro su una vostra topologia? Lo scenario tipico dura 20 minuti: scegliamo un caso reale che state vivendo, lo riproduciamo su CHR, vi mostriamo come lo affronta. Se le ipotesi vanno, vi proponiamo un trial supervisionato sulla vostra rete.