Skip to content
Guides & References

Split AI design: a local model for Iris, cloud agents over MCP

Keep Iris on a self-hosted model, and let engineers who need more use cloud agents over MCP with tokens scoped to the devices allowed off site.

Iris: AI CenterReference designUpdated
On this page

Split AI design: a local model for Iris, cloud agents over MCP

Two AI paths reach rConfig, and they don’t have to share a provider. In the split design, Iris’s everyday features (explain this config, narrate this change) run on a self-hosted model, so routine use never leaves the site. Engineers who need the strongest models for harder work (estate-wide investigations, automation code) use cloud agents over MCP, with tokens that limit which devices those agents can read.

What it looks like

flowchart LR
    subgraph site["Your network"]
        U["Engineers in rConfig"] --> R["rConfig"]
        R --> M["Self-hosted model<br/>Ollama / vLLM"]
        E["Engineer's laptop<br/>Claude Code, Cursor, Codex"] -- "MCP, scoped token" --> R
    end
    E -- "agent's own model" --> C["Cloud model provider"]
Path Provider What it sees
Iris inside rConfig Your self-hosted model Every config the user can open in rConfig
Agents over MCP Each agent’s cloud model Only the devices the token owner’s role allows

Who it suits

  • Organisations that allow some configs off site (lab, branch, low-risk segments) but not others (core, payment, OT).
  • Teams that want strong models for automation work without sending every config to the cloud.
  • A stepping stone: the self-hosted model handles daily use while you decide on a long-term provider.

Controlling what reaches the cloud

The MCP token is the control point.

  • Scope roles by tag. Tag the devices whose configs may leave the network, and give cloud-agent users a role scoped to that tag. Their tokens then see only those devices. See tag-scoped roles.
  • Tokens belong to their creator. A token sees what its creator sees, so engineers create their own. See Tokens and what the agent can see.
  • Review the activity log. Every MCP tool call is logged with the tool, outcome and device, so you can confirm agents stay inside their scope.

Pros

  • Routine use stays on site, at no per-token cost.
  • Engineers still get the strongest models where they add the most.
  • Exposure is limited by rConfig roles you already manage.

Cons

  • Two things to run: a model server and MCP token hygiene.
  • Iris’s answers on long configs are only as good as the local model.
  • Relies on correct role scoping.

Frequently asked questions

Can rConfig use a local model and still work with Claude Code or Cursor?

Yes. The provider you set in rConfig only drives Iris's features inside rConfig. Agents connect over MCP separately and use their own models. The two settings are independent.

How do I control which configs reach cloud agents?

Through MCP tokens. Each token sees only the devices its owner's rConfig role allows, so give cloud-agent users roles scoped to the devices whose configs may leave your network, for example with tag-scoped roles.

Is this more complex than one provider?

Slightly. You run a model server for Iris and manage MCP tokens for agents. In return, everyday use stays on site and only deliberate agent work goes to the cloud.

Type to search.