At a Glance — Where an AI Agent’s Logic Lives
- System of record: the ERP, where a business fact is authoritative (ledger, inventory, approvals, master data)
- System of action: whatever reads those facts and acts on them. With AI agents, the open question is where the decision logic runs
- Three options: inside the ERP, in the AI client, or in the integration layer between them
- Our recommendation: reasoning in the model, records in the ERP, and the integration layer as the control point for access, writes and logging
- Rule of thumb: agents read through narrow read-only tools and propose changes; a flow validates, gets approval where needed, and performs anything that touches money or the ledger
System of record vs system of action: the plain definitions
A system of record is the place a business fact is authoritative. In most of the projects we run, that is NetSuite: it owns the ledger, inventory, orders and approvals, and when two systems disagree, it wins. A system of action is whatever reads those facts and does something with them: routes an order, drafts a purchase order, answers a question about a customer’s balance. Until recently, that meant people, scripts and integration flows.
AI agents add a new kind of actor to that second category, one that decides what to do instead of following a fixed rule. You will also see “system of intelligence” used for a middle tier between the two. It appears in some vendor material, but it is not a standardized category, so we don’t build around it. The questions that matter are simpler: where does the agent’s logic run, what can it touch, and who can see what it did?
Three places an agent’s logic can live
Published guidance does not agree on this, and the disagreement is useful. Here are the three placements, with who argues for each:
| Where the logic runs | Who describes it | What it does well | What to watch |
|---|---|---|---|
| Inside the ERP | Microsoft describes agents operating “directly within governed Dynamics 365 workflows” (ERP Today, Jan 2026). Jade Global places decision logic “directly within your ERP and core business systems” (Jul 2025). | Same data, same permissions, same identity as the ERP itself. | Tied to one vendor’s agent tooling. A process that also touches a CRM, a 3PL or a storefront still needs integration. |
| In the AI client | A Claude project, a custom internal assistant or any MCP-compatible client that reasons and calls tools. | Flexible and model-agnostic. Fast to start. | It holds whatever access you give it, and its logs live outside your integration tooling. |
| In the integration layer | Celigo’s AI Agent step, where the model receives a structured payload at one point in a flow and returns structured output the flow acts on, and its MCP Server, which exposes defined queries to external assistants. | Scoped access, logging, rate limits and error handling in the same place you already run integrations. | You have to define the tools and the boundary. The agent is narrower than one with free-roaming access. |
These are not mutually exclusive. Most real designs use two: the model reasons in the client or in a flow step, and the ERP’s own controls still apply to every write. The choice that decides how safe the design is, is the one between the first two columns and the third: whether anything sits between the agent and the ERP that you control.
Why the integration layer is the control point
Giving an agent direct API credentials is the shortcut, and it is where most ungoverned setups go wrong. Credentials end up in the model’s context, prompts and logs; nobody can say what the AI queried until something breaks; failed calls have no governance layer to catch them; and the whole thing is owned by whoever wrote the prompt. (We cover these four failure modes in Celigo MCP Server: Governed AI Access to NetSuite.)
Putting the integration layer in the middle changes what each side can do:
- The agent never holds ERP credentials. It authenticates with a scoped token you can revoke.
- Read-only can be enforced, not requested. With Celigo’s MCP Server, read-only tokens are enforced at the MCP layer, so even a manipulated model cannot create, edit or delete records.
- The agent only reaches tools you defined. It can call “order status by order number”; it cannot improvise a query you never exposed.
- Every call is logged and rate-limited. Celigo records the timestamp, model identifier, input parameters and a response hash, in the same dashboard as your other integrations.
This does not make the design risk-free. Prompt injection through ERP free-text fields and data leaving through other tools on the same assistant are still yours to design around; we cover them in Celigo MCP Server Security and the governance basics in AI Agent Governance.
In a mid-market deployment we built, an internal AI assistant moved from a 24-hour manual NetSuite reporting cycle to real-time answers through four defined query types (inventory by SKU, order status, customer activity, and an open AP/AR summary), with no NetSuite credentials in the model context. The details are in our MCP Server article.
Which decisions go where
This is our rule of thumb, not a published standard. It sorts agent work by what could go wrong:
Reads: let the agent look, through narrow read-only tools
Inventory by SKU, order status by number, a customer’s open balance. These are reversible and low-risk, and the value is in speed. Keep each tool to one question and return only the fields the question needs.
Recommendations: let the agent propose, not apply
A suggested reorder quantity, a ticket triage, a flagged sync failure. The agent returns structured output (the item, the quantity, the reason), and the next step is a rule or a person, not the agent itself.
Writes that touch money or the ledger: the flow performs them
Journal entries, payments, price changes. An agent should not hold the pen. The integration flow validates the proposal against fixed rules, gets approval where policy requires it, and writes with a fixed mapping, the same way it would for any other source system.
A propose, validate, approve, execute pattern
- Propose. The agent returns a structured proposal, not free text.
- Validate. The flow checks it against fixed rules: allowed values, limits, required fields, does the record exist.
- Approve. A person approves anything above a threshold you set or anything that moves money.
- Execute. The flow writes to NetSuite with an idempotency key, so a retry or a redelivered message cannot apply the same change twice. Our n8n article on race conditions in agent workflows covers the claim-first fix, and the same idea applies on any platform.
The effort in a build like this is mostly the second and fourth steps, not the model. Published benchmarks we cite in AI Agent NetSuite Integration Cost put integration and QA at 40–60% of an AI agent build.
Frequently Asked Questions
What is the difference between a system of record and a system of action? A system of record is where a business fact is authoritative, such as NetSuite for the ledger, inventory and approvals. A system of action is whatever reads those facts and does something with them: routes an order, drafts a purchase order, answers a question. For AI agents the practical question is where the agent's decision logic runs and what it is allowed to touch.
Where should an AI agent's decision logic live? Entech's view: keep records in the ERP, keep the model's reasoning in the AI client or in an AI step inside a flow, and put the integration layer between them as the control point. That layer decides what the agent can read, what it can change, and what gets logged. Vendors differ: Microsoft describes agents working inside Dynamics 365 workflows, and Jade Global places decision logic in the ERP and core systems.
Is "system of intelligence" an official category? No. The term appears in some vendor material as a middle tier between system of record and system of action, but it is not a standardized category, so we don't design around it. The design questions that matter are where the logic runs, what the agent can access, and how its actions are controlled and logged.
Should an AI agent write directly to NetSuite? Not for anything that moves money or changes the ledger. Our rule of thumb: agents can read through narrow, read-only tools; for recommendations the agent proposes structured output; and the integration flow validates it, gets approval where needed, and performs the write with a fixed mapping.
How does Celigo fit into a system-of-action design? Celigo supports an AI Agent step inside a flow, where the model receives a structured payload and returns structured output the flow acts on, and an MCP Server that exposes defined queries to external AI assistants through scoped, logged, rate-limited access. Entech Solutions is a certified Celigo partner and builds both patterns for NetSuite and other systems.
Sources
- Microsoft Pitches Agentic ERP, CRM as Operating System for AI-First Enterprises (ERP Today, Tarsilla Moura, Jan 12, 2026): vendor-framed; source for the Dynamics 365 quote
- From AI Agents to Systems of Execution: Redefining Operations (Jade Global, Manoj Machiwal, Jul 24, 2025): vendor-authored; source for the “within your ERP” quote
Entech Solutions is a certified Celigo partner. We design and build AI-agent integrations for NetSuite and other systems, including the scoping, logging and approval steps above. See our AI Agents & MCP Server capability page, or talk to an integration expert.