# How to add AI agents to DELMIAworks (IQMS)

> Source: https://netray.co/integrations/delmiaworks-ai-agents
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## Short answer

Put an agent runtime beside DELMIAworks, give it a small set of read tools over the Oracle schema or the vendor API, and route every write through a human approval step. Start with exception triage and expediting, where the agent drafts and a planner confirms. Models can run on your own GPUs so plant data never leaves the building.

## System

DELMIAworks (IQMS)

## Capability

ai-agents

## Intro

DELMIAworks, long known as IQMS EnterpriseIQ, is a plastics, automotive-supplier and discrete manufacturing ERP with a built-in RealTime MES. Many plants still run it on-premises on an Oracle database, with presses, molds, work orders and shop-floor data all sitting in one schema. That single-schema design is a gift for an agent: almost everything an expediter or planner looks at lives in tables the agent can query.

The pain is the same on every floor. A planner opens a dozen screens to work out why a work order will miss its date, a buyer chases late POs by email, and a quality engineer rebuilds the history of a lot by hand. An AI agent is a worker that does the looking, reasoning and drafting, then hands a finished proposal to a person.

This page covers how to build that safely against DELMIAworks specifically, including what to do when the only supported write path is the application itself and not the database.

## Use Cases

### Late work order triage

**Description:** Each morning the agent scans open work orders against due dates, material availability and press load, then writes a ranked list with the likely cause for each slip: missing resin, a mold down for repair, or a scheduling collision.

### PO expediting

**Description:** For purchase orders past promise date, the agent reads the PO lines and supplier history, drafts a chase email in the buyer's voice, and queues it for one-click send.

### Scrap and downtime explanation

**Description:** Given a press and a shift, the agent pulls RealTime MES production counts, scrap codes and downtime reasons and explains in plain words what drove the gap to plan.

### Quote-to-order checking

**Description:** When a sales order is entered, the agent checks price, lead time and material coverage against the item master and flags lines that look wrong before release.

### Lot genealogy summaries

**Description:** On a customer complaint the agent traces a finished lot back to resin lots and forward to shipments, then drafts the containment summary for the quality engineer.

### Inventory reconciliation hints

**Description:** The agent compares book inventory with recent transactions and cycle counts and proposes the three most likely explanations for a variance.

## System Surface

Oracle database: the core schema holds inventory (commonly ARINVT), customers (ARCUSTO), sales orders (ORDERS, ORD_DETAIL), purchasing (PO, PO_DETAIL) and WORKORDER. Table names vary by version, so confirm against your data dictionary before writing tools.

Read-only database user: a dedicated Oracle account with SELECT on a curated set of tables or views is the safest read path for an on-prem agent.

Vendor REST API: recent DELMIAworks releases expose web service endpoints for common objects. Availability and coverage depend on version and license, so ask your account contact which endpoints you own.

RealTime MES data: production counts, cycle data and downtime events are stored in the same Oracle instance and can be read as time series for press and work center analysis.

Reports and exports: scheduled reports and CSV or Excel exports are a low-risk fallback feed when direct database access is not allowed by policy.

## How It Works

### Pick two read-only jobs

**Detail:** Choose workflows where a wrong answer costs nothing, such as late work order triage and PO expediting. Resist wiring write access in the first release.

### Build a curated read layer

**Detail:** Create Oracle views with friendly column names and row filters (open orders only, current plant) and grant a read-only account on those views. The agent never sees raw tables.

### Define tools, not SQL

**Detail:** Expose functions like get_open_workorders(plant, date_range) and get_po_status(po_number). The model calls tools, and your code runs fixed, parameterized queries.

### Add an agent loop with limits

**Detail:** Use a framework that supports tool calling with a step cap, a token budget and a timeout per run. Log every tool call and result.

### Route writes through approval

**Detail:** When the agent wants to change a date or send an email, it creates a proposal record. A named user approves it, and the change is made through the application or its supported API under that user's identity.

### Evaluate on history

**Detail:** Replay last quarter's late orders and check whether the agent's diagnosis matches what planners actually found. Fix the tools before touching the prompt.

### Roll out per role

**Detail:** Give planners the triage agent first, then buyers the expediting agent, each with role-appropriate data scope.

## Example Flows

### Morning late-order triage

**Trigger:** Scheduled run at 6:00 for each plant.

**Steps:**

- Agent calls get_open_workorders and filters to orders due within five days.
- For each, it calls get_material_coverage and get_press_schedule.
- It classifies the cause: material short, mold unavailable, or capacity.
- It drafts a one-line action per order and groups by owner.

**Result:** Planners open a ranked list with causes and suggested actions instead of hunting through screens.

### Supplier chase draft

**Trigger:** A PO line passes its promise date by two days.

**Steps:**

- Agent reads the PO line, item, quantity and previous delivery history for that supplier.
- It checks whether the late item blocks a work order this week.
- It drafts an email with the exact PO and line, urgency stated, and a question about ship date.
- The buyer reviews and sends.

**Result:** Chases are consistent and prioritized by real production impact.

## On Prem

DELMIAworks is frequently deployed on-premises with Oracle, and the agent should follow suit. Run the model server (vLLM or Ollama with an open-weight model such as Llama, Qwen or gpt-oss class) on a GPU host inside the same network segment as the database, expose only the tool layer to the model, and keep logs local. The model never needs internet access. If you use a cloud DELMIAworks tenant, you may be limited to the vendor API, in which case run the agent in a private cloud or VPC and treat the API as the only data path.

## Security

- Use a read-only Oracle account scoped to views, never the application owner schema.
- Make every write a proposal with a named approver, and perform it as that user so ERP audit trails stay truthful.
- Log prompts, tool calls, query text and results to storage the plant controls.
- Mask or exclude customer pricing and cost fields from roles that should not see them.
- Block outbound network from the model host to enforce the air gap.

## Options

### Vendor tooling

**Fit:** Check whether your DELMIAworks release includes built-in AI or alerting features. If it covers triage and notifications, it may be enough.

**Effort:** Days to configure, limited flexibility.

### Build in-house

**Fit:** Teams with an Oracle DBA and a Python developer can build the read layer and a small agent in a focused project.

**Effort:** Several weeks for a first read-only agent.

### Partner such as Netray

**Fit:** Useful when you need on-prem models, approval workflows and evaluation harnesses without hiring for them.

**Effort:** Typically a few weeks to a pilot, depending on scope.

## Pitfalls

- Letting the agent write SQL freely against production tables. Use fixed tools.
- Writing directly to Oracle tables to update orders. This bypasses application logic and can corrupt related records.
- Ignoring custom fields and plant-specific user-defined columns that planners rely on.
- Skipping evaluation, so a confident but wrong diagnosis erodes trust in week one.
- Running heavy queries during shift change and slowing the live system. Use views, indexes and off-peak schedules.

## Faq

### Can an AI agent write back to DELMIAworks?

**Answer:** Yes, but do it through the application or a supported API under an approving user's identity, not by updating Oracle tables directly. Direct table writes skip business rules and can leave related records inconsistent. Start read-only and add writes one narrow action at a time.

### Do I need the cloud version of DELMIAworks?

**Answer:** No. Agents work well against on-premises installations by reading a curated set of database views. The cloud tenant simply narrows you to the vendor API, which still supports many read and write tasks.

### Which model should I use?

**Answer:** For on-prem work, a mid-size open-weight model that handles tool calling is usually enough for triage and drafting. Test two or three on your own historical orders and pick the smallest one that diagnoses correctly.

### How is this different from a report?

**Answer:** A report shows data you already knew to ask for. An agent investigates across several tables, forms a hypothesis about why an order is late, and proposes an action. It still shows its queries so a planner can verify.

### How long does a first version take?

**Answer:** A read-only triage agent with a handful of tools can often be piloted in a few weeks if database access is granted quickly. Evaluation and approval workflow design usually take longer than the model work.

## Search terms

delmiaworks ai agents, iqms ai agents, ai agent for delmiaworks, iqms enterpriseiq ai, delmiaworks automation ai, add ai to iqms erp, delmiaworks work order ai, on-prem ai agent iqms, delmiaworks po expediting ai

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json