Skip to content
Guides & References

Onboard network engineers faster with an AI agent over rConfig and NetBox

Give new network engineers an AI agent that reads real configs from rConfig and intent from NetBox, so they can ask how each site is built.

Iris: AI CenterReference designUpdated
On this page

Onboard network engineers faster with an AI agent over rConfig and NetBox

A new engineer’s first months are spent reverse-engineering the network: opening configs, tracing VLANs, asking colleagues why dub-dist-02 has a static route nobody remembers adding. An agent connected to rConfig (what’s configured) and NetBox (what was designed) lets them ask those questions in plain language and get answers grounded in the real configs.

Best for: new starters, engineers moving to a new region or customer, on-call engineers covering an unfamiliar site. Tools: rConfig. Optional: NetBox, Nautobot or Infrahub. rConfig tools used: get_devices, get_latest_config, search_configs, get_config_history.

Set it up for the person, not the team

  • Their own token. Have the engineer create their own MCP token, so the agent sees exactly the devices their rConfig role allows. See Tokens and what the agent can see.
  • A client they’ll use. Claude Desktop for chat, Claude Code or Cursor for engineers who live in a terminal or editor. See the compatibility table.
  • Your conventions written down. Naming standards, design principles, “why we do it this way”. Put them in the agent’s instruction file. Add the same text as customer knowledge entries so Iris’s features inside rConfig use them too.

Questions worth asking

Site tour

Using rConfig and NetBox, give me a tour of site DUB: the core and distribution devices, how they connect, the routing protocol, the VLANs and what each is for, and the WAN links. Point out anything in the configs that doesn’t match NetBox.

Follow a path

How does traffic from VLAN 30 at the Dublin branch reach the data centre? Walk through the relevant config on each device, from rConfig.

Why is this here?

dub-dist-02 has ip route 10.99.0.0 255.255.0.0 10.1.1.254. When did it appear, according to rConfig’s config history, and what else changed at the same time?

Learn the conventions

Look at the hostnames and interface descriptions of the Core group in rConfig. What naming pattern do they follow, and which devices break it?

Make the answers last

Ask the agent to turn a good session into a site page: “Write what you just explained as a Markdown page for our wiki, with the config excerpts you used.” The next new starter begins from that page instead of from scratch. Review it before publishing, and keep it out of public spaces.

Limits to know

  • Configs explain what, not always why. The agent can say a static route exists and when it appeared; only people or tickets know the reason.
  • Long configs. For a full site tour, the agent reads several large configs. Work one site at a time.
  • Check the claims. The agent is a starting point. New engineers should confirm anything they’ll act on.

Frequently asked questions

How can an AI agent help onboard a network engineer?

Connected to rConfig and NetBox over MCP, it answers questions about how a site is built from the real configs and the documented design: routing, VLANs, WAN links, management access, naming. The new engineer asks instead of reading thousands of config lines.

Will a new engineer see devices they shouldn't?

No, if their token is their own. rConfig scopes MCP results to the token owner's role, so a junior engineer's agent sees what their rConfig account sees.

Can the agent explain our naming conventions?

Yes, if you write them down. Iris customer knowledge entries add your conventions to the AI features inside rConfig, and a short instruction file does the same for an external agent.

Type to search.