AI & Software

Peplink diagnostic agent

A troubleshooting agent that compares live router readings, outage history, and documentation without changing the network.

My role: Sole developer and system owner
Project state: Prototype
Technologies: Python / FastAPI / MCP / Claude / LanceDB / BM25 / ONNX / pytest

Inside one investigation

Has the connection actually recovered?

I built a Python service, diagnostic tools, and a web console to investigate network problems. In this recorded run, the agent found improved availability after a carrier change, remaining disconnects, and a backup connection that had not taken over. It qualified the carrier explanation because there was no controlled comparison.

The Peplink console gathers live health and historical availability, while an event-log query fails because it exceeds the seven-day limit. — The first tool calls, including a rejected 14-day event-log request. The complete run made 20 calls across six model turns. View full size ↗

Recorded live investigation, 28 October 2026. Identifying details and credentials were replaced; measurements, event sequence, and conclusions were preserved. The stills and video come from a replay in the actual console. Replay pauses were shortened, so playback does not represent response speed.

Watch the recorded investigation · 1:59

1:59 · Silent replay of the recorded investigation. Identifying details replaced; pauses shortened, not representative of response speed. Open video ↗

The three stages below summarize the question, evidence, and assessment in the silent recording.

Read the investigation and evidence

01 / Investigation

Start with an operational question

The operator asks whether one site has recovered, what changed, and why disconnects remain. The answer needs to reconcile live router readings with two weeks of cloud history.

SITE-024 had serious connectivity problems over the past two weeks. Has it recovered?

The prompt also asks for the main WAN and carrier changes, a comparison of current health and historical availability, and evidence for the assessment.
The agent queries current health, cellular status, availability, and connectivity history. After the event-log request fails, it retries within the supported seven-day window.

02 / Investigation

Reconstruct the recovery

The records show a change from a physical SIM to an AT&T eSIM on 22 October, followed by improved availability. At the time of investigation, the cellular link had been up for about 26 hours, with strong current signal readings.

The recorded answer lists current router health, cellular uptime, two radio-band measurements, and the cold-standby Wi-Fi configuration. — Current evidence from the recorded assessment. Names and addresses are replaced; the readings are preserved. View full size ↗

The history still contains a 33-minute outage on 24 October and brief later drops. Daily availability rounded to 100% does not mean there were no disconnects.
The Wi-Fi backup was in cold standby and did not connect during the longer outage. The agent flags this as a resilience gap, while acknowledging that it did not verify why the backup was unavailable.

03 / Investigation

Separate recovery from certainty

The assessment is “mostly recovered, but not completely.” It associates the improvement with the carrier change, but explicitly says this was a timing-based inference without a controlled comparison.

The answer’s reasoning-boundary section distinguishes inferences about power, carrier changes, remaining drops, backup availability, and clock offset from direct observations. — The answer qualifies its own conclusions. Strong signal now cannot establish radio conditions at an earlier disconnect. View full size ↗

The agent suggests narrower signal-history queries and checks of the tunnel and Wi-Fi events. It made no configuration changes.
All six cited passage identifiers were present in retrieval results. This verifies citation provenance, not the correctness of every inference.

Inspect the evidence

Selected excerpts from the recorded live investigation. Identifying details were replaced; measurements, tool calls, and conclusions were preserved.

Current signal is only a snapshot

Measurements reported in the recorded assessment from get_wan_status and get_cellular_status at 06:43:24 UTC. These are real observations with identifying details replaced.

Cellular uptime: 94,241 seconds (about 26.2 hours)
Band B2:  RSRP −79 dBm, RSRQ −6 dB, SINR 26 dB
Band B12: RSRP −85 dBm, RSRQ −5 dB, SINR 15 dB

Missing tunnel history

The ic2_speedfusion_device call failed. The answer keeps this gap visible rather than inventing tunnel history.

PENDING response requires an asynchronous typed wrapper

A traceable source

The answer cites the project’s failover runbook when discussing health-check failures. It also retrieves vendor documentation; citation presence alone does not establish the cause of this incident.

Title: Runbook: WAN priority and failover
Version: 2026-07
Section: Diagnosing failover events
Passage: 30aba66cf5737bb125db

The answer’s own limitation

An exact excerpt from the recorded answer. The opening assessment sounds more certain; this later qualification matters when judging its conclusion.

This is based on timing (stable from 22 Oct 11:40, apart from 24 Oct). I didn't have a controlled comparison.

Check where an answer came from

I combine semantic search with keyword search so retrieval can match both symptoms and exact feature names. Returned passages carry source and version information. The system checks that cited passage IDs were actually retrieved; an operator still has to judge whether the conclusions follow.

Keep execution outside the agent

The agent can inspect the network and propose a change, but it has no tool that executes one. Requests for remediation produce a dry-run preview. The CLI and MCP layer have a separate, explicitly gated path for operator actions. Tests cover that boundary alongside retrieval, redaction, and diagnostic scenarios.

Current state

This is a working prototype with a web console, CLI, MCP server, and a restricted cloud variant. Broad team adoption is not claimed. Recorded scenarios help me test its behaviour, but answers still depend on fresh observations, available access, and an operator’s judgment.