Explain every network config change automatically with rConfig webhooks and an AI agent

Explain every network config change automatically with rConfig webhooks and an AI agent

A config change on a core device should never surprise anyone. rConfig already sends a config.changed webhook the moment a backup differs from the previous version. Put an agent between that webhook and your team channel, and every change arrives with a short explanation of what changed and why it might matter.

Best for: NOC and operations channels, change awareness across teams, catching out-of-hours changes. Tools: rConfig webhooks and MCP server, plus n8n or a small service you run. rConfig tools used: get_config_history, get_config_diff, get_latest_config, get_compliance_status (all optional; the webhook carries the diff).

How it flows

flowchart LR
    R["rConfig<br/>config.changed"] --> V["Receiver<br/>verify signature,<br/>skip seen event ids"]
    V --> F{"Worth explaining?<br/>group, size"}
    F -- yes --> A["AI agent<br/>+ rConfig MCP"]
    F -- no --> X["Drop or log"]
    A --> O["Slack / Teams / ticket"]

The webhook payload includes the device name and ID, the config ID, the command and the diff lines, so the agent usually has enough to start without calling rConfig at all. The MCP tools give it more context when needed: earlier versions, the full config, compliance status.

Two ways to build it

Either way, the agent uses a token for a dedicated rConfig user, and the receiver checks the webhook’s signature before doing anything else.

The prompt

Keep the instruction short and the output shape fixed, so messages look the same every time:

A configuration change was detected on DEVICE (rConfig device ID ID, command COMMAND). The diff is below. In under 80 words: what changed, what it affects, and a risk rating (low, medium, high) with one reason. If the diff alone isn’t enough to judge, use rConfig to look at the previous two versions. Don’t speculate about who made the change.

An illustrative message:

dub-core-01 changed at 02:14 (running config, version 212)
VLAN 30 removed from the trunk allowed list on Gi1/0/48 (uplink to dub-dist-02).
Hosts in VLAN 30 behind dub-dist-02 lose their path to the core.
Risk: high. A production VLAN was removed from an uplink outside a change window.

Keeping it useful

• Filter before the agent runs. Not every change deserves a message. Filter by device group in the webhook itself, then skip diffs below a few lines or that only touch descriptions.
• Route by risk. Post low-risk summaries to a quiet channel and high-risk ones to the on-call channel.
• Deduplicate. The event id stays the same across retries and redeliveries; store processed ids.
• Don’t name people. The diff doesn’t say who made the change. If you need that, see Find unauthorised network changes, which correlates with your logs.

Related reference

• Webhooks
• Drift Detection and Narration
• Connect an AI agent over MCP
• n8n with rConfig