Blog · Architecture
One AI Relay, Many ERPNext Installs: Inside the Noviz Plugin Architecture
Every customer who installs the Noviz plugin into their own ERPNext gets the same question answered differently depending on their own data, their own roles, and their own permissions, without any two customers' data ever touching. That's not a database trick. It's a specific split between what runs inside each customer's ERPNext and what runs centrally, and it's worth explaining because it's the part of the architecture an integration architect should actually scrutinize before trusting an AI agent near production data.
The plugin is deliberately thin
The ERPNext side is a native, open-source Frappe app: no subprocess, no daemon, no bundled model. It exposes one whitelisted entry point that a signed-in user's browser calls, and every real data operation it performs runs through Frappe's own ORM, under that user's own already-authenticated session. The plugin never holds a standing "agent" credential, and it never sees more of ERPNext's permission model than the person using it already has. If a user can't see a doctype in the desk UI, the agent can't either, because it isn't a separate identity, it's the same one.
The reasoning stays central, and stays generic
The actual planning, all of the tool selection, and every LLM call happen on one shared backend, not inside each customer's install. What crosses that boundary is not a raw ERPNext query. It's a small, generic call specification, a "fetch this doctype, these fields, this filter" shape, that carries zero business vocabulary specific to any one customer's setup. The plugin's own job is limited to executing that literal instruction against Frappe's ORM and handing back the result. It never has to understand what a "quotation" or a "purchase order" means to the reasoning layer, which is exactly what keeps the public plugin repository free of proprietary logic while the private backend keeps doing the actual thinking.
Why the split, not a bundled model per install
Running the model inside every customer's own ERPNext would mean shipping proprietary reasoning logic into a public, open-source repo, and re-deploying that logic to every install separately every time it improves. Centralizing it means one backend gets better once, for everyone, without touching a single customer's site, while the trust-sensitive part, actual data access, stays local, permissioned, and fully within each customer's own ERPNext instance the whole time.
Isolation is structural, not just configured
Each request is resolved to exactly one tenant before anything else happens, and a conversation's state is scoped to that tenant for its entire lifetime, including when a multi-step exchange pauses and later resumes. Two customers asking about "open invoices" at the same moment are handled as fully independent turns; neither ever has a code path into the other's records, because the tenant boundary is checked at resolution time, not assumed downstream.
That's the shape worth asking about with any AI agent that touches your ERP: what crosses the wire, under whose identity, and how thin is the boundary between the part that reasons and the part that can actually act.