Back to Insights
AI Agents in ERP: From Linear Projects to a Learning System
From linear process to learning system: how AI agents turn industrial project business into a loop that learns from every job.
/Herr_Dreher_500x500.jpg)
From linear process to learning system: how AI agents turn industrial project business into a loop that learns from every job.
AI × ERP series · Part 4
Part 3 showed how manufacturers train AI together without handing over raw data. Part 4 turns to the fourth lever — the process itself: how AI agents and digital twins turn the one-way street of project business into a loop, so each finished project makes the next quote sharper.
The key answer in 60 seconds
Project business thinks in straight lines — quote, deliver, close, forget. AI thinks in circles. The prize is not a smarter tool; it is an ERP that feeds each finished project back into the next one.
Every project generates exactly the data the next estimate needs — actual hours against plan, why the change orders came, which supplier slipped, what went wrong at commissioning. In a linear process that data is created once and then buried in a closed project folder. The estimator on the next bid works from memory.
AI agents, digital twins and a feedback path back into the ERP close that loop: conclusions from finished jobs become inputs to live ones, without a person re-keying them. The technology is not the hard part — the organisation and the governance are. 33+ years of consulting experience, 500+ projects, 100% vendor-independent.
"Why do we re-learn the same lessons on every project?"
A question we hear across plant engineering, special-machine building and industrial construction. The calculation that ran twelve percent over, the change order that traced back to one under-specified interface, the commissioning defect that showed up on the last three jobs of this type — each was understood, once, by the people on that project. Then the project closed, the team dispersed, and the knowledge left with them. The next bid starts from a blank sheet and a good memory.
The data was never missing. It sat in the ERP, the project files and the timesheets the whole time. What was missing is a way for it to travel forward — from a finished project into the one being estimated now.
From linear to circular: the shift project business has resisted
Project business is linear by habit: win, plan, execute, invoice, archive. Each stage hands off to the next and the project ends — cleanly, on purpose. That discipline is a strength in delivery and a weakness in learning, because the most valuable data is produced at the end, exactly when the organisation stops paying attention to it.
The shift now underway — the same circular thinking that data-space initiatives describe for industry at large — treats project data differently: it is generated, structured, and reused rather than generated and shelved. A finished project is not an endpoint but a data source for every comparable project that follows. That is a change in operating model long before it is a question of software, and it is the reason a bigger ERP alone changes nothing: a linear process digitised is still a linear process.
Three building blocks of a learning project system
In practice, three components turn a one-way process into a loop. They are worth most together, but each delivers on its own.
Block 1
AI agents that carry findings forward
An agent reads closed projects and surfaces the pattern to a live one — "this component family drives most of the change orders," "commissioning on this plant type always slips at the same step." The estimator gets the conclusion at the moment of quoting, not months later in a review.
Block 2
Digital twins of projects and plants
A living model of the asset or project, fed by as-built and operating data, so the next comparable job starts from reality rather than a blank template. The twin is where estimate, execution and field performance are reconciled — and where the gap between them becomes visible.
Block 3
Feedback that writes back into the ERP
The step that closes the loop: post-project actuals update estimating templates, standard times and bills of material inside the ERP itself. Without this, the first two blocks produce insight nobody acts on. With it, the system gets measurably better with every completed job.
None of this requires exchanging raw data with anyone outside the company — the loop runs on your own project history first. Where cooperation across companies does add value, the sovereignty rules from Part 3 apply unchanged.
The opportunity is real — so are the organisational and legal conditions
A learning project system is not a feature you switch on. It rests on three conditions that are organisational and legal before they are technical. First, the loop has to be made explicit: which data is captured at close-out, how it is structured, where it re-enters the process. Modelling it — in BPMN or a comparable notation — is what turns "we should reuse our lessons" into a process someone owns. Second is the change dimension: estimators and project leads will only trust a feedback signal they understand, so the loop has to be transparent, not a black box that quietly overrides their judgement.
Third is governance. An agent that writes back into the ERP is influencing commercial decisions, which brings it into scope of the EU AI Act. The Act is in force; under the 2026 Digital Omnibus agreement, obligations for many high-risk use cases were deferred to December 2027 — time to prepare, not a reason to ignore it. And because project data increasingly includes machine- and product-generated data, the EU Data Act (in application since September 2025) shapes who may reuse what. The rule of thumb: decide deliberately what an agent may change automatically and what it may only propose — and write that decision down.
From our project work
The problem is rarely the estimate. It is that the estimate never hears how the project actually went.
A recurring pattern in plant and special-machine engineering: each new plant is quoted almost from scratch, even when it closely resembles the last three. The actuals exist — hours, deviations, change-order causes, commissioning defects — but they live in closed project archives, not in the estimating template. So the same optimistic assumptions get made again, and the same overruns follow.
The workable path is not a bigger ERP or a full digital-twin programme on day one. In our advisory work the first job is always the same: pick one recurring project type, define what gets captured at close-out, structure the lessons-learned into signals a system can read, and close a single loop — actuals feeding back into that one estimating template — before anything is automated.
The outcome of that groundwork is not a cleverer algorithm. It is the difference between an organisation that re-learns the same lessons every project and one whose next quote already knows what the last job cost.
Recommendation: four steps from a finished project to a learning system
You do not build the loop all at once. Four steps, in order, turn a completed project into an input for the next one:
- Step 1 — instrument the close-out. Capture actuals against the estimate structurally — hours, cost, deviations, causes — not as a final PDF nobody reopens. If the data isn't captured in a usable shape at project end, there is nothing to feed forward.
- Step 2 — structure the lessons. Turn narrative lessons-learned into machine-readable signals: cause codes, deviation categories, recurring defect types. A paragraph is a story; a coded cause is something an agent can act on.
- Step 3 — close one loop. Choose a single recurring project type and feed its actuals back into that type's estimating template and standard times. One working loop beats a company-wide programme that never ships.
- Step 4 — govern the write-back. Decide what an agent may change automatically and what it may only propose. Anchor that in the process model (BPMN) and, where machine or product data is involved, in your contracts — what the AI Act and Data Act require, your governance has to make operational.
Our assessment: the sequence matters more than the sophistication. Firms that instrument and close one loop first build a system that compounds; firms that wait for a full digital-twin platform keep re-learning the same lessons at full price. And all of it stands on the earlier parts of this series: without honest data (Part 1), clean masters (Part 2) and clear data sovereignty (Part 3), there is no reliable signal to feed back.
30 minutes of plain talk about your project data — directly with Dr. Dreher
Which of your finished projects should be sharpening the next quote — and what should an agent be allowed to change on its own? No sales pitch, no junior consultants.
Next steps
If a digital-twin initiative or an "AI for project management" proposal is on your desk, it pays to model the loop and settle the governance before any tool decision. You can find more on our approach to digitalisation, ERP and AI integration in our overview of consulting services.
The series so far:
why ERP data alone can't carry AI — Part 1
why no model repairs poor master data — Part 2
sharing data without losing control — Part 3.
From ERP data silo to peak AI performance in five steps - Part 5
This is the daily reality of plant & mechanical engineering project business; making the loop explicit is a question of process management.
Found this helpful? Let’s explore how these insights could benefit your business.
Click the Contact Us button to connect with me directly.
