The Change Agent
Most of the work in raising a change is not the decision. It is assembling the affected objects, the proposed revisions and the right reviewers — and that part is a traversal, a set of rules and a draft, which is exactly what an agent should be doing.
What it is, and what it is not
An agent scoped to the change process. It drafts change objects, populates their affected sets, proposes resulting revisions, recommends reviewers, and explains what a proposed change would touch.
It is not a decision maker. The judgement in a change — whether the cost is worth it, whether the customer must be told, whether the qualification has to be repeated — belongs to people, and nothing here attempts to shortcut that.
It is also not the source of the impact analysis. That is a deterministic traversal with no model in its path, and the agent is a caller of it. Keeping those separate is what allows the impact set attached to an approved change to be evidence rather than an artefact of whichever model version happened to run that day.
What it actually does
Drafts the change. From a problem description, a failing part, or a supplier end-of-life notice, it creates a draft ECR of the right kind with the affected objects already populated from the impact traversal and the proposed revisions filled in.
Recommends reviewers. Not by seniority, but by relationship: who released the affected revisions, who owns the requirements they verify, who approved the qualification the change might invalidate. Each recommendation is cited to the object that produced it.
Explains the blast radius. Given a hypothetical — “if we supersede this connector, what else changes?” — it runs the traversal and describes the result, including the parts already published to the ERP with open demand behind them.
Flags what the draft is missing. A change with no effectivity, an affected object in a lifecycle state that cannot transition, a proposed revision that collides with another open change on the same part. These are rules, and the agent runs them before a human wastes a review cycle on an incomplete draft.
The failure it prevents
A supplier end-of-life notice arrives on a Tuesday. It affects one component. Somebody has to work out which products contain it, which of those are shipping, which have open orders, whether an alternate is already approved elsewhere, and who needs to be in the room.
That takes a competent engineer most of a day, and it is the reason the notice sits in a queue for three weeks. Not because nobody cares, but because starting it costs a day and there is always something with a nearer deadline.
The agent produces the draft in the time it takes to read the notice. The engineer's day is spent on the decision rather than on assembly, and — this is the part that matters — the change gets raised in week one instead of week four, while there is still stock and still choice.
How it meets the rest of the product
It calls the impact analysis service rather than reimplementing it, so the affected set on an agent-drafted change is byte-identical to the one a person would get by clicking the button. That reproducibility is what makes the draft reviewable rather than merely convenient.
Every element of a draft is cited to the object and revision that produced it. A recommended reviewer names the release they signed; an affected object names the relationship path and depth by which it was reached. A reviewer who disagrees can see exactly what the agent was reading.
The default tier is Prepare: it creates real draft objects in an unsubmitted state, carrying an agent attribution, and a person reviews and submits. That is where most tenants leave it, and the plan was always that they should — a drafted ECR with the affected objects populated is most of the labour, and a human submitting it is a feature rather than a limitation.
How it meets your ERP
Drafts carry ERP context, because an impact set without it is only half an answer. Affected parts already published to your ERP are flagged, with on-hand quantity, open purchase orders and lead time shown against each — read from NetSuite, SAP, Dynamics, Epicor or Acumatica as the connector is configured.
This is what turns “four assemblies are affected” into a decision. Two with no stock and a two-week lead time are a different proposition from one with sixteen weeks on the shelf and a purchase order in flight, and the disposition conversation is about the second one.
The agent will not alter ERP-mastered fields, and it will not initiate a publication. Publishing a released change outward sits at the Execute tier by default and cannot be lowered accidentally — it is a stated constraint in the connector configuration, not merely a setting.
Where the boundary is
It does not approve, release, or set effectivity on its own. Effectivity is a commercial and operational decision — how much stock to burn, what to tell a customer — and no amount of graph traversal produces it.
It also does not decide disposition on affected inventory. Use-as-is, rework, scrap and return-to-vendor are judgements made with inventory data in front of a person; the agent assembles that data and stops.
Facts
| Scope | Change objects — draft, populate, recommend, explain |
| Impact set | Computed by a deterministic service, not by the model |
| Default tier | Prepare — real drafts, unsubmitted |
| Reviewers | Recommended by relationship, each cited |
| Pre-flight rules | Missing effectivity, bad states, colliding revisions |
| ERP context | On-hand, open orders and lead time on affected parts |
| Publication | Execute tier only; cannot be lowered by accident |
| Never | Approves, releases, sets effectivity, decides disposition |
Frequently asked
Does the AI compute the impact analysis?
No. The traversal is a deterministic service with no model in its path, and the agent calls it. That separation is deliberate: an impact set attached to an approved change has to be reproducible a year later, not an artefact of whichever model version happened to run that day.
What does an agent-drafted ECR look like?
A real draft change object in an unsubmitted state, with the affected objects populated from the traversal, proposed revisions filled in, recommended reviewers attached, and an agent attribution on the record. A person reviews it and submits it into the normal change process.
How does it choose reviewers?
By relationship rather than by seniority: who released the affected revisions, who owns the requirements those parts verify, who approved a qualification the change might invalidate. Each recommendation cites the object that produced it, so a disagreement is easy to check.
Can it set the effectivity date?
No. Effectivity is a commercial and operational decision — how much stock to burn through, what a customer has been promised, when a plant can absorb the change. No amount of graph traversal produces that, and an agent that guessed would be guessing about money.
Does it see our ERP data?
It reads context: affected parts already published, with on-hand quantity, open purchase orders and lead time alongside. That is what turns a list of four affected assemblies into a decision, because the one with sixteen weeks of stock behind it is the expensive one.
Can it release a change to the ERP?
Only at the Execute tier, which sits behind the human approval gate and is a stated constraint in the connector configuration rather than a toggle. Publishing a released change into a production ERP is the one action where the tier cannot be lowered by accident.
What if the draft is wrong?
It is a draft, so you edit or discard it like any other. The pre-flight rules catch the mechanical problems first — missing effectivity, affected objects in states that cannot transition, proposed revisions colliding with another open change — so review time goes on substance rather than on completeness.