Enterprise AI Architecture: How Agents Connect to Your ERP, CRM, and Core Data
An AI agent that can read your CRM and write to your ERP is useful on day one and dangerous on day two. Give it a super-user account and one misread request can post a duplicate purchase order, overwrite a customer's credit limit or email a price list to the wrong account. Hold it back to read-only and it never does enough work to earn its budget. Enterprise AI architecture decides where an agent sits between those two outcomes.
The model itself is the smallest part of that decision. The work is in the layer between the agent and your systems of record: who it acts as, which fields it can touch, which decisions a fixed rule makes for it, when a person signs off, and what gets written to the log.
The five layers of an enterprise AI agent architecture
The production agents we build connect to business systems through five layers. The tools change from one stack to the next, and the boundaries between the layers do not.
- Channels. Where work arrives: a Teams or Slack message, a shared inbox, a change on a CRM record, an ERP alert or a schedule.
- Agent. A language model with instructions. It extracts the facts from the request, chooses a tool and writes the reply. It holds no database credentials and makes no final decision on money, access or customer data.
- Integration layer. Workflows and tools that make every call on the agent's behalf. This layer authenticates as the requesting user, maps fields between systems, queues and retries calls, and runs the rules and approval gate.
- Systems of record. Your ERP, CRM and warehouse. Reads go to a cache or warehouse first, and writes go back to the system that owns the record.
- Audit log. One row for every step: prompt, model version, records read, tool called, rule applied, approver and result.
The highlighted layer carries most of the risk and most of the engineering. Our enterprise context layer page covers how the same layer gives every agent one governed view of company data.
Why AI agents fail at the ERP and CRM boundary
ERP APIs were built for people typing at a desk
ERP and CRM APIs were designed around people entering records at human speed. An agent working through a backlog can fire dozens of calls a minute, hit rate limits, time out halfway through a multi-step update and leave a sales order with no lines. The integration layer absorbs that load: it queues calls, retries failures with backoff, and treats a multi-step write as one unit that either completes or rolls back and alerts someone.
Reads are the bigger load, and most of them should never reach the ERP at all. A Dutch Odoo implementation partner had spent a full year trying to build appointment scheduling natively in Odoo for a dental care group with 200 practitioners. We moved the scheduling logic out of Odoo: five sync workflows copy practitioners, locations and treatment series into a Supabase planning cache every night, and an AI agent in n8n places 1,500 appointments a week from that cache. Any appointment it cannot place lands on a report that says why. Odoo stays the system of record and never carries the planning load. The full case is on our enterprise AI consulting page.
The same customer has two names
Your CRM calls a customer an Account and your ERP calls the same company a Debtor, with a different ID, a different address format and sometimes a different legal name. An agent asked to "check whether Acme has unpaid invoices before we renew" has to join those records. Left to guess, a model will produce a confident match that is wrong, and a wrong match on a write is a wrong invoice, credit note or dunning letter.
The fix is a mapping the integration layer owns: one table that ties CRM IDs to ERP IDs, and one definition for each shared field such as customer, revenue or open balance. You do not need to rebuild either database first. You need the mapping for the fields your first workflow touches, and you extend it with each workflow after that. Our context layer blueprint describes how those definitions grow into a semantic layer.
Read before you write: a staged permission model for AI agents
Agent permissions should grow in stages, and each stage should earn the next with a measured run.
- Read. The agent answers questions and drafts summaries from a cache or warehouse. Nothing it does changes a record.
- Draft. The agent prepares the record, such as a purchase order, a CRM update or a credit note, and a person approves it before it posts.
- Write within limits. The agent posts records below a threshold the business owner sets, and everything above that threshold still goes to a person.
At every stage the agent acts as the person who asked. When a sales rep asks it to update an opportunity, the integration layer calls the CRM with that rep's permissions, so the agent can never see or change a record the rep could not. Shared service accounts with blanket access are how an agent becomes the most privileged user in the company without anyone deciding it should be.
In the example above the agent did the slow part, pulling demand history and choosing a quantity, and the procurement lead spent one click on the decision that carries the money. Below the limit, the same order would have posted on its own with the same log row.
Keep the decision out of the model
A language model predicts text, so it approximates a rule rather than executing it. Any decision with a correct answer, such as a discount ceiling, an approval threshold, a stock calculation or an access check, belongs in code or in the database, where it returns the same answer every time. The model reads the request and explains the result.
IES Limited runs four travel insurance brands from a 25-page daily MI pack. In the system we built for them, every figure is a PostgreSQL view, n8n decides who needs to know, and the language model receives finished numbers and writes the sentence around them. A drop in the quote funnel that once took 20 working days to notice now reaches the right Teams channel within 30 minutes of the pack landing. Because the thresholds live in the database, IES changed them 34 times in six weeks without a single developer ticket. The IES Daily MI case study walks through the build, and mapping business rules into the context layer shows how to store rules as versioned records an agent can query.
AI agent security: insiders, injected prompts and least privilege
An agent with access to your ERP is a new privileged identity, and it inherits every way a privileged identity can be abused. CISA's Insider Threat Mitigation Guide (September 2026) names the AI-specific cases directly: insiders with access to internal data stores can poison training data, alter a deployed model's parameters "to favor fraudulent transactions or misclassify sensitive documents", or expose sensitive data by entering it into an AI system that is not approved to hold it.
The architecture answers each of these with controls you can test:
- Each agent gets its own credentials, stored in a secrets vault and revocable in one step, so a suspicious agent can be cut off without stopping every workflow.
- Instructions, rules and model versions are versioned and changed through review, so nobody edits a live system prompt by hand.
- Text that arrives from outside, such as an email body or a supplier PDF, is treated as data. It can inform a draft, and it cannot trigger a write on its own.
- Staff reach AI through sanctioned tools that run inside your environment, which removes the reason to paste customer data into a public chatbot.
Our enterprise AI governance page sets out the policy side of these controls, and the n8n consultant page covers how we review and harden workflows that are already running.
What to log for every agent action
When an agent does something wrong, your team needs to reconstruct why: a prompt injection, a wrong record retrieved, a rule out of date or a model that misread the request. CISA's Logging Reference Architecture (August 2026) sets the bar for AI systems: organisations "should log user prompts, system prompts, model outputs, and other parameters used when interacting with an AI model, as well as the decisions and actions taken by AI agents and any interactions with external functions or components." It also calls for model versions and lineage, and for recording non-human identities before short-lived infrastructure recycles them.
In practice that is one log row per step with these fields:
- Timestamp, the requesting user and the agent's own identity
- System prompt version, model name and model version
- IDs of every record read and every record written
- Tool or workflow called, with inputs and outputs
- Rule ID and version applied, with the verdict
- Approver and approval time, where a person signed off
Send those rows to the SIEM your security team already uses, and keep them in storage that cannot be edited after the fact. A log that records only "agent queried ERP" cannot tell you whether a specific customer record was touched in a specific window. Keeping that logging and alerting running after launch is part of our AI managed services.
Where MCP and n8n fit in the integration layer
The Model Context Protocol, which Anthropic released as an open standard in November 2024, gives agents one way to discover and call tools. You describe a tool once, for example "look up open invoices for a customer", and any MCP-capable agent can call it. That makes tools reusable across agents, and it puts each tool's permissions and logging in one place.
MCP is the interface, and something still has to do the work behind it. We use n8n for that work: authenticating to SAP, Odoo, Salesforce or HubSpot, transforming fields, queuing calls, retrying failures and posting approval cards. Self-hosted n8n runs inside your own cloud, so customer records do not pass through a third-party automation platform. Ovidius is an n8n Select Partner, and n8n for enterprise covers deployment, scaling and the plan choices. If you are still choosing a platform, our AI agent platform comparison sets eight of them side by side.
Start with one workflow and grow the foundation from it
The architecture-first plan says to consolidate every source, standardise every schema and then deploy the first use case. Run that way, a project can spend a year or more before anyone sees an agent do useful work.
The faster path builds the five layers for one workflow and lets them grow:
- Pick the workflow. Choose one with a measurable cost today, such as order triage, invoice matching, field-service scheduling or procurement approvals.
- Measure the baseline. Record hours per week, error rate and time to completion before anything is built.
- Build the layers it needs. Map only the fields it touches, give it read access first, and put its rules and approvals in the gate.
- Run it in draft mode. Let people approve every write until the numbers show where a limit is safe.
- Reuse the foundation. The next workflow inherits the same identity model, log format and mappings, so it ships faster than the first.
Our AI Audit ranks your candidate workflows by return and feasibility and ends in a 90-day roadmap. If you want a quick sense of where you stand first, the AI readiness scorecard takes a few minutes, and the AI agent cost estimator prices the running cost of an agent before you build one.
Frequently Asked Questions About Enterprise AI Architecture
What is enterprise AI architecture?
Enterprise AI architecture is the design that connects AI models and agents to a company's systems, data and people. It covers where requests come from, which identity the agent acts as, how it reads and writes records, which decisions fixed rules make, when a person approves, and what is logged.
How do AI agents connect to an ERP like SAP or Odoo?
They connect through an integration layer, never with direct database access. Workflows in a tool such as n8n call the ERP's API as the requesting user, map fields, queue and retry calls, and run approval rules. Reads usually go to a synced cache or warehouse so the ERP is not overloaded.
Should an AI agent have write access to our CRM?
It can, within limits. Start with read access, move to drafts that a person approves, and allow direct writes only below thresholds the record owner sets, with every write logged against a rule and a user.
Do we need to clean all our data before deploying AI agents?
No. You need clean definitions and ID mappings for the fields the first workflow uses. Each new workflow extends the mapping, which is how the data foundation improves without a separate multi-year project.
What should we log when an AI agent acts in production?
Log the prompt, system prompt version, model version, records read and written, tools called, rule and version applied, approver and result for every step, and send it to your SIEM. CISA's Logging Reference Architecture (August 2026) says organisations should log prompts, model outputs and agent actions for AI systems.
Map the first workflow your agents should run
In a 30-minute discovery call you speak directly with an engineer about the workflow, the systems it touches and the approvals it needs. If an audit is the right first step, we will tell you and scope it on the call. How we work shows what happens after that.
Sources
- Cybersecurity and Infrastructure Security Agency (August 2026). Logging Reference Architecture (LRA).
- Cybersecurity and Infrastructure Security Agency (September 2026). Insider Threat Mitigation Guide.
- Anthropic (November 2024). Introducing the Model Context Protocol.