Noviz NovizAI Agent

Noviz platform architecture

How Noviz is built: one common agent core, every enterprise system

Nine diagrams, read top to bottom: the whole platform, the common core and its connectors, the relay engine in detail, the path of one request, LLM analysis with the local analytics engine, permissions and agent roles, business workflows, knowledge and retrieval, and administration. One shared engine serves every organisation and every system, so a fix made once reaches every customer’s next request, with no per-customer deployment and no plugin update.

The diagrams are wide. On a narrow screen, scroll each one sideways, or view the page on a larger screen.

1 of 9

Platform overview

Every part of Noviz in one picture: the channels where people work, the edge, the product apps, the common agent core, connectors, shared services, data, model providers and operations.

CHANNELS · WHERE PEOPLE WORK 💬 ERPNext Desk Noviz AI app (Frappe) chat page, settings, policies runs calls as the user 🧩 Business Central AL extension, AppSource chat page on Role Centers RecordRef call executor 🏢 Noviz ERP app Vue app on ERPNext agent built in (premium) 38 business pages 🤝 Noviz CRM Vue app on Frappe CRM leads to deals, quotes agent built in (Advantage) 📥 Inbox email and notifications as cards with actions mailbox never modified 📷 Document intake upload or camera invoices, orders, receipts draft until confirmed HTTPS · organisation key · signed-in user and ERP roles · no ERP credentials leave the customer EDGE 🛡️ TLS gateway and routing One public entry point · per-product routes · request limits per organisation · trial sites routed to their own stacks · services never exposed directly PRODUCT APPS · ONE PER ENTERPRISE SYSTEM, ALL ON ONE CORE 🔷 ERPNext agent app registers the ERPNext connector relay protocol for the Frappe app single-tenant routes for self-hosting 🔶 Business Central agent app registers the Business Central connector relay protocol for the AL extension self-registering organisations ➕ Next system Odoo and others a connector plus entity maps the core is unchanged PLANNED NOVIZ AGENT CORE · THE COMMON ENGINE EVERY PRODUCT SHARES 🔑 Organisations and auth key resolves one organisation tier, term, token budget session per turn 🧠 Turn engine reasoning loop, named guards pause, resume, continue bounded steps and time 📝 Prompt system thin core + module sections tool rule blocks on demand cache-friendly fixed order 🧰 Tool registry entity, report, workflow factories from config hand-written modules 🎯 Tool filtering keyword module router spine + discovery search per-request tool cap 🚦 Permission gateway tier × role allowance every call, one entry point confirm before commit 🖼️ Renderers tables, cards, charts PDF reports, print formats one format, every channel ⚡ Caches and gates exact and semantic cache token-rate gate rate limits per tenant 📊 Interaction log every turn and tool call tokens, latency, feedback feeds the review loop 🧱 Layers standard, ERP, client extend, override, add modules on or off per client CONNECTORS · THE ONLY CODE THAT KNOWS AN ERP ERPNext connector canonical entities → doctypes reports, print formats, workflows Frappe permissions as the user Business Central connector canonical entities → BC tables document types, posted records BC permission sets as the user Module packs (12) CRM, selling, buying, stock accounting, HR, manufacturing projects, assets, quality, support Odoo connector same contract models and fields mapped engine and tools unchanged PLANNED SHARED SERVICES 📈 Noviz Analytics Engine LLM picks and explains, local Python engine computes 100 analyses, forecasts, anomalies LLM + ENGINE 📚 Knowledge (RAG) documents → chunks → vectors per-organisation, cited live workflow awareness ROLLING OUT 💳 Accounts and billing one noviz.in account plans, terms, invoices keys issued and renewed 🚀 Trial provisioner ERP, ERP Premium, CRM a new site in minutes go-live on payment 🧭 Site router each trial subdomain to the right stack ERP or CRM DATA AND MODEL PROVIDERS 🗄️ PostgreSQL organisations, turns, usage interaction log, settings billing and trials 🧭 pgvector knowledge and policies semantic response cache embeddings per organisation ⚡ Redis response cache rate limits, token gate shared by all workers 🤖 Reasoning model any chat-completions API switchable in settings no redeploy 👁️ Vision and embeddings document scanning vector search separate key and model OPERATIONS 📐 Contracts OpenAPI for relay, billing, analytics and knowledge one data contract per analysis 🧪 1,300+ automated tests engine, connectors, prompts, guards and renderers full suite on every change 🚢 Tested deploys exactly what is in main build beside, swap, health check automatic rollback 🔍 Review loop logged turns across organisations one fix, made centrally every organisation's next turn Modular monolith first: a part becomes its own service only when it has a different language, load or failure profile (analytics, knowledge). The reasoning hot path (prompt, tool selection, guards, model call) stays in one process: no network hop between deciding and acting.

What this shows: one common agent core serves every product. Each enterprise system gets a thin product app and a connector; everything that reasons, filters, checks permissions and renders is shared. Analytics and knowledge run as their own services because they have a different language and load profile; the reasoning hot path stays in one process.

Back to the diagram list

2 of 9

Core and connectors

How one engine serves ERPNext, Business Central and the systems that follow, and how each organisation receives its own behaviour without a fork.

1 · PRODUCT APP App start-up registers its connector first, then loads the engine Channel protocol turn, continue, next page, scan, feedback, policies System-specific auth Frappe app key, BC entitlement, or direct user sign-in registerConnector() 2 · COMMON CORE (ONE LIBRARY, VERSIONED, TESTED) Engine turn loop and guards turn state, pause/resume response composer Prompt system core blocks module sections by keyword rule blocks per tool session block last Tool factories entity: list/get/create/ update/submit report, workflow hand-written modules Filtering and gateway router feeds prompt + tools spine and discovery tier × role, confirm Renderers and caches table, cards, chart, PDF exact + semantic cache rate and token gates reads every ERP only through the contract 3 · CONNECTOR CONTRACT SystemConnector list, get, create, update, submit aggregate, count, run report PDF, payments, inbox, workflow Entity mapping canonical entity → native object canonical field → native field child tables (line items) Report mapping canonical report key → native report and filters orientation, company scope Call shaping filter triples prepareCallSpec per ERP isToolSupported per add-in 4 · CONNECTOR IMPLEMENTATIONS ERPNext Frappe REST and ORM doctypes, reports, print formats workflow transitions runs as the signed-in user Business Central AL RecordRef executor sales header by document type posted documents read-only BC permission sets Odoo and others models and fields same contract no engine change PLANNED 5 · WHAT EACH ORGANISATION GETS Module packs (12) entities, rules, training, prompt section, keywords per business module Standard layer the common behaviour every organisation starts here sealed parts cannot change ERP layer what one ERP adds or needs e.g. ERPNext print formats, BC document types Client layer extend (calls the base) override, or add new modules switched on or off Resolution order: standard → ERP → client. An override can only add to a module's base prompt sections; locks (sealed, wrap, replace) decide what a layer may change. Modelled on how ERPNext and Business Central themselves are customised: hooks and Customize Form, Chain of Command, never edits to the base. Add an ERP write a connector and entity maps register it in a new app tools, prompts, gateway unchanged Add a customer an organisation and its key optional client layer no code deploy Add a capability one module or factory config reaches every product after the full test suite

What this shows: the core never imports ERP code. A product app registers its connector at start-up; the engine reads every system through one contract. Module packs and three customization layers (standard, ERP, client) decide what each organisation gets, the way ERPNext and Business Central are themselves customised: extend, never edit the base.

Back to the diagram list

3 of 9

Relay engine in detail

The shared relay, hop by hop: from the organisation's key to the call specification the ERP executes, with the caches, gates, budgets and logs that run alongside every turn.

INSIDE THE ORGANISATION'S OWN ERP · ONE OF MANY 💬 Noviz AI Chat native ERP page, no separate login tables, cards, charts, PDF same design on every surface ⚙️ Noviz AI Settings relay key (encrypted), on or off module policies, email account set by the organisation's admin 🔌 Dispatcher executes call specifications through the ERP's own API as the signed-in user 🧩 Business Central add-in same relay, same protocol RecordRef executor permission sets apply HTTPS · organisation key · person and roles · no ERP credential sent RELAY PIPELINE · SHARED BY EVERY ORGANISATION, STATELESS BETWEEN STEPS 🔑 Organisation key → one organisation term, tier, budget 🗂️ Turn state pause and resume across HTTP calls 📝 Prompt layered, cached prefix policy for this org 🎯 Tool filter router + spine discovery search 🧠 Reasoning loop model call, guards bounded steps 🚦 Gateway tier × role confirm writes 🔀 Translator generic call spec no business words 📤 Composer spec or answer rendered output Every hop is a plain function in one process. The pipeline pauses whenever the ERP must run a call, and resumes from saved turn state when the result arrives. Any worker can continue any turn: several workers serve all organisations behind one endpoint. ALONGSIDE EVERY TURN ⚡ Response cache exact, then semantic fresh conversations only 🎚️ Token-rate gate stays under provider limits for all workers 📅 Monthly budget per organisation checked before a model call 🧱 Rate limits per organisation and per endpoint 📊 Interaction log prompt, tools, gates, latency, feedback 📈 Usage tokens per call, per organisation, per month BUSINESS MODULES · ONE CONFIGURATION FOLDER EACH (ENTITIES · RULES · TRAINING · PROMPT · KEYWORDS) CRM Selling Buying Stock Accounting Assets HR and Payroll Manufacturing Quality Projects Support Analytics Plain configuration, shared by every organisation: which entities exist, how fields map through the connector, which reports exist, which keywords load the module. Nothing per organisation is coded into the engine. DATA 🗄️ PostgreSQL organisations, keys (hashed), terms turn state, usage, interaction log settings, billing, trials 🧭 pgvector knowledge and policy documents semantic response cache ⚡ Redis cache, rate limits token gate, shared by workers OUTSIDE CALLS · THE ONLY NETWORK BOUNDARIES 🤖 Model providers reasoning, vision, embeddings swappable in settings, no deploy 📈 Noviz Analytics Engine LLM chooses, local engine computes: forecasts, anomalies; rows never to the LLM 📚 Knowledge service retrieval per organisation cited passages ROLLING OUT 📧 Email keys, invoices, resets never in the chat path ONE SHARED ENGINE · EVERY ORGANISATION IMPROVES AT ONCE 1 · Logged every turn, every organisation prompt, tools, gate, latency 2 · Reviewed patterns across organisations feedback and blocked gates 3 · Fixed once prompt layer, module config, tool or guard, with tests 4 · Deployed tested deploy of main automatic rollback 5 · Everyone sharper the next turn of every organisation gets the fix No change is made per organisation and no plugin update is needed: the engine, prompts and module configuration live centrally. Organisation-specific needs go into that organisation's own layer or policies, never into the shared engine. Data stays in the ERP: the relay keeps turn state, logs and usage, and executes nothing against the ERP itself.

What this shows: the relay reasons; the ERP acts. Every hop is a plain function in one process, paused whenever the ERP must run a call and resumed from saved state. Module packs configure it, model providers, analytics, knowledge and email are its only outside calls, and the review loop at the bottom turns any organisation's logged turn into one central fix for everyone.

Back to the diagram list

4 of 9

Prompt to response

Every step of a single request, from the message typed in the ERP to the rendered answer, including the loop that runs until the answer is ready.

💬 Message typed in the ERP chat page (or a scan, or an inbox action) 🔌 App → relay one HTTPS request: organisation key, person, ERP roles, turn id 1 · 🔑 Resolve organisation, term, tier, budget load turn state if continuing 2 · ⚡ Cache new conversation: exact, then semantic match; a hit answers here 3 · 📝 Prompt and tools router picks modules → prompt sections + spine and module read tools 4 · 📚 Context conversation state, organisation policy, closest knowledge passages 5 · 🤖 Model swappable provider, token-rate gate answers, or proposes tool calls 6 · 🧩 Guards repeat caps, redirects to the right tool step and time limits 7 · 🚦 Gateway tier × role per call; writes become a proposal the person confirms 8 · 🔀 Call specification generic list, get, insert, submit, report, print: no business vocabulary 9 · 🏢 Executed in the ERP by the app, as the signed-in user permissions, validations, workflow apply 10 · ↩️ Result returns turn resumes; more calls may follow, bounded; analyses computed by the engine 11 · 🖥️ Rendered text, table, cards, chart, PDF, or the ERP's own refusal message 12 · 📊 Logged prompt, modules, tools, gates, tokens, latency; feedback later 🔁 Loop back to step 5 with each result, until an answer is ready ✋ Confirmation exact values shown; the person confirms, then step 8 runs ⚡ Cache hit answer returned still logged as a turn 🔍 Review loop fixes made once improve steps 3 to 7 for everyone 💬 Follow-up carries the turn id, continues with memory of what was shown Steps 7 and 9 are two independent permission checks: the agent's tool grant, then the ERP's own. Nothing reaches the ERP that the gateway refused, and nothing the ERP refused is hidden.

What this shows: two independent permission checks (the agent's tool grant at the gateway, then the ERP's own permissions), a write that always stops for confirmation, results that loop back until the answer is complete, and a log that feeds the shared review loop. A follow-up continues the same turn with its memory.

Back to the diagram list

5 of 9

LLM analysis + Local Analytics Engine

How precise analysis is produced: the language model reasons about the question and the result, and the local analytics engine computes every number, forecast and anomaly in Python.

LLM analysis + Local Analytics Engine = precise analysis 1 · THE QUESTION 💬 "How will sales go next quarter, and which customers are slipping?" asked in the ERP chat, by a person with access to sales data 2 · LLM ANALYSIS · DECIDES WHAT TO COMPUTE 🧠 Understand intent sales trend + forecast + customer decline period: next quarter 📚 analytics.catalog 100 standard analyses in 12 categories found by name and purpose 🎯 Choose and set up sales forecast, customer trend period, company, filters asks if the request is unclear ▶️ analytics.build or compare_periods / compare_segments analysis key and parameters only no data in the request request 3 · NOVIZ ANALYTICS ENGINE (LOCAL) · COMPUTES IT EXACTLY 🔌 Datasets from the ERP the relay pulls each dataset the analysis needs through the ERP app, as the signed-in user complete period, paged; rows stay server-side 📐 Data contract → Python service fixed columns per dataset (date, party, item, amount, quantity); every ERP maps to them posted to the private analytics service 🐍 Compute (pandas, NumPy, SciPy) periods, growth, ageing, top-N, ABC, concentration forecast: Holt damped trend + regression, 80% range anomalies: robust z-score; change point: Welch t-test 🧾 Analytical layer and render KPIs vs prior period, observations, watch-outs, recommendations; charts (matplotlib), dashboard, PDF; the model gets only summary + KPIs 4 · WHAT THE ENGINE RETURNS 📊 Dashboard KPI tiles and charts straight into the chat 📄 PDF report same analysis, download link with a short expiry 🧮 Summary + KPIs the only part the model reads: a few hundred tokens 📈 Forecast next periods, 80% range trend and seasonality ⚠️ Anomalies outlying periods and change points flagged 5 · LLM ANALYSIS AGAIN · EXPLAINS, NEVER RECALCULATES 💬 Explains "Sales are forecast to rise 6 to 9%; three customers are down over 30% against last quarter." 🔁 Follow-ups "why?" → drill-down analysis "show by region" → new build same engine, same rules ➡️ Next steps suggest a related analysis or an action in the ERP confirmed by the person ANALYSIS CATALOGUE · 100 STANDARD ANALYSES IN 12 CATEGORIES Sales Customers Purchasing Suppliers Inventory Production Projects Finance Cash flow Profitability HR Executive Every analysis can add a forecast, anomalies and a change point to its trend, and can be compared across two periods or two segments. PURPOSE · WHAT THE ENGINE PREDICTS AND SOLVES 💰 Financial results profit and loss, gross and net profit margins, budget vs actual next periods forecast, 80% range 💵 Cash flow cash position, inflow, outflow working capital receivables and payables ageing 📦 Stock flow balance, valuation, turnover stock ageing, dead and slow stock reorder needs, ABC classes 🧩 Complex business issues customers slipping, suppliers late margin lost by item or customer where and when a change started 🏭 Operations and people production efficiency, wastage workstation use, project budgets payroll cost, turnover 🧭 Executive view business KPI dashboard overall business health executive summary with watch-outs WHY THE WORK IS SPLIT THIS WAY Precise every number computed in code over the complete data Reproducible same data, same parameters, same result, every time Permission-safe data fetched as the user; nothing they cannot see Cheap the model reads a summary, never thousands of rows Honest charts and tables are drawn from engine output, not prose The model is good at understanding questions and explaining results; it is not reliable at arithmetic over many rows. So it chooses and explains, and the engine computes. Self-hosted: the open-source agent includes a Python engine sample (monthly trend with a projection) that runs the same way, as a local process.

What this shows: a clear division of work. The model understands the question, picks one of 100 standard analyses and sets its parameters; the relay pulls the complete data through the ERP as the user, and the Python engine computes the analysis exactly (aggregation, period and segment comparison, forecasting with a range, anomaly and change-point detection) and returns a dashboard, a PDF and a compact summary. The rows never reach the model, so the numbers are exact, reproducible and cheap, and the model is left to do what it does well: explain, answer follow-ups and suggest the next step.

Back to the diagram list

6 of 9

Permissions and agent roles

Six gates every request passes, the roles the agent plays, and who administers what.

EVERY REQUEST PASSES SIX GATES, IN ORDER 1 · Organisation API key resolves one organisation paid term active, token budget tier: read-only or read and write 2 · Person the signed-in ERP user their real ERP roles sent by the ERP, not typed 3 · Role allowance ERP roles → permitted tools a sales user never sees payroll tier × role, neither widens 4 · Tool filtering only relevant permitted tools offered for this request discovery stays inside the grant 5 · Gateway the only path to any tool unknown or denied = rejected writes become a proposal 6 · The ERP role and user permissions validations, closed periods the approval workflow ✅ Result or refusal passed through unchanged the ERP's own message shown to the person ✋ Confirmation exact document and values person approves or cancels then the write runs AGENT ROLES · ONE ENGINE, DIFFERENT TOOLS 🧑‍💼 Operations agent every permitted user read, create, update, submit within that user's roles 🔁 Workflow (AutoFlow) follows the ERP's own workflow next document in the chain approvals stay with approvers 📷 Document intake scan → structured draft party and items matched nothing posted unconfirmed 📈 Analytics (LLM + engine) LLM chooses and explains Noviz Analytics Engine computes KPIs, forecasts, anomalies, exact 📥 Inbox email and notifications reply, mark read, act through the same gateway 🎯 Specialists collections, reorder, month-end close own goals, same gates ROADMAP WHO ADMINISTERS WHAT Organisation admin in their own ERP: relay key, module policies, email, access role grants the Noviz AI role to users ERP administrator roles, user permissions, workflows, validations the agent obeys them unchanged Noviz platform admin organisations, terms, budgets model provider settings review loop across organisations GUARANTEES No credential leaves the ERP the plugin executes calls inside the user's own session No privilege escalation tier and role only narrow; the agent has no role of its own No silent change every write is shown first and confirmed by the person Truthful errors an ERP refusal is shown as the ERP returned it Native audit trail documents show the real user as owner in ERP history Full interaction log prompt, tools, gate decisions, tokens and latency per turn Mailbox protection mail is read, never deleted or moved by the agent Cost and abuse limits rate limits, token gate, monthly budget per organisation The agent never holds more access than the person using it: each gate can only remove options, and the last word always belongs to the ERP. Specialist agents are instances of the same engine with their own tool set and prompt layer; they pass the same six gates under a named service user.

What this shows: the agent never holds more access than the person using it. Each gate can only remove options; the ERP has the last word. Every agent role (operations, workflow, document intake, analytics, inbox, and the specialist agents on the roadmap) is the same engine with a different tool set, behind the same gates.

Back to the diagram list

7 of 9

Business workflow

How the agent walks the ERP's own document chains and approval workflows, step by step, without adding or skipping anything.

ORDER TO CASH · EACH DOCUMENT CREATED FROM THE ONE BEFORE Lead prospect from email or web Opportunity qualified need value, probability Quotation priced offer valid until Sales Order confirmed order to deliver and bill Delivery Note goods leave stock reduced Sales Invoice revenue, receivable due date Payment Entry money received invoice settled PROCURE TO PAY Material Request internal need or reorder level Request for Quotation sent to suppliers Supplier Quotation offers compared Purchase Order often needs approval Purchase Receipt goods in stock increased Purchase Invoice payable supplier bill Payment Entry supplier paid Standard ERPNext chains only. The agent follows whatever chain and approval workflow the organisation has configured; it adds no steps and no rules of its own. AT EVERY STEP 1 · Read the state the document, its status and workflow state, live workflow.describe as the user 2 · Propose the next document, created from its source (keeps links and progress tracking) 3 · Confirm exact values shown the person approves or changes the proposal 4 · ERP validates mandatory fields, stock, credit limit, closed periods refusal passed through 5 · Approve approval workflow applies approver acts in the ERP or via the agent with the role 6 · Report back result in the chat notification to the inbox next step offered If the ERP refuses at step 4 or 5, the agent shows the ERP's own message and offers what the ERP allows next (fix the field, request approval, choose another warehouse). Steps 3 and 5 are different people when the organisation's workflow says so: the agent never approves on behalf of someone who lacks the approver role. Every step is a normal ERP transaction under the person's own session, so ERP history shows who did what, exactly as without the agent. Example: "Convert quotation SAL-QTN-0042 to a sales order" → read quotation → propose sales order → confirm → ERP validates → workflow: Pending Approval → Sales Manager approves → submitted. APPROVAL WORKFLOW · CONFIGURED IN THE ERP, READ LIVE BY THE AGENT Draft saved, editable no ledger effect Pending Approval waiting for the approver role Approved submitted ledgers posted Rejected returned with a reason Cancelled reversing entries kept for audit Amended new draft copy corrected, resubmitted submit approve cancel amend reject Who may move each state is the ERP's role setting; the agent reads it and offers only the actions open to this person. AUTOMATION THAT RUNS THE SAME WAY 🔁 AutoFlow the next document in the chain suggested after each step one click, still confirmed 📥 Inbox to transaction a customer email or a scan becomes a draft document reviewed before saving 🔔 Notifications approvals waiting, overdue invoices, low stock as cards with actions 🎯 Specialist agents collections, reorder, month-end close same steps, same gates ROADMAP Workflow knowledge comes from two places: the knowledge base explains how a chain normally works, and the live ERP workflow shows what is true for this document now. The ERP remains the system of record for every state change; the agent makes the chain faster to walk, never shorter than the organisation configured it.

What this shows: each next document is created from its source so the ERP keeps its links and progress; the person confirms every step; the ERP validates and applies the organisation's approval workflow; approvers keep their role. The agent makes the chain faster to walk, never shorter than the organisation configured it.

Back to the diagram list

8 of 9

Knowledge and RAG

How the agent learns what documents mean and what normally happens next, from ERP process documentation, company policies and the live workflow.

1 · KNOWLEDGE SOURCES 📘 ERP process documentation order to cash, procure to pay, stock, manufacturing, close, document lifecycle 📜 Company policies and SOPs uploaded by the organisation admin (PDF, Word) versioned, can be deactivated 📎 Reference documents contracts, price agreements, product and service manuals per organisation 🔁 Live ERP workflows states, transitions, roles read at request time never copied or stored 2 · INGESTION PIPELINE (ON UPLOAD OR CHANGE) Parse PDF, Word, Markdown metadata: title, module Chunk by section heading overlap on long sections Label title > section kept with every chunk Embed embeddings model separate key and quota Store pgvector, per organisation linked to its source ♻️ Lifecycle checksum: unchanged = skipped edit = re-index that source deactivate or delete = its chunks removed 3 · RETRIEVAL AT REQUEST TIME Request "Why can't I submit this purchase order?" + person, roles, organisation Module router keywords → buying same router as tools and prompt sections Warm context closest passages added within a fixed budget no extra model step knowledge.search the model asks on demand filtered by module returns cited passages workflow.describe live from the ERP, as the user current state actions allowed now Filters on every retrieval: this organisation only · active sources only · module scope · ERP data is never retrieved from vectors, it is read live through tools with the person's permissions. Workflow state comes from the ERP at the moment of the request, so a change to the approval process is reflected immediately with no re-indexing. 4 · REASONING AND ANSWER 🧠 Model reasons knowledge explains the process live workflow shows the state tools fetch the document 💬 Answer with sources "This order is Pending Approval; Purchase Manager approves." source: Procure to Pay 🏛️ ERP stays the authority no rule is decided by text submitting still runs the ERP's validations and workflow DESIGN RULES Meaning, not data documents explain how processes work; records are read live No business rules limits and approvals live in the ERP, never in documents Isolated per organisation one organisation's documents never reach another's answers Cited every passage carries its source title Cheap by design section chunks, checksums, budgeted context Same vector space policies, knowledge and the semantic cache One service, many products ERPNext, Business Central, CRM use the same knowledge API Open source too the self-hosted agent ships the same design Knowledge tells the agent what a document means and what normally happens next; the live workflow tells it what is true for this document now; the ERP decides.

What this shows: documents are chunked by section, labelled, embedded and stored per organisation; at request time the closest passages arrive as context or on demand through knowledge.search, and workflow.describe reads the live state from the ERP as the user. Knowledge explains meaning; business data is always read live, and the ERP decides.

Back to the diagram list

9 of 9

Administration and review

Who sets up what: purchase and keys, the organisation's admin inside the ERP, the Noviz platform admin, and the review loop that improves every organisation at once.

1 · PURCHASE OR TRIAL 👤 noviz.in account one account for all products email verified 💳 Checkout plan and term secure payment 🔑 Key issued organisation created key emailed with invoice ♻️ Renewal same key, new term no reconfiguration 🚀 Trials ERP, ERP Premium, CRM own site in minutes 2 · THE ORGANISATION'S ADMIN, INSIDE THEIR OWN ERP ⚙️ Connect paste the relay key turn the agent on base URL set automatically 👥 Give access grant the Noviz AI role to chosen users ERP roles still decide data 📧 Email mail account for the inbox read without modification replies sent as the user 📜 Policies module policies in plain text policy documents uploaded for this organisation only 🔁 Workflows approval workflows configured in the ERP read live by the agent 3 · THE NOVIZ PLATFORM ADMIN 🏢 Organisations create, suspend, renew terms and access level read-only or read-write 📅 Budgets monthly token budget per organisation usage per day and month 🤖 Model settings provider, model, key reasoning, vision, embeddings switch in seconds, no deploy 📈 Usage and billing tokens per organisation invoices, one counter payments reconciled 4 · REVIEW AND IMPROVE, ACROSS EVERY ORGANISATION 🚩 Flagged negative feedback, blocked or warned gates, slow or failed turns 🔍 Diagnosed read the logged turn: prompt, tools, results root cause, not symptom 🛠️ Fixed once prompt layer, module config, tool or guard full test suite 🚢 Deployed exactly what is in main health check, rollback Same shared relay Organisations and auth · turn state · prompt system · tool filtering · reasoning loop · gateway · translator · dispatcher Configuration and policies are data the relay re-reads on the next request: no restart and no redeploy for flows 1 to 3. Flow 4 means every organisation arrives at the relay a little sharper each release. SEPARATION OF DUTIES Organisation admin connection, users, email, policies, workflows never sees other organisations ERP administrator roles, user permissions validations, approval rules the agent obeys them Noviz platform admin organisations, budgets, models, review loop never sees ERP data No ERP credential is ever given to Noviz: the key identifies the organisation; every data call runs inside the ERP as the person who asked.

What this shows: separation of duties. Organisations configure their own connection, users, email, policies and workflows; the platform admin manages organisations, budgets and models and never sees ERP data; flagged turns from any organisation are fixed once, centrally, and reach everyone on the next release.

Back to the diagram list

Go deeper

The guide How to build an enterprise AI agent explains each part with code from our open-source agent, including why we built our own engine instead of using LangChain.