Every tool that makes customisation easier makes scope easier too. In AinosERP, customisation can happen in three separate layers: screen, business rule and agent execution. Defining those layers separately is the only way to keep project scope measurable. This article covers the layers and, in particular, how a record produced by the AI agent should be governed.
Three customisation layers
- Visual Designer — the screen layer. The vendor states that a drag-and-drop screen designer and pre-built components allow instant publishing. No code is written in this layer; layout, fields and flow are defined.
- NOS — the business rule layer. The vendor's platform-specific business rule language. Conditions, loops and data operations are written here. This is where the behaviour behind the screen is decided.
- The agent — the execution layer. The vendor states that the agent plans the task itself, navigates between screens and executes with the user's approval. Natural language questions and process analysis are stated as supported.
These three carry different risks. A screen customisation can be reverted; a business rule customisation affects data; agent execution produces records.
The screen layer: the thin line between ease and scope
Drag-and-drop screen design lowers customisation cost noticeably. Its risk is that the customisation goes unrecorded: because no code was written, it does not count as "development" and never reaches documentation.
The rule that works in practice is this: a screen customisation is a change record too. Who changed which screen, when, and on whose request — without those four fields, six months later nobody knows why the screen looks the way it does.
The business rule layer: NOS
NOS is a platform-specific language in which business rules are written. The example syntax the vendor publishes shows conditions and loops operating over a record set.
The questions to ask in the business rule layer are product independent and the same in every ERP:
- Where does the rule run: on the screen, at save time, or in the background?
- If two rules touch the same record, which runs first?
- Is the rule text versioned? Which rule version was a past record calculated with?
- When a rule changes, is a closed period recalculated?
The last two are critical on the finance and costing side; an unversioned rule silently changes closed-period reports.
The agent layer: AI that produces records
This is the new layer and the one demanding most care. The vendor states the agent executes with approval. In every scenario where an agent can perform an action that becomes a financial or operational record, a verification and authorisation mechanism must be designed separately.
This approach matches our general stance on the ERP side: we do not put AI in place of verifiable business rules in auditable finance, inventory and cost records. We use it under control in suitable scenarios — document classification, statement description parsing, anomaly detection and decision support are examples. The detail is on our ERP consulting page.
Three numbers that keep customisation measurable
- The number of screens customised with the visual designer.
- The number of business rules written in NOS.
- The number of transaction types the agent can execute without approval.
The third is the most critical and grows quietly over time: every "let the agent do that too" request increases it by one. When the number is not tracked, an expansion of authority nobody consciously granted takes place.
We cover the product's module structure and single data model in what is AinosERP, and the method of tying the customisation decision back to the fit-gap table in the ERP selection guide.
Frequently asked questions
Should customisation done without code also be documented?
Yes. The purpose of documentation is not the code but the traceability of the decision. A screen change made by drag-and-drop is a decision too, and six months later its rationale will be asked about.
Can an AI agent create an accounting entry?
That it is technically possible does not mean it is operationally right. For every agent action that becomes a financial record, a threshold, an approval, a reversal path and an audit trail must be defined. Without those four, we do not recommend wiring the agent into the financial flow.
Does a platform-specific language like NOS create lock-in?
It creates some; that is true of every ERP that ships its development platform with the product. What manages the lock-in is not the language but documenting the rules and developing key users. We describe the same discipline in customisation in CANIAS ERP.
Why does the difference between an agent suggesting and executing matter?
A suggestion can be discarded; an execution leaves a record. An agent running in suggestion mode is low risk; an agent running in execution mode becomes part of the authorisation model and must be designed as such.