How to add AI agents to IFS Cloud
Short answer
Build AI agents on IFS Cloud by exposing a small set of read and propose-only tools over its OData projections, triggering them from IFS business events or schedules, and routing every write through a human approval step. Keep the model behind your own network if the data is regulated.
IFS Cloud customers in aerospace, defense, MRO, shipbuilding and heavy engineering run long, asset-centric processes: projects with work breakdown structures, serialized parts, maintenance work orders, and supply chains with long lead times. Most of the daily pain is not data entry. It is chasing exceptions across Supply Chain, Manufacturing, Maintenance and Project modules, each with its own screens in Aurena.
An AI agent is a loop: observe a trigger, call tools to gather facts from IFS, reason, and then either answer or propose an action. The value in IFS comes from agents that stitch several modules together, for example a late purchase order, the shop order it feeds, and the project milestone that depends on it.
IFS ships its own AI features, and for single-screen assistance those may be enough. A custom agent earns its place when the workflow crosses modules, uses your own documents and policies, or must run on a model you host. This page covers the architecture that works against the real IFS integration surface.
What teams use it for
Late purchase order expediting
An agent scans open purchase order lines past promised date, checks the demand they feed (shop orders, project activities), ranks by downstream impact and drafts a supplier chase for buyer approval.
Shop order shortage triage
When material is short for a released shop order, the agent finds alternates, on-hand in other sites, and incoming supply, then proposes a reallocation or an expedite for a planner to accept.
Maintenance work order planning
For a new corrective work order, the agent reads asset history, similar closed jobs and the spare parts structure, then drafts the operation list and required parts for the planner to review.
Project cost variance watch
An overnight agent compares committed and actual cost against budget per project element, explains the largest movers in plain language and posts a summary to the project controller.
Nonconformance first draft
From a receiving or shop floor report, the agent gathers part, lot, supplier and inspection context and drafts the quality record, leaving disposition to a quality engineer.
IFS Cloud integration surface
- IFS Cloud exposes business data as OData v4 projections (for example under a path like /main/ifsapplications/projection/v1/<Name>.svc). The API Explorer inside the product lists the projections available to your release and lets you test calls.
- Authentication goes through IFS IAM, which is OpenID Connect based, so an agent uses a registered service client with the client-credentials flow and its own permission set rather than a person's login.
- Business events and event actions can fire on record changes and push to IFS Connect or a message endpoint, which gives agents an event trigger instead of polling.
- Information Sources and lobby elements expose pre-joined query results that can be cheaper for an agent than stitching many projections together. Names and capabilities vary by release.
- Underneath is an Oracle database with PL/SQL _API packages. Treat direct SQL as a read-only fallback for analytics, never as the write path.
How it works
- 1
Pick one workflow and one outcome
Choose a single exception type such as late PO lines on a defined supplier class. Define what a good proposal looks like and who approves it.
- 2
Create a dedicated service client and permission set
Register a client in IFS IAM and grant a permission set limited to the projections the workflow needs. Start read-only.
- 3
Wrap projections as narrow tools
Expose tools like get_open_po_lines, get_shop_order_demand and get_supplier_history. Each returns trimmed, typed JSON, not raw OData payloads, so the model sees only relevant fields.
- 4
Choose the trigger
Use a business event for real-time exceptions or a scheduled run for sweeps. Deduplicate so one late line does not spawn ten agent runs.
- 5
Add a propose-only write layer
Agents write drafts to a review queue, with the evidence and the exact IFS call that would be made. A person approves, and only then does a separate, narrowly permitted service perform the change.
- 6
Log and evaluate
Record every tool call, prompt and decision. Replay a month of historical exceptions and compare proposals with what planners actually did before enabling live runs.
Example flows
Expedite a supplier for a project-critical part
Trigger: A purchase order line passes its promised date by two days.
- Agent reads the PO line and supplier delivery history.
- It traces demand to the shop order and the project activity it supports.
- It checks inventory at other sites for a transfer option.
- It drafts a chase message and a ranked list of options.
- The buyer approves, edits or rejects in the review queue.
Result: The buyer sees impact and options in one place instead of opening four Aurena pages.
Weekly project cost narrative
Trigger: Friday scheduled run per active project.
- Pull budget, committed and actual cost by project element.
- Compute the largest variances and their source transactions.
- Generate a short narrative with links to the underlying records.
- Send to the project controller for review.
Result: A reviewed variance note replaces a manual spreadsheet pass.
Keeping data on-prem
Many IFS Cloud estates are customer-managed or run in a private cloud because of defense, export control or data residency rules. In that setup, run the agent runtime, the tool layer and an open-weight model (a Llama, Qwen or Mistral class model served with vLLM) inside the same network zone as the IFS middle tier. The agent calls IFS projections over the internal network, so no part, drawing or supplier data leaves the boundary. Size GPUs for concurrent runs rather than peak chat, since agents make many short calls. Keep the review queue and logs in your own storage.
Security checklist
- Use a dedicated service identity per agent with the smallest permission set that works, never a shared admin account.
- Separate the read tools from the write service so a prompt cannot reach a write path directly.
- Treat text from suppliers, emails and documents as untrusted input and never let it change tool arguments without validation.
- Keep an immutable audit trail of tool calls, proposals and approvers.
- Respect IFS site and company scoping so the agent only sees data the owning team may see.
Ways to get it done
Use IFS built-in AI capabilities
Effort: Low, mostly configuration and licensing.
Single-module assistance where the vendor feature already covers the task.
Build in-house on projections plus an agent framework
Effort: Typically weeks for a pilot, longer to harden and evaluate.
Teams with integration developers and a clear first workflow.
Work with a partner such as Netray
Effort: Scoped pilot first, then expand workflow by workflow.
Regulated or on-prem estates that need private models and cross-module agents.
Pitfalls
- !Projection names and fields differ between releases, so pin tool contracts to your version and retest after each update.
- !Agents that read wide OData entities burn tokens and confuse the model, so trim fields in the tool.
- !Skipping deduplication on events floods planners with repeat proposals.
- !Letting the agent write directly to IFS because the first demo worked.
- !No replay set, so nobody can tell whether a prompt change made things better or worse.
Frequently asked questions
Can an AI agent write back into IFS Cloud?
Technically yes, through the same projections and PL/SQL-backed actions the client uses. In practice you should keep agents propose-only, queue each change with its evidence, and let a person approve it. Execute approved changes through a separate service with narrow permissions and a full audit trail.
Do we need IFS Connect for agents?
Not always. Scheduled sweeps only need the projections. For event-driven triggers you can use business events and event actions, and IFS Connect is one way to route them to an endpoint. Which mechanism you pick depends on your release and how your integration team already works.
Which model should power the agent?
Tool-calling quality matters more than raw size. For regulated data, a self-hosted open-weight model in your network is the safer default. For non-sensitive workflows a hosted frontier model can be fine. Evaluate both on your own historical exceptions before deciding.
How is this different from IFS's own AI?
Vendor AI is tuned for IFS screens and processes it knows. A custom agent can combine IFS with your documents, supplier portals, policies and a model you control. If a built-in feature solves your problem, use it and skip the custom work.
How do we start safely?
Pick one exception type, give the agent read-only access, run it silently against a month of history, and compare its proposals with what planners did. Only then show proposals to users, and only later consider approved write-back.
Want AI agents working on your IFS Cloud?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment