The AI in your RMM should be a router, not an interpreter

Most “AI in RMM” features ship the same way. There is a chat box bolted on. The model gets a fat system prompt about what your environment looks like. You type “patch the Acme servers.” The model decides what to do, calls some tools, invokes a script, and writes a friendly summary at the end.

That is the model as interpreter. The model is running the operation, and the system around it is mostly trust.

I think this is the wrong shape. The model should be a router. It looks at the request, picks one of a small set of named tools, and passes the arguments. The tools are written in regular code, by you. They do exactly what their code says they do. The model cannot improvise around them or decide a tool’s safety guarantees do not apply this time.

In Breeze, the LLM picks from around 12 named tools. Each has a Zod-validated schema for its inputs. The tools are tiered. Read-only tools (T1) run immediately. Configuration-changing tools (T2) log and proceed. State-changing tools (T3) block on a human approval card before the action happens. The model cannot self-approve, retry around the approval, or chain past it by calling a different tool. The approval is enforced in code, outside the model’s reach.

That is what an AI-native audit row looks like in the database: tool, input, approver, session. If you cannot reconstruct which tool, on whose behalf, with what arguments, with whose approval, you do not have audit. You have hope.

The interpreter pattern puts the model in the security perimeter. That is a mistake born from how chatbot UIs got built. The router pattern moves the perimeter to the tool’s code, where someone you can hold accountable wrote it.

Stop trying to harden the prompt. Harden the tools and let the model do the routing. That is where the real boundary lives.