An AI operator for the MikroTik NOC
A customer says the internet is slow. It is the middle of the night, one engineer is on call, and the fleet holds hundreds of MikroTik devices. The first stretch of that ticket is rarely about the fix. It is about working out where to look.
What ARIA does with the ticket
You describe the problem in plain words. ARIA picks the checks, runs them on the live device and explains what came back: reachability and path from the device itself, a throughput test, and the state of interfaces, routes, firewall rules, address leases and logs. A full health baseline of ping, path and speed arrives as one assessment.
Reads need no approval, so the engineer is not clicking through prompts to find out what is wrong.
Knowledge that does not sit with one person
RouterOS expertise tends to live with a few senior operators. ARIA carries a built-in knowledge base of RouterOS practice, so a how-do-I question gets an answer without touching a device. A configuration nobody on the team wrote can be pasted in and explained line by line, with the risks flagged. The explanation is in operational language, so the next shift starts from evidence and not from a blank terminal.
From diagnosis to a fix, with a person in the loop
When the cause is a configuration, ARIA proposes the change, as a vetted template where one fits: a typed, reviewed change with the values filled in. Free-form writes are possible too, inside the permitted namespaces; a template-only mode exists but is optional and off by default. Either way, nothing has run at that point. The engineer sees the exact change, the device and the customer, and approves it or does not.
Every write waits for that approval. The approval is single use and expires if nobody acts on it. It is bound to the command, the user, the session and the device, so a different value means a new approval. On yes, an audit record is written before the device is touched.
The model can ask. Only code decides.
A language model should not be the thing that stands between a request and a router. In ARIA, code does that job. Every command is classified as a read or a write by a classifier validated on more than 1,600 real commands. Free-form writes stay inside 16 permitted namespaces, and 10 are never writable. When a template is used, the change must match the template it came from, or it never reaches approval. A session is capped at 15 writes.
Text that comes from a device is treated as untrusted data and wrapped in a marked envelope with a per-turn random token. That does not make a model immune to it. What holds is the write gate: a write cannot run unless a person approves the real command on screen, whatever the model says.
Who it is for
Junior engineers get to an answer faster. Senior engineers get the repetitive part of their work shortened: the same checks, the same correlation, the same note at the end of the ticket. ARIA does not replace the NOC, and the judgment about what to change stays with the person who approves it. It works with MikroTik today.
See it on a real incident. See it live