Rolling out network changes fast is great—rolling them back safely when something goes sideways is even better. In this guided conversation, we’ll show how the Quantum Network Monitor Assistant helps you automate change windows end-to-end: take a baseline, stage and apply a change, validate with parallel tests, and roll back if needed. We’ll rely on built-in functions for monitoring, diagnostics, and automation, and we’ll point out how each call informs the next step. You can try these steps yourself via the Quantum Network Monitor Assistant.
Scenario A network engineer is pushing a firewall ACL and routing change to Data Center 1. They need:
Step 0 — Pick the right agent for the job We start by listing available monitoring/scanner agents to run tests from a relevant vantage point (e.g., your data center or a nearby region).
User: Which agent should we use for DC1 changes?
Assistant: Let’s list agents and pick one in or near DC1.
Function call
{
"name": "functions.get_agents",
"arguments": {
"detail_response": false
}
}
How we interpret the response
Step 1 — Establish your baseline monitors We add a small set of monitors that represent business-critical paths before the change window begins. add_host sets up ongoing monitoring for each target.
User: Baseline these four: the DC1 gateway, the intranet site, internal DNS, and SMTP.
Assistant: I’ll add ICMP for the gateway, HTTPS for the intranet, DNS for the resolver, and SMTP HELO checks for the mail relay.
Function call
{
"name": "functions.add_host",
"arguments": {
"address": "gw-dc1.corp.local",
"endpoint": "icmp",
"timeout": 5000,
"agent_location": "DC1 - Local Agent",
"email": "[email protected]"
}
}
{
"name": "functions.add_host",
"arguments": {
"address": "intranet.corp.local",
"endpoint": "https",
"timeout": 8000,
"agent_location": "DC1 - Local Agent",
"email": "[email protected]"
}
}
{
"name": "functions.add_host",
"arguments": {
"address": "dns.corp.local",
"endpoint": "dns",
"timeout": 5000,
"agent_location": "DC1 - Local Agent",
"email": "[email protected]"
}
}
{
"name": "functions.add_host",
"arguments": {
"address": "mail.corp.local",
"endpoint": "smtp",
"timeout": 7000,
"agent_location": "DC1 - Local Agent",
"email": "[email protected]"
}
}
How we interpret the response
Step 2 — Snapshot the baseline data We pull the latest dataset (dataset_id: 0) for quick pre-change numbers.
User: Grab the current status so we can compare later.
Function call
{
"name": "functions.get_host_data",
"arguments": {
"detail_response": true,
"dataset_id": 0,
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 3 — Clear old alerts before the change We reset stale alerts to avoid confusion as we enter the change window.
Function call
{
"name": "functions.reset_alerts",
"arguments": {
"reset_all_hosts": true
}
}
How we interpret the response
Step 4 — Pre-change automated tests (quick diagnostics) We run a short set of real-time checks just before applying changes.
User: Run pings and a traceroute to the intranet, plus a TLS config check.
Assistant: Kicking off BusyBox pings/traceroute locally, and an OpenSSL check via the Security Expert.
Function calls
{
"name": "functions.run_busybox_command",
"arguments": {
"command": "ping -c 5 intranet.corp.local",
"agent_location": "DC1 - Local Agent",
"number_lines": 40
}
}
{
"name": "functions.run_busybox_command",
"arguments": {
"command": "traceroute intranet.corp.local",
"agent_location": "DC1 - Local Agent",
"number_lines": 80
}
}
{
"name": "functions.call_security_expert",
"arguments": {
"message": "I am authorized to assess intranet.corp.local. Please run an OpenSSL TLS check to report protocol versions, ciphers, and certificate chain to confirm current baseline.",
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 5 — Create “Apply” and “Rollback” automations We package the change and rollback as Cmd Processors. The expert turns our description into manageable .NET processors that we can run on demand.
User: Build two processors—apply the firewall ACL and route change; rollback restores prior state. We’re authorized to execute on DC1.
Function call
{
"name": "functions.call_cmd_processor_expert",
"arguments": {
"message": "I am authorized to manage cmd processors on the DC1 agent. Create two processors: (1) apply_dc1_change: Connect via SSH to firewall 10.10.0.1 and router 10.10.0.254 using stored creds, push the provided ACL snippet and route updates, then save/commit and return structured JSON with success/failure per step. (2) rollback_dc1_change: Revert to the last known-good ACL and route set (paths provided), commit, and return structured JSON. Provide help text for both and store them for later runs.",
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 6 — Apply the change during the window We run the apply processor. The assistant captures the result for the runbook.
User: It’s time—apply the change.
Function call
{
"name": "functions.call_cmd_processor_expert",
"arguments": {
"message": "I am authorized to run the cmd processor apply_dc1_change with default arguments. Execute now and return the structured JSON result.",
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 7 — Post-change automated validation in parallel Immediately after applying, we run multiple tests together: monitoring reads, quick traceroute, a short Nmap service scan, and a TLS re-check.
User: Validate fast—grab monitors, trace the path, and confirm external exposure/TLS.
Assistant: Running tests in parallel for speed.
Function calls
{
"name": "functions.get_host_data",
"arguments": {
"detail_response": true,
"dataset_id": 0,
"agent_location": "DC1 - Local Agent"
}
}
{
"name": "functions.run_busybox_command",
"arguments": {
"command": "traceroute intranet.corp.local",
"agent_location": "DC1 - Local Agent",
"number_lines": 80
}
}
{
"name": "functions.call_security_expert",
"arguments": {
"message": "I am authorized to run an Nmap service scan against intranet.corp.local targeting the web service only to validate exposure and banner changes. Use a safe, limited scan profile.",
"agent_location": "DC1 - Local Agent"
}
}
{
"name": "functions.call_security_expert",
"arguments": {
"message": "I am authorized to perform an OpenSSL TLS re-check for intranet.corp.local and compare protocols/ciphers/cert chain against pre-change baseline.",
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Optional quantum-safety posture check If your change might affect edge policies or TLS front-ends, a quick quantum-readiness spot check can help validate that post-quantum settings remain intact.
Function call
{
"name": "functions.call_quantum_expert",
"arguments": {
"message": "I am authorized to assess intranet.corp.local. Test for TLS KEM support and post-quantum certificate usage; perform a quantum readiness check and summarize any change from baseline.",
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 8 — Detect anomalies quickly We can filter for newly triggered alerts right after the change.
Function call
{
"name": "functions.get_host_data",
"arguments": {
"alert_flag": true,
"dataset_id": 0,
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 9 — Safe rollback on failure If post-change SLOs degrade or key tests fail, we roll back immediately.
User: Roll it back now and re-validate.
Function call
{
"name": "functions.call_cmd_processor_expert",
"arguments": {
"message": "I am authorized to run the cmd processor rollback_dc1_change with default arguments. Execute now and return the structured JSON result.",
"agent_location": "DC1 - Local Agent"
}
}
Follow-up validation (same as Step 7) confirms restoration.
Step 10 — Automate the runbook with a Connect To make this repeatable, we create a Connect that automatically:
Function call
{
"name": "functions.call_connect_expert",
"arguments": {
"message": "I am authorized to add a Connect named dc1_change_validator. Behavior: (1) Before window: pull latest get_host_data for targets gw-dc1.corp.local, intranet.corp.local, dns.corp.local, mail.corp.local; (2) On window start: run apply_dc1_change; (3) Post-apply: perform traceroute, OpenSSL TLS check, and a limited Nmap web scan; (4) If any monitors show alert_flag or test failures, run rollback_dc1_change automatically; (5) Send a summary report including latency deltas and test diffs. Schedule is manual trigger only.",
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Step 11 — Tuning or removing monitors After the change is stable, you can adjust or remove temporary monitors.
Edit a monitor
{
"name": "functions.edit_host",
"arguments": {
"address": "intranet.corp.local",
"timeout": 6000,
"agent_location": "DC1 - Local Agent"
}
}
Delete a monitor
{
"name": "functions.edit_host",
"arguments": {
"address": "mail.corp.local",
"hidden": true
}
}
How we interpret the response
Step 12 — Reset alerts and archive the window Before finishing, clear any residual alerts and pull a final data snapshot for your change record.
Reset alerts
{
"name": "functions.reset_alerts",
"arguments": {
"reset_all_hosts": true
}
}
Final snapshot
{
"name": "functions.get_host_data",
"arguments": {
"detail_response": true,
"dataset_id": 0,
"agent_location": "DC1 - Local Agent"
}
}
How we interpret the response
Tip — Cancel long-running jobs if needed If a heavy scan runs too long, you can cancel it by its message ID.
{
"name": "functions.cancel_functions",
"arguments": {
"message_id": "change-window-scan-001"
}
}
Function roles recap
Closing With a handful of focused function calls, you can transform risky, late-night changes into a safe, automated routine: baseline, apply, validate in parallel, and roll back instantly if something drifts. Try these steps in your own environment and tailor the flows to your runbooks using the Quantum Network Monitor Assistant.
A local DC1 agent gives you a more realistic view of how the change affects services from inside the data center. That makes pre- and post-change validation more accurate for internal paths, latency, routing, firewall behavior, and service reachability.
You should compare monitor status, latency, packet loss, traceroute path changes, TLS settings, and service exposure. The goal is to spot any new alerts, degraded response times, unexpected route changes, certificate or cipher drift, or newly opened/closed ports after the change.
You should roll back if key SLOs degrade or validation checks fail after the change. Examples include alert_flag turning true on monitored targets, ICMP or HTTPS failures, increased latency or packet loss, failed DNS or SMTP checks, unexpected traceroute changes, or security validation results that differ from the approved baseline.
The automated runbook packages the entire workflow into a repeatable process: collecting baselines, applying the change, running validation checks in parallel, triggering rollback automatically if needed, and generating a summary report. This reduces manual effort, improves consistency, and makes change windows easier to audit and reuse.
Yes. The post shows that you can tune monitors with edit_host, remove temporary ones by setting hidden=true, reset alerts to clear leftover flags, and take a final data snapshot for audit records. You can also cancel long-running scans during the window if they take too long.
In this walkthrough, we’ll show how a user and the Quantum Network Monitor Assistant collaborate to create, upload, and test a custom .NET command processor for advanced automation—end to end. Along t
Read More