# From Switch Config to NetBox in One Prompt > Your NetBox says one thing, your switch says another. Here is how to reconcile them with a single natural-language instruction instead of a Python script you have to maintain forever. Canonical: https://www.toolmesh.io/en/blog/switch-config-to-netbox/ ## The situation You run NetBox as your source of truth. It is good, until it isn't. Last Tuesday someone swapped a switch in rack B. They added two VLANs, renamed a couple of interfaces, and moved an uplink. NetBox knows none of it. Now your IPAM is quietly wrong, your cable map lies, and the next person who trusts NetBox to plan a change is going to have a bad afternoon. The usual fix is a sync script. You write a few hundred lines that pull the live config, diff it against NetBox, and push the deltas. It works. Then the vendor ships a firmware update, an interface naming scheme changes, you add a second switch model, and now you maintain the script as carefully as the network it describes. There is a different shape to this. ## The instruction Here is what the task looks like when the tooling carries the connectivity and you carry the intent: > Read the live configuration from the `perlman` switch. Compare its interfaces, IP addresses and VLANs against what NetBox has for that device. Tell me every difference, then update NetBox to match the switch — but stop and show me anything that looks like a removal before you delete it. That is the whole thing. No script. Tomorrow the instruction is "…and also reconcile rack B's MikroTik while you're at it" and nothing in your codebase has to change, because there is no codebase. The instruction is the automation, and it is disposable by design. ## What actually happens underneath This is not magic, and the point of this series is that you can see exactly what runs. The agent has two tool surfaces in front of it, both served through a single ToolMesh endpoint: - the MikroTik switch, described by a [DADL](/en/dadl/) file — about thirty lines of YAML turn its REST API into callable tools like `export_config`, `list_interfaces` and `list_ip_addresses` - NetBox, the same way — `netbox_get_device`, `netbox_create_interface`, `netbox_create_ip_address`, `netbox_update_*` In Code Mode the model does not fire one tool call per round-trip. It writes a short piece of JavaScript that runs server-side and only returns the result: ```javascript // pull live state const live = await toolmesh.mikrotik_perlman_list_interfaces({}); const liveIps = await toolmesh.mikrotik_perlman_list_ip_addresses({}); // pull NetBox's view of the same device const device = await toolmesh.netbox_get_device({ name: "perlman" }); const nbIfaces = await toolmesh.netbox_list_interfaces({ device_id: device.id }); // diff happens here, in code, not in the model's head return diff(live, liveIps, device, nbIfaces); ``` One execution, one result back to the model. A catalogue of eighty NetBox tools plus the switch's tools would cost roughly 142,000 tokens to advertise on every reasoning step if you listed them all as JSON schemas. Code Mode keeps that closer to a thousand, flat, no matter how many backends you add. That is the difference between "this is neat in a demo" and "I can leave this running against my real network." ## The parts you'd worry about, handled **Nothing deletes silently.** The instruction said stop and show me removals, and that is enforced at the gate, not just left to the agent's good intentions. Two core mechanisms do it. Authorization comes first: through OpenFGA, an agent can hold `netbox_create_*` and `netbox_update_*` but never `netbox_delete_*` — the delete tools are simply never unlocked for it. And the `ExecuteTool()` pipeline runs a Pre-Gate before any call reaches the backend, where a short hard rule — plain JavaScript — refuses anything matching `netbox_delete_*`. The pipeline is fail-closed: if a rule can't decide, the call is denied, not waved through. Creates and updates flow; deletions are refused at the gate, so the agent shows you the removals it found and changes none of them. You write that once, and it holds for every prompt you ever run. **No credentials in the prompt.** The switch's API token and the NetBox token never reach the model. They live in ToolMesh's credential store and get injected at call time. The model orchestrates; it never sees a secret. **You can prove what happened.** Every call lands in a structured audit log — which tool, which device, what changed, how long it took, success or denied. When someone asks in three weeks why interface `sfp-sfpplus3` got renamed, the answer is a query, not an archaeology project. ## What this is, and what it isn't If your reaction is "I've done config-to-NetBox with Nornir for ten years" — you have, and well. The claim here is not that this is more powerful than a purpose-built script. It's that there is no script to maintain. The reconciliation logic isn't pinned to one vendor, one naming scheme, or one NetBox version. The instruction adapts to the situation in plain language; the tools underneath are declared in YAML you can diff in Git. When the situation changes, you change a sentence, not a pipeline. That is the whole bet: network state changes constantly, so the layer that reconciles it should be the cheap, disposable part — not the part you babysit. ## Want to try it on your own network? The honest friction here is setup: standing up ToolMesh, writing the DADL for your switch, wiring NetBox. If that friction is the thing stopping you, skip it. ToolMesh is an offering of [Dunkel Cloud GmbH](https://www.dunkel.cloud/), and we will set up a personal instance for you on its own VM — you keep full control and your own credentials, we just do the initial wiring so you can point it at your gear and see whether the reconciliation actually holds up against your reality. That offer is genuine, and it is the fastest way to find out if this fits how you work. --- This is post 1 of a series on driving NetBox from real infrastructure: [MikroTik](https://dadl.ai/d/mikrotik), OPNsense, [Xen Orchestra](https://dadl.ai/d/xen-orchestra), [Hetzner](https://dadl.ai/d/hetzner-cloud), vSphere, and UniFi. Each one is a real workflow from our own stack, not a contrived demo. ToolMesh is open source (Apache 2.0). DADL is an open spec (CC BY-SA 4.0) with a public registry at [dadl.ai](https://dadl.ai/).