The Manufacturing Agent
When an engineering change lands, somebody has to work out what it means for each plant's build. That is a comparison against three structures with different deliberate divergences — tedious, mechanical, and exactly the shape of work worth automating.
What it is, and what it is not
An agent scoped to the manufacturing structure: the transform from engineering bill to plant bill, the divergences each plant maintains, and the work instructions generated from them.
It is not a process planner. Deciding the assembly sequence, the fixture, the station layout and the takt time is manufacturing engineering, informed by a plant nobody has modelled in enough detail for a model to reason about usefully.
It also does not own the MBOM. Ownership is the contested row in the system-of-record matrix and is decided per tenant — frequently in favour of your ERP. Where the MBOM lives there, this agent reads the EBOM side and proposes; it does not write into a structure Manufacturing PLM does not master.
What it actually does
Proposes the transform. Given a new or changed EBOM, it proposes the MBOM edits each plant would normally make, learned from the divergences that plant already maintains: this site explodes fastener kits, adds an EU label and a carton, and substitutes the regional power supply. The proposal is a draft a person accepts, edits or rejects.
Finds the plant a change missed. An ECO touching a shared sub-assembly affects three plant structures. Two are obvious; the third diverged eighteen months ago in a way nobody remembers. The agent compares against all three and reports which divergences the change breaks.
Drafts work instructions from the structure. Not prose invented about a process — the step list follows the MBOM and the operations recorded against it, with part numbers, quantities and revisions pulled through rather than typed.
Flags what has gone stale. Instructions referencing a part that has since revised, a plant MBOM whose EBOM moved without a corresponding transform, a phantom that no longer explodes to anything.
The failure it prevents
A change releases. Two plants pick it up because their manufacturing engineers were in the review. The third — a smaller site running an older variant with a substituted connector — was not represented, and the change breaks the substitution in a way that only shows up when a kit fails to scan.
Four hundred units later somebody works out what happened. The root cause is not carelessness; it is that comparing an EBOM change against three plant structures with different deliberate divergences is an hour of careful work per change, and nobody has an hour per change.
The agent does that comparison in the time the review takes, and reports the third plant by name. It does not decide what to do about it — that is a conversation between two engineers — but the conversation happens before release rather than after four hundred units.
How it meets the rest of the product
Comparisons run through the resolution engine on both sides, so a plant MBOM effective from October is compared as it will be, not as it is today. Effectivity and variant conditions apply to manufacturing structures exactly as they do to engineering ones.
The change impact set already includes derived MBOMs — that is a deterministic traversal with no model in its path. What the agent adds is interpretation: which of those affected structures have divergences the change actually breaks, versus which inherit it cleanly.
Proposals land as drafts through the ordinary change process, with an agent attribution on the record. A person submits. Every claim cites the structures, lines and revisions it read, and because the underlying comparison is deterministic a reviewer can re-run it and get the same result.
How it meets your ERP
Where the MBOM masters in your ERP, the agent reads the published structure back as context and compares against it, but proposes changes as engineering actions rather than writing production BOMs. That boundary is not politeness — writing into a structure another system masters is how two systems end up disagreeing overnight.
Routings, work centres and operations are not touched under either ownership arrangement. They belong to manufacturing execution, and the agent reads them where exposed to keep work instructions consistent with the actual operation sequence.
Stock context makes proposals actionable. A transform change that obsoletes a plant-specific carton with eleven weeks of stock behind it is a different proposition from one with none, and the agent shows the quantity beside the proposal rather than the structural delta alone.
Where the boundary is
It does not decide assembly sequence, tooling, station layout or takt time. Those depend on the physical plant — the bench, the fixture, the operator, the thing that is awkward to reach — and none of that is in the data. An agent proposing a sequence would be guessing about a room it has never seen.
It also cannot invent a divergence that was never recorded. If a plant substitutes a connector informally, on the floor, without an MBOM line, the agent cannot compare against it and will report the change as landing cleanly. That is an argument for recording the substitution, and a limit worth knowing.
Facts
| Scope | EBOM→MBOM transform · plant divergence · work instructions |
| Learns from | The divergences each plant already maintains |
| Key output | Which plant a change quietly breaks, by name |
| Comparisons | Both sides resolved — future effectivity included |
| Writes | Drafts only, through the ordinary change process |
| MBOM in your ERP | Reads and proposes; never writes a structure it does not master |
| Routings | Read where exposed, never modified |
| Cannot | Decide sequence, tooling, layout or takt time |
Frequently asked
Can it create our plant MBOMs?
It proposes the transform each plant would normally apply, learned from the divergences that plant already maintains — kits exploded, labels and cartons added, regional parts substituted. The proposal is a draft somebody accepts, edits or rejects, not a structure it creates unilaterally.
How does it know a change breaks a plant?
By comparing the changed EBOM against every derived plant structure through the resolution engine, and reporting which deliberate divergences the change conflicts with. That comparison is an hour of careful work per change by hand, which is why nobody does it every time.
What if the MBOM lives in our ERP?
Then it reads the published structure back as context and proposes engineering-side changes, without ever writing production BOMs itself. Writing into a structure that another system masters is how two systems end up disagreeing overnight, and no permission tier makes that acceptable.
Does it write work instructions?
It drafts them from the structure and the recorded operations, with part numbers, quantities and revisions pulled through rather than typed. It does not invent prose about a process it cannot observe. A person edits and owns the result before it reaches a line.
Will it plan the assembly sequence?
No. Sequence, tooling, station layout and takt time depend on the physical plant — the bench, the fixture, the thing that is awkward to reach — and none of that is in the data. An agent proposing a sequence would be guessing about a room it has never seen.
What about undocumented substitutions?
It cannot see them. If a plant substitutes a connector informally on the floor without an MBOM line, the agent compares against a structure that does not reflect reality and reports the change landing cleanly. That is an argument for recording it, and a real limit.
Does it consider existing stock?
Yes, where the connector exposes it. A transform change obsoleting a plant-specific carton with eleven weeks of stock behind it is a different proposition from one with none, so the quantity appears beside the proposal rather than the structural delta alone.