ERP-aware agents, and the honesty they require
An agent that can see both systems is far more useful than one that cannot — and far more dangerous, because a confident claim about somebody else's data is the easiest wrong answer to produce.
What ERP-aware actually means
It means an agent evaluation can read the cached ERP values Manufacturing PLM holds — cost, stock, lead time, open orders, item master presence — alongside engineering data, and reason about the two together.
It does not mean the agent queries your ERP directly. Evaluations read the same cached values every screen reads, with the same source attribution and the same as-of stamps. An agent given its own live connection would be an unbounded query load on a production system, triggered by a model's judgement about what to look at.
The distinction shows up in every finding. A finding names the value, the system it came from, and when it was read. *This item's unit of measure differs between systems as of a read eleven minutes ago* is a usable statement; *this item has the wrong unit of measure* is a claim the agent is not entitled to make.
Which system is right
When two systems disagree, the interesting question is not that they disagree — it is which one is supposed to be authoritative for that field, and the answer is in your system-of-record matrix rather than in anything an agent can work out.
So agents read the matrix. A cost disagreement where the ERP owns cost is reported as drift in Manufacturing PLM's cached copy, resolved by re-reading. The same disagreement on a field Manufacturing PLM owns is reported as a publication that did not land, resolved by re-publishing. Same symptom, opposite remedies.
An agent that reported both cases identically would be worse than no agent, because it would send half its findings to the wrong team, and a team that receives wrong findings stops reading the queue within about a fortnight.
Where the matrix does not cover a field — which happens, because matrices are written by people and products have a lot of fields — the finding says the ownership is undefined and asks for a decision. That is a genuinely useful output: an undefined row is a disagreement waiting to happen.
The failure it prevents
A released assembly's structure is published to the ERP. One line fails validation because the item does not exist in the item master. The publication reports partial success, which nobody reads, and the ERP holds a structure missing one component.
Production builds against it for three weeks. The missing component is a fastener, present in stock, consumed from a bin without being booked, and the shortage surfaces as a stock discrepancy that gets written off as a counting error.
Nobody looked, because nothing was looking. A partial publication is precisely the kind of half-failure that no dashboard shows and no person owns. An agent comparing the resolved structure against what the ERP actually holds finds it the same day, names the line, and says which side is missing it.
How it meets the rest of the product
The reconciliation engine does the deterministic comparison; agents handle what determinism cannot. A field-by-field diff is a query and needs no model. Deciding that four separate drifts share one cause — a connector misconfiguration after a change in your ERP's unit-of-measure settings — is a judgement, and that is where an agent earns its cost.
Findings arrive as tasks routed by the matrix. Drift on an ERP-owned field goes to whoever owns the integration; a failed publication on a Manufacturing PLM-owned field goes to the engineering owner. Routing by ownership is the practical payoff of maintaining the matrix at all.
Agents cannot write across the seam. Publication requires an attributed actor and a change record, and an agent's Prepare tier stops at a draft — which for a publication means a queued publication awaiting a person's approval, not a publication that happened.
How it meets your ERP
Read scope is configured explicitly and narrowly. An agent reads the fields the connector is configured to cache and nothing else, which means enabling ERP-aware agents does not widen what Manufacturing PLM reads from your ERP by a single field.
Staleness is surfaced rather than hidden. Where a cached read is older than its configured freshness window, findings based on it say so, and the agent will state that a conclusion depends on data last read four days ago rather than presenting it as current.
No agent has write access to your ERP under any tier or configuration. The connector is the only write path and it requires an attributed actor. This is not a setting; there is no version of the product in which it is otherwise.
Where the boundary is
Agents do not query your ERP directly. They read Manufacturing PLM's cached values with their provenance intact. A model-triggered live query against a production ERP is an unbounded load nobody agreed to.
They also do not resolve disagreements. An agent names the fields, the sides, the as-of stamps and the matrix's ownership, and a person decides. A machine choosing which of two systems is correct is a machine editing a record with no authority to do so.
Facts
| Reads | Manufacturing PLM's cached ERP values — never a live ERP query |
| Every finding names | The value · the source system · the moment it was read |
| Ownership from | Your system-of-record matrix, not the agent's judgement |
| Same symptom | Cache drift or failed publication — opposite remedies |
| Undefined matrix rows | Reported as a decision needed, which is a useful finding |
| Routing | By ownership — integration owner or engineering owner |
| Stale reads | Stated in the finding, never presented as current |
| Write access to your ERP | None, at any tier, in any configuration |
Frequently asked
Do agents query our ERP directly?
No. They read the cached values Manufacturing PLM already holds, with the same source attribution and as-of stamps every screen uses. An agent with its own live connection would be an unbounded query load on a production system, triggered by a model's judgement about what to examine.
How does an agent know which system is right?
From your system-of-record matrix, rather than from its own reasoning. A cost disagreement on a field where the ERP owns cost is cache drift, resolved by re-reading. The same disagreement on a field Manufacturing PLM owns is a failed publication, resolved by re-publishing it.
Why does that distinction matter so much?
Because the remedies are opposite and so are the owners. An agent reporting both cases identically would send half its findings to the wrong team, and a team receiving wrong findings stops reading the queue within roughly a fortnight of starting.
What if our matrix does not cover a field?
The finding says ownership is undefined and asks for a decision. That is a genuinely useful output rather than a gap — an undefined row is a disagreement waiting to happen, and finding it before it happens costs nothing to act on.
What can an agent do about a partial publication?
Find it, name the affected line, and say which side is missing it. Partial publications are the classic half-failure that no dashboard shows and no person owns, which is why they persist for weeks and surface as stock discrepancies nobody explains.
Can an agent re-publish or re-read to fix drift?
Prepare tier stops at a draft, which for a publication means a queued publication awaiting a person's approval rather than one that happened. Writing across the seam needs an attributed actor and a change record, and an evaluation produces neither of those.
Does enabling this widen what you read from our ERP?
No. Agents read the fields the connector is already configured to cache and nothing at all beyond them, so turning on ERP-aware evaluation does not add a single field to what Manufacturing PLM requests from your system, or change how often it asks.