The Cost Agent
“Why did this product get fourteen percent more expensive since March?” is a question with an exact answer that nobody has time to compute. It is two resolutions, a rollup and a diff — arithmetic, not judgement.
What it is, and what it is not
An agent that explains product cost by decomposing rollups over resolved structures. It answers what a cost is made of, what changed, which lines drove the change, and what a proposed change would do to it.
It is not a costing engine. It does not calculate standard cost, allocate overhead, model labour rates or produce anything an accountant would recognise as a costing run. Those are ERP functions built on transactions Manufacturing PLM never sees.
It is also not a source of cost data. Every figure in its answers comes from your ERP, cited with the source system and an as-of timestamp. What Manufacturing PLM contributes is the structure those figures are summed over, and the ability to sum them over two different configurations and subtract.
The mechanism: two resolutions and a subtraction
The question “why did cost move” is answered by resolving the product twice — once under the conditions that applied in March, once under today's — rolling cost through both, and comparing line by line.
That works only because resolution is deterministic and because both sides go through the same engine. A comparison with a resolution on one side and a stored structure on the other reports every effectivity and variant decision as a cost difference, which is how a fourteen percent movement becomes forty lines of noise.
The decomposition separates three causes that people routinely conflate: the structure changed (a component was superseded, a quantity moved), the price changed (same part, different cost in the ERP), and the configuration changed (you are asking about a different variant or plant than you think). Reporting a price rise as a design regression, or the reverse, sends the next hour of work in the wrong direction.
The failure it prevents
A product's cost has drifted up over two quarters. Somebody exports the current BOM with costs, exports an older one, and puts them side by side in a spreadsheet.
The comparison returns sixty rows. Most are noise: re-sorted lines, a phantom that expanded differently, eleven lines that appear on one side only because the older export was scoped to the 240-volt variant and the newer one was not scoped at all, and a dozen where the cost field was stale in one of the two extracts.
A day later somebody has an answer they are not confident in, and the answer is usually “the control board went up” — which is true and incomplete, because the actual driver was a quantity change on a fastener that occurs sixty times. Two resolutions and a subtraction produce three lines with numbers, in the time it takes to ask.
How it meets the rest of the product
It calls the same resolver, rollup and comparison services the interface calls, so a claim can be clicked through and re-run. Because those services are deterministic, re-running returns identical bytes — which is what lets a cost claim appear in a change review rather than only in a conversation.
During change review it answers the forward question: what would this ECO do to cost, at the effectivity proposed, for each affected product. That number sits next to the impact set, so an approver sees the engineering consequence and the commercial one on the same screen.
Where a cost target is missed, it proposes structural moves with citations — a consolidation onto a part already approved elsewhere, an alternate qualified on another product, a quantity that looks wrong against reference designators. Each proposal names the lines and the revisions it read them at.
How it meets your ERP
This is the agent most constrained by the system-of-record matrix, and deliberately so. Cost is ERP-mastered, so the agent cannot write one. Asked to reduce the cost of an assembly, it will not edit a price — it proposes a change to the structure that drives the price and leaves the number alone.
Figures are cited differently from things Manufacturing PLM owns. A cost carries its source system and an as-of stamp, because it is a cached read of somebody else's master record rather than something Manufacturing PLM can vouch for. Conflating the two would make the structural half of an answer look as provisional as the price half, or the price half look as solid as the structure.
It reads more than unit cost where the connector exposes it: on-hand and committed quantity, open purchase orders and lead time. A cost reduction that strands sixteen weeks of existing stock is not a cost reduction, and the agent says so rather than reporting the unit saving alone.
Where the boundary is
It does not forecast, quote, or model should-cost. Predicting where a commodity price will go, or what a supplier would charge at a different volume, requires information Manufacturing PLM does not hold and an agent that guessed would be inventing numbers that look exactly like the real ones.
It also cannot see cost your ERP does not expose. Tooling amortisation, freight, duty and yield loss are frequently the difference between a unit cost and a landed cost, and where those live outside the connector's reach the agent reports the boundary rather than quietly understating.
Facts
| Method | Two resolutions, a rollup each, and a subtraction |
| Separates | Structure change · price change · configuration change |
| Cost data | Entirely your ERP's — cited with an as-of stamp |
| Writes | Never a cost — cost is ERP-mastered |
| Proposes | Structural changes, with the lines cited |
| In change review | Cost impact at the proposed effectivity, per product |
| Also reads | On-hand, committed, open orders, lead time |
| Not offered | Should-cost modelling · quoting · price forecasting |
Frequently asked
Where do the cost numbers come from?
Entirely from your ERP, cited with the source system and an as-of timestamp. Manufacturing PLM contributes the resolved structure those figures are summed over. It holds no cost of its own, and every figure in an answer is a cached read of somebody else's master record.
Can it reduce our costs directly?
It cannot edit a cost, because cost is ERP-mastered under the system-of-record matrix. What it does is propose structural changes — a consolidation onto a part approved elsewhere, an alternate already qualified, a quantity that looks wrong — each citing the lines and revisions it read.
How does it explain a cost movement?
By resolving the product under both sets of conditions, rolling cost through each and comparing line by line. It then separates structure changes from price changes from configuration differences, because reporting a price rise as a design regression sends the next hour in the wrong direction.
Why not just export two BOMs and diff them?
Because that comparison returns noise. Re-sorted lines, phantoms expanding differently, and lines appearing on one side only because the two exports were scoped to different variants. Resolving both sides through one engine first is what makes the difference mean something.
Does it consider existing stock?
Yes, where the connector exposes it. A cost reduction that strands sixteen weeks of existing inventory is not a cost reduction, so on-hand, committed quantity and open purchase orders appear alongside the unit saving rather than the agent reporting the per-unit number alone.
Can it tell us what a part should cost?
No. Should-cost modelling, quoting and price forecasting need information Manufacturing PLM does not hold — commodity curves, supplier margin, volume breaks. An agent that guessed would be inventing figures indistinguishable from real ones, which is the worst possible failure mode here.
What about freight, duty and tooling amortisation?
Only where your ERP exposes them through the connector. Those are frequently the difference between unit cost and landed cost, and where they sit outside reach the agent reports the boundary rather than quietly understating the total and letting somebody act on it.