Guide
GuidesAutonomous LAN fault detection, human-approved fixes
Autonomous detection, human-approved fixes
Most AI network agents pick a side. Either they auto-remediate confidently and occasionally take down production, or they raise a ticket and the operator is back to staring at dashboards at two in the morning. NetMender does both halves separately: detection runs without a human, every fix waits for one.
~3 min read
The autonomy split that actually ships
Full autonomy on the fix path is where network agents fail in public. A confident-but-wrong diagnosis arrives pre-approved, the playbook runs, and a config push lands at the wrong time on the wrong device. Full manual is the other failure mode: detection is the bottleneck, faults sit unfound until users complain. The fix is to split the two halves on purpose. Detection and root-cause analysis are pure read paths, so they run unattended. Execution changes state, so it waits for a human. The headline writes itself once the loop is right: find every fault, fix it in one tap.
Why a confidence gate matters
A numeric confidence score on each RCA is not a cosmetic detail, it is a structural guardrail. Above the threshold, the fault arrives with a fix pre-formed: a specific playbook the operator can read and approve. Below the threshold, the fault goes to triage with no fix attached, plus concrete manual steps. Operators never see a confident-but-wrong proposal because the system refused to write one in the first place. The same gate runs whether the RCA came from Claude or the built-in heuristic that takes over when no model key is configured.
Detection that keeps working
Telemetry flows in from Meraki and UniFi, plus an on-LAN host probe that watches the network from a real device on it. The probe is what keeps detection alive when the cloud controller is unreachable or the last-mile path is the thing breaking. Persistent conditions correlate into one fault that updates in place instead of flooding the board each poll, and a fault auto-resolves when a later cycle no longer sees the condition. The detection loop is steady on its own, regardless of what the operator is doing.
Guardrails an operator can sleep on
The kill switch is a single toggle that hard-blocks the execution path at the orchestrator, regardless of UI state, while detection keeps running. The audit trail is append-only at the database level: every detection, RCA, approval, and execution is recorded with actor and timestamp, and the trigger blocks edits and deletes even from an admin. Vendor control-plane credentials live in an encrypted vault per org and are decrypted only server-side at execution time, never returned to the browser. For how the same model handles a mixed Meraki and UniFi fleet, see multi-vendor LAN faults under one model, or the NetMender product page for the live demo.
Related guides
Keep reading
Networks
Multi-vendor LAN faults under one model
Running a mixed Meraki and UniFi fleet (and a real on-LAN host probe) under one canonical fault model, one board, swappable per-vendor adapters underneath.
Governance
IT governance, run by agents
How Paragon turns governance from a dashboard of problems into an assess, generate, remediate loop across twelve modules.
See it on your own network
Tell us the vendors you run and we will get you into the demo against a fleet like yours.
Subscribe
Get new guides when they drop. One email when there is something to read; never spam.