Over the past two years many companies have tried an “AI assistant”: connect a large language model, feed it a pile of policy documents, let employees ask a few questions — and within weeks nobody uses it. The cause is rarely that the model is not smart enough. It is that the assistant can talk but cannot act: it cannot see live inventory, cannot create a work order, cannot move a delivery date. It ends up as an expensive search box.
Making an agent part of a real business process is not primarily a prompt-engineering problem. It is a systems integration problem: expose ERP, MES, WMS, and CRM capabilities as tools the agent can call safely, and design permissions, idempotency, auditing, and human confirmation around them. This article lays out an architecture and a rollout path that works in practice.
1. Why a chat-capable agent fails inside a company
Three patterns show up in almost every failed pilot:
- The data is stale. The knowledge base holds an inventory export from last week, so nobody dares trust the answer.
- The output has no exit. The agent says “consider delaying this order by three days”, but there is no button that submits it to the ERP. The employee still clicks through the system manually.
- Permissions were never defined. The moment an agent touches production systems, IT worries about a shared account reading or writing data out of scope — so the whole thing gets blocked.
The goal of integration is therefore not “teach the model the business”. It is to let the model invoke deterministic business capabilities inside a controlled boundary.
2. Four integration patterns, from low to high risk
Do not start with write operations. A reliable sequence is read-only first, then controlled writes, then event-driven automation — with separate acceptance for each level.
| Pattern | What it does | Risk | When to use |
|---|---|---|---|
| 1. Read-only query | Inventory, order status, lead time, BOM, customer credit limit | Low (data leakage possible) | Must-have in phase one |
| 2. Controlled write | Create draft work orders, submit purchase requisitions, draft quotations | Medium (needs idempotency and rollback) | Phase two |
| 3. Event-driven | Auto-create tickets on quality exceptions; suggest replenishment below threshold | Medium-high (needs throttling and dedup) | Phase three |
| 4. Human-in-the-loop | Agent proposes an action → manager approves in WeCom/DingTalk/Slack → system executes | Controlled (a human stays in the loop) | Parallel with 2 and 3 |
In practice, patterns 2 and 3 must always pair with pattern 4: any write that touches money, inventory, or delivery dates needs a human approval step. This is not a technical limitation; it is how organisational trust gets built.
3. Reference architecture: four layers
3.1 Access layer
Employees ask questions through WeCom, DingTalk, Slack/Teams, a web portal, or an embedded ERP page. This layer handles identity (SSO), session context, and routing to the orchestration service. It must align with the corporate directory, because every downstream permission decision depends on it.
3.2 Orchestration layer
Responsible for intent detection, tool selection, multi-step planning, and retries. The critical design point is defining each “tool” as a structured schema — name, description, typed parameters, required fields, response shape — instead of letting the model compose SQL or URLs freely. The model may only choose registered tools and fill in parameters, which structurally eliminates SQL injection and out-of-scope access.
3.3 Tool layer (integration adapters)
This is where the real work happens. Four common connection types:
| Connection | Typical systems | Advantages | Caveats |
|---|---|---|---|
| REST / GraphQL API | Modern ERP and in-house systems | Standard, authenticable, auditable | Watch pagination and rate limits |
| SOAP / Web services | Legacy ERP (SAP ECC, older domestic ERP) | Complete functionality | Verbose payloads; trim fields |
| Read-only database views | Legacy systems with no API | Fast and inexpensive | Strict read-only account, isolate with views, never query base tables directly |
| Staging tables / message queues | MES, WMS, shop-floor systems | Decoupled, asynchronous, resilient | Define idempotency keys and retry policy |
3.4 Data and audit layer
Record the inputs, outputs, latency, caller identity, and whether a human approved every tool invocation. This is the only basis for troubleshooting, measuring effectiveness, and passing internal audit. In manufacturing, an agent project without an audit log generally does not survive IT and compliance review.
4. Permissions and security: five hard rules
- Least-privilege service account. Give the agent a dedicated service account with only the permissions it needs; never reuse an administrator account.
- Row-level filtering implemented in code. Rules such as “a salesperson sees only their own customers’ orders” or “a supervisor sees only their own workshop’s work orders” must live in the tool layer, not in the model’s judgement.
- Idempotent writes. Every write request carries a unique idempotency key (session ID + action + timestamp) so network retries cannot create duplicate records.
- Dual approval for critical actions. Actions above an amount threshold, above an inventory adjustment limit, or that change delivery dates must go through an approval flow.
- Masking and on-premise deployment. Customer phone numbers and supplier prices should be masked before reaching the model, and the model itself should preferably run on-premise — see our private LLM deployment guide.
5. Five high-value starting scenarios
Do not build an “all-purpose assistant”. Pick one high-frequency scenario with clear boundaries and measurable benefit.
| Scenario | What the agent does | Measurable benefit |
|---|---|---|
| Inventory and lead-time lookup | Query live stock, in-transit, available quantity, committed delivery date by material or order number | 20–40 fewer phone calls per salesperson per day |
| Work order creation and reporting | Turn a spoken request into a standard draft work order; human confirms, then write to MES | Creation time from 10 minutes to 2 |
| Quality exception closure | Photo plus description → link the batch, create a nonconformance record, notify the owner | Response time cut by ~50% |
| Procurement comparison | Aggregate historical purchase prices and supplier quotes; produce a comparison sheet and requisition draft | Preparation from half a day to 20 minutes |
| Daily operations report | Aggregate output, yield, delivery attainment, open exceptions into a plain-language summary | 30 minutes saved per manager per day |
“Quality exception closure” connects naturally to visual inspection systems. You can also try the inference quality on our online diagnostic page.
6. Rollout path and acceptance metrics
Phase 1: read-only connectivity (4–6 weeks)
Pick three to five read-only endpoints (inventory, orders, lead time, BOM) and complete identity integration, tool registration, and audit logging. Do not release it company-wide; start with ten pilot users.
Phase 2: controlled writes (4–8 weeks)
Add two write operations — draft work orders and draft requisitions — each behind human approval. Focus testing on idempotency and rollback: simulate network timeouts and check for duplicate records.
Phase 3: event-driven and expansion
Connect quality exceptions and inventory alerts, then extend to more departments.
| Metric | Definition | Target |
|---|---|---|
| Tool call success rate | Share of calls returning successfully | ≥ 98% |
| First-contact resolution | Tasks completed in a single conversation without escalation | ≥ 60% initially |
| Human takeover rate | Share requiring human confirmation or handover | 100% retained for writes |
| Average handling time | From question to task completion | At least 50% shorter than the current process |
| Unauthorised writes | Writes performed without confirmation | 0 |
7. Five common failure modes
- Writes before permissions. IT shuts the project down after the first bad write.
- Letting the model compose SQL. Neither auditable nor secure; constrain it with tool schemas.
- Assuming every legacy system has an API. Many older ERPs only allow database views; assess this early.
- No audit log. You cannot investigate incidents or demonstrate compliance.
- Chasing an all-purpose assistant. Spread too thin, none of the scenarios goes deep, and every department stops using it.
Conclusion
The value of an AI agent is not conversation. It is compressing a cross-system operation into a single sentence. Whether that sentence can be trusted depends on the integration architecture, permission design, and audit capability behind it — precisely the parts that enterprise IT has spent years building, and the parts most “AI projects” skip.
Our recommendation: prove one read-only scenario with real data, then gradually open write access. If you are evaluating an ERP/MES integration, contact us for an interface inventory and risk-tiering template.
