Iris guides

Iris is rConfig’s AI layer: the AI features inside rConfig, and the MCP server that lets outside agents read your configuration data. In the rConfig app you’ll find it under AI Center.

An AI agent is only as good as the facts it can reach. rConfig holds one set of facts no other tool in your stack has: what is actually configured on every device, what changed and when, and whether it passes your policies. These guides cover how to put those facts in front of the agents your engineers already use, alongside the other tools they already run. The step-by-step setup stays in the AI Center documentation; these pages explain the design and the use cases.

What rConfig answers, and what it doesn’t

Most network questions need more than one source. An agent connected to several tools over the Model Context Protocol (MCP) can ask each one the question it is best placed to answer, then combine the results.

Question	Tool type	Examples
What is configured, what changed, is it compliant?	Configuration management	rConfig
What should be there?	Source of truth	NetBox, Nautobot, Infrahub
Is it healthy right now?	Monitoring	Zabbix, LibreNMS, Statseeker, PRTG, Checkmk, Grafana
Who got paged, and when?	Incident response	PagerDuty
Who asked for the change?	ITSM	ServiceNow, Jira
What happened in the logs?	SIEM	Splunk, Elastic

rConfig already shares a device inventory with several of these through Device Sync, so device names usually line up across tools. That makes cross-tool questions far more reliable: the agent doesn’t have to guess that dub-core-01 in NetBox is the same box as dub-core-01 in rConfig.

Two ways AI reaches rConfig

flowchart LR
    subgraph inside["Inside rConfig"]
        U["Engineer clicks<br/>Ask AI / Analyze / Narrate"] --> R["Iris<br/>(AI Center in rConfig)"]
        R --> P["Your AI provider<br/>(set in AI Settings)"]
    end
    subgraph outside["Outside rConfig"]
        A["Your agent<br/>Claude Code, Cursor, Copilot, Codex"] --> M["rConfig MCP server<br/>read-only, 8 tools"]
        A --> O["Other MCP servers<br/>NetBox, Grafana, PagerDuty"]
        A --> AM["The agent's own model"]
    end

Inside rConfig, the Iris capabilities (config analysis, drift narration, compliance narration) run on the provider you configure in rConfig. You control the model, and with a local model nothing leaves your network.

Outside rConfig, an agent connects to the MCP server with a token and reads devices, configs, history, diffs and compliance results. rConfig’s AI provider plays no part here. The agent sends what it reads to whatever model the agent uses, so that model’s data terms apply to your configs. Secrets are obfuscated before they leave rConfig either way.

Guides in this section

Connecting agents

Which AI agents can connect to rConfig over MCP? Every common client, how it authenticates, and what it needs to reach your server.
Using rConfig with other MCP servers Running rConfig next to NetBox, Grafana, PagerDuty and monitoring servers in one agent.
Setup and use, client by client: Claude Code, Claude Desktop, Cursor, VS Code and Copilot, Codex CLI, Gemini CLI, n8n, and ChatGPT and Claude on the web.

How Iris works

The context harness The built-in knowledge Iris adds to every request, and the knowledge your team can add.
Read-only by design What Iris and the MCP server can and can’t change.
Better config analysis What Iris reads, and how to ask for answers you can check.
Change review with drift narration Triage a change in a minute.
Audit responses with compliance narration From a failed policy to an audit answer.
Drafting policies with AI Generate, test and tighten policy rules.

Playbooks: operate and secure

Alert to root cause A monitoring alert fires; the agent finds what changed on the device and explains it.
Find devices exposed to a security advisory Turn a vendor advisory into a list of affected devices from stored configs.
Change window verification Prove only the approved lines changed, and note it on the ServiceNow or Jira ticket.
Event-driven change narration Every config change explained in Slack, Teams or a ticket as it happens.
Unauthorised change hunt Match config changes with Splunk or Elastic logs and approved tickets.
Audit evidence pack Compliance results and config evidence, drafted for the auditor.
Scheduled digests A morning summary of changes and compliance from a headless agent.

Playbooks: plan and automate

Compare NetBox intent with running configs Find where the source of truth and the network disagree.
Batfish pre-change validation Test a change in Batfish against snapshots built from rConfig.
Engineer onboarding New engineers ask how each site is built, answered from real configs.
ChatOps in Slack and Teams Ask rConfig questions without leaving chat.
Remediation as code From compliance failure to an Ansible playbook in a pull request.
Migration verification Check a move from Oxidized, RANCID, NetMRI or SolarWinds NCM is complete.

Architecture

Choosing an AI provider and model Cloud API, Azure tenant or self-hosted, compared.
Provider designs: self-hosted with Ollama or vLLM, Azure OpenAI, public API, and the split design.
Sizing a local model The context window Iris needs, and Ollama’s 4k default.
Reference designs: NetBox, rConfig and monitoring, ITSM-integrated, air-gapped NOC, and MSP multi-tenant on Vector.

Governance

Data flow map What leaves rConfig, where it goes, and what’s kept.
Prompt injection and trust Free text in configs and tickets, and trust rules for multi-tool agents.
Access and least privilege Permissions, roles and MCP tokens for people and automation.
Rolling out Iris A phased plan from pilot to team-wide use.
Cost and tokens What drives spend, and how to measure and control it.
Security review The questions security teams ask, and where the answers are.

Ground rules these guides follow

rConfig stays read-only. No AI path in rConfig changes a device, and the MCP server has no write tools. Where a playbook ends in a change, the change goes through your own tooling with a person approving it.
Each page states what it was tested against. Playbooks carry a status. Reference design means the workflow is built from documented tool behaviour but has not been run end to end in our lab.
Third-party tools change quickly. Client and MCP server details were checked against vendor documentation on the date at the top of each page. Check your client’s current docs if a setting doesn’t match.