The BOM Agent
Ask what changed between two revisions, why a rollup moved, or what looks wrong in a structure somebody just pasted in. It answers by calling the resolver and the comparison service — not by reading a summary of them.
What it is, and what it is not
An agent scoped to structures. It resolves, compares, rolls up, traverses and validates, and it explains what it found in the vocabulary an engineer already uses.
It is not a chat box over a search index. The difference is that its answers come from the same services the screens are built on, so “what changed between rev C and rev D” returns the comparison — the actual five difference kinds against the actual resolved structures — rather than a paraphrase of a document that mentions both revisions.
It also does not have its own opinion about what a BOM contains. There is one resolver, and the agent is a caller of it like everything else. An agent with a private read path would be able to disagree with the compare screen, and there would be no principled way to say which was right.
What it actually does
Explain a difference. Given two revisions, two variants, two plants or two dates, it runs the comparison and describes the result — which lines were added, removed, changed or moved, and which change order caused each one, cited.
Explain a number. A cost, mass or compliance rollup that moved gets decomposed: which lines drive it, by how much, and what changed underneath. This is the question people most want automated and it is almost entirely arithmetic over a resolved structure.
Find what looks wrong. Quantities that are implausible against reference designator counts, a line with no effectivity in a structure where everything else has one, an alternate group with a single member, a phantom that expands to nothing. These are not model judgements; they are rules, and the agent runs them and reports the exceptions.
Answer a question about scope. Where a part is used, in which shipping products, under which conditions — the where-used query with the conditions made explicit rather than assumed.
The failure it prevents
Somebody pastes four hundred rows into a new assembly on a Friday afternoon. Two hundred and ninety of them are correct. The rest have quantities that came across as text, three reference designators that do not match their quantities, and one line pointing at a part that was made obsolete last year.
None of that is visible by scrolling. The grid validates what it can at entry, but a quantity of eight against twelve reference designators is not a syntax error — it is a mistake that requires reading both columns together and caring about the relationship.
The agent reads the whole structure and reports the eleven exceptions with the rows named. It does not fix them, at the default tier, and it does not need to: the value is entirely in the reading, which is the part a person will not do at five o'clock on a Friday.
How it meets the rest of the product
Every answer carries citations naming objects at the revisions they were read at, so a claim can be clicked through and re-run. Because the comparison and rollup services are deterministic, re-running returns identical bytes — which is what makes an agent answer usable in a change review rather than merely interesting.
It sits on a permission tier you set per tool. Reading and explaining is Observe. Proposing a correction is Recommend. Drafting a redline against a real structure is Prepare. Applying a mass change is Execute, behind the human gate. Most tenants keep it at Recommend for reads and Prepare for drafting.
It inherits the asking user's permissions in full, so it cannot surface a structure or a line that person could not open themselves, and it does not reveal existence through the shape of a refusal.
How it meets your ERP
Cost and on-hand values in its answers come from your ERP and are cited as such, with the source system and an as-of timestamp. The structural half of an explanation is reproducible from Manufacturing PLM's own resolution; the price half is a cached read of somebody else's master record, and the citation says so rather than blurring the two.
Because cost is ERP-mastered under the system-of-record matrix, the agent will not propose editing a cost. Asked to reduce the cost of an assembly, it proposes structural moves — a consolidation, an alternate already approved on another product, a quantity error — and cites the lines involved.
It also reads publication state. Asked whether a change is safe, it can tell you which affected parts have already been published to the ERP and carry open demand, which is usually the difference between a cheap change and an expensive one.
Where the boundary is
It does not approve anything, and it does not release. Structure edits it proposes at the Prepare tier arrive as drafts with an agent attribution on them, and a person submits them into change control like any other change.
It also does not judge engineering intent. A quantity that looks implausible against reference designators may be entirely correct for reasons that exist nowhere in the data, and the agent reports the exception rather than asserting an error. Telling the difference is what the reviewer is for.
Facts
| Scope | Structures — resolve, compare, roll up, traverse, validate |
| Reads via | The same services the interface calls |
| Citations | Object at revision, on every claim |
| Default tier | Recommend for reads, Prepare for drafts |
| Permissions | Cannot exceed the asking user's own access |
| Validation | Rules, not model judgement — exceptions reported |
| ERP values | Cited with source system and as-of stamp |
| Never | Approves, releases, or edits an ERP-mastered field |
Frequently asked
How is this different from a chat box over search?
It calls the resolver and the comparison service directly, so “what changed between rev C and rev D” returns the actual comparison against actual resolved structures. A search-backed assistant paraphrases documents that mention both revisions, which is a different and much weaker claim.
Can it edit a BOM?
Only at a tier you grant, and by default it drafts rather than commits. A proposed correction arrives as a draft with an agent attribution, and a person submits it into change control. Applying a mass change sits at Execute, behind the human approval gate.
What kinds of problem does it catch?
Quantities implausible against reference designator counts, lines with no effectivity where everything else has one, alternate groups with a single member, phantoms that expand to nothing, and references to obsoleted parts. These are rules rather than judgements, which is why the results are checkable.
Does it explain cost movements?
Yes, and it is the question people most want automated. It decomposes a rollup into the lines that drive it and what changed underneath, citing each. The structural part comes from Manufacturing PLM's resolution; the price part is cited as a read of your ERP with a timestamp.
Will it flag things that are actually correct?
Sometimes, and it reports them as exceptions rather than errors. A quantity that looks wrong against reference designators may be right for reasons recorded nowhere in the data. Distinguishing those is the reviewer's job, and an agent that asserted certainty would be making it harder.
Can it see restricted programmes?
Only if the person asking can. It runs inside the asking user's permissions, so the tenant predicate, role policy and field-level access control all apply. A refusal is shaped so it does not reveal that something exists — leaking existence through a refusal is still leaking.
Are its answers reproducible?
Yes. The comparison, resolution and rollup services underneath have no model in their path, so re-running any cited query returns identical bytes. That is what makes an agent answer usable in a change review rather than merely interesting to read.