Engineering Change: How Teams Can Apply AI Agents in ECO Work

In a recent article, Why ECOs Need a Workspace: Rethinking the ECO for Agentic Change, I focused on a fundamental gap in how engineering change is managed today, showing that traditional ECO systems often arrive too late in the process to capture real context and support the work that actually happens before formal approval. 

This piece continues that conversation and shifts the lens slightly, not to repeat the problem, but to explore how teams can practically apply AI to real ECO work once change finally has a place to live. Rather than imagining a single omniscient assistant, we will look at how multiple specialized AI agents can work alongside humans in a collaborative workspace, continuously observing the evolving change context, reducing coordination overhead, and leaving judgment and decisions clearly in human hands.

ECOs Were Never a Solo Activity

Engineering change has never been an individual exercise, even if many of the systems built to manage it quietly assume that it is. Mechanical engineers, electrical engineers, manufacturing engineers, supply chain, quality, and program roles all contribute to change in different ways and at different times. Some of these contributions are tightly coupled, others are loosely connected, but almost all of them happen before a formal ECO record exists. The ECO typically appears once a team believes it has converged, which means that much of the real work has already happened somewhere else.

This is not a failure of discipline. It is a consequence of how change actually unfolds. Engineers discuss alternatives, sketch ideas, test assumptions, and negotiate constraints long before they are confident enough to formalize a decision. Systems that only engage at the moment of approval inevitably feel late, because they are. They enter the story after the most complex reasoning has already taken place.

Why ECOs Often Feel Late

Most traditional PLM ECO software systems are optimized to record outcomes, not to support exploration. They do an accurate job at documenting what changed, then perform an approval process, and when it became effective, but they struggle to capture why the change took the path it did or what alternatives were considered and rejected along the way. As a result, reviews often turn into investigative exercises, where participants try to reconstruct context that no longer exists in any coherent form.

This reconstruction is expensive. Engineers spend time re-explaining decisions. Reviewers ask questions that were already answered weeks earlier. Gaps in data surface late, when they are costly to fix. None of this is caused by a lack of intelligence or effort. It is caused by the fact that the system of record is asked to do something it was never designed to do, which is to preserve evolving intent.

Change Is Time-Based, Not Event-Based

One of the most persistent mismatches in change management is the assumption that change is an event. In reality, change is a process that unfolds over time, often non-linearly. Ideas branch, stall, and converge. Some parts of a product move quickly, others lag behind. Fast corrective actions run in parallel with longer redesigns. Treating all of this as a single transaction forces teams to either serialize work that could have happened in parallel or to hide unfinished work outside the system.

This is where coordination overhead accumulates. Engineers compensate by relying on email threads, shared documents, whiteboard sessions, and hallway conversations. These coping mechanisms work locally, but they do not scale, and they do not transfer. When the time comes to formalize the change, the ECO must reconstruct a reality that existed only briefly and mostly outside the system.

The Missing Layer: A Shared Change Context

What has been missing is not another workflow or approval step, but a shared change context that persists over time. A collaborative workspace built around a BOM sandbox changes the role of the ECO entirely. Instead of being the container for work, the ECO becomes the result of work.

In a BOM sandbox, teams can explore changes without impacting released structures. They can redline assemblies, try alternates, adjust quantities, and model what-if scenarios while keeping all of that activity connected to the product definition itself. Discussions, tasks, and decisions live next to the structures they affect, not in disconnected tools. Parallel explorations can coexist without interfering with each other, and context accumulates naturally as work progresses.

Once change has a place to live, many of the pathologies of traditional ECO processes begin to soften. Reviews become more focused. Late surprises are reduced. Decisions are easier to understand because the reasoning that led to them is still present.

How to apply AI to help? 

In the last year, we have seen many AI chatbots focusing on how to improve PLM functions. Most of these tools were session-based. They operate on snapshots of information provided at a moment in time or extracted using API or MCP layer – actions, queries, analysis, etc. Engineering change, by contrast, is time-based. It depends on evolving context, partial information, and ongoing collaboration.

Without persistent context, AI can assist with drafting summaries or checking isolated rules, but it cannot support the flow of change itself. It is asked to reason about something that no longer exists as a coherent whole. This is not a limitation of model intelligence so much as a limitation of where and how the models are applied.

The Wrong Mental Model: One Super-Agent

A common response to this gap has been to imagine a single, highly capable AI agent that can “understand” an ECO and manage it end to end. This mental model is appealing, but it repeats the same mistakes that made monolithic workflows brittle in the first place. Engineering change is distributed, contextual, and partial by nature. Expecting one agent to own it all creates a new bottleneck instead of removing an old one.

Engineering teams do not work that way. Responsibility is distributed. Expertise is specialized. Coordination happens through shared artifacts, not through a single omniscient coordinator. If AI is going to fit naturally into this environment, it needs to mirror that structure rather than fight it.

Agentic ECO as a Multi-Agent System

A more realistic and more useful model is an agentic ECO built as a multi-agent system. Instead of one agent trying to understand everything, multiple specialized agents operate continuously on the same shared change context. Each agent has a narrow responsibility and a clear scope. None of them makes decisions. They observe, validate, and surface issues as change evolves.

These agents are long-running not because they act autonomously, but because change itself is long-running. They remain present as structures are edited, alternates are introduced, and discussions unfold. Their value comes from persistence and focus, not from authority.

What Specialized Agents Actually Do

In practice, this specialization matters. One agent may continuously watch part numbers and structure completeness, flagging inconsistencies as assemblies change. Another may focus on quantities, units of measure, and effectivity, ensuring that basic definitions remain coherent as alternatives are explored. A third may monitor vendor assignments, sourcing rules, and lead-time assumptions, highlighting conflicts that often surface only late in the process. Others may track cost impact, compare deltas against released BOMs, or watch for reuse opportunities and inventory implications.

Each of these tasks is individually simple, but together they represent a significant portion of the coordination work engineers perform today. By handling them continuously and quietly, agents reduce the need for periodic manual audits and last-minute cleanup efforts.

Shared Context as the Coordination Layer

An important aspect of this model is that the agents do not need to coordinate with each other explicitly. The collaborative workspace itself is the coordination layer. Because all agents operate on the same evolving context, their observations naturally align. A missing quantity detected by one agent often explains a cost anomaly flagged by another. A sourcing inconsistency sheds light on a lead-time concern raised elsewhere.

This is a subtle but important shift. Coordination emerges from shared context rather than from centralized control. The system does not attempt to orchestrate intelligence. It makes information visible.

Humans in the Loop by Design

None of this changes the role of human judgment. Engineers remain responsible for decisions, tradeoffs, and approvals. Agents do not decide what the change should be. They prepare the ground for decision-making by ensuring that the state of the change is visible, coherent, and complete.

Reviews become conversations about intent and tradeoffs rather than scavenger hunts for missing information. Approvals capture real decisions rather than implicit assumptions. Promotion from sandbox to released structures remains deliberate and governed.

The ECO Emerges, It Is Not Executed

When change exploration converges, the ECO emerges as a structured summary of decisions already made. It is generated from the accumulated context in the workspace, not from memory or reconstruction. Because intent, alternatives, and reasoning were captured as part of the work, the ECO is auditable and understandable without additional explanation.

This reframing matters. The ECO stops being a procedural hurdle and becomes a natural outcome of collaborative change work. It reflects reality instead of trying to recreate it.

From Change Records to Product Memory

Over time, this approach creates something more durable than individual ECOs. It creates product memory. Future teams can see not only what changed, but why it changed, what options were considered, and what constraints shaped the final decision. AI, in turn, has something meaningful to reason about, because the context that shaped past decisions is still present.

Bringing It All Together: From Concept to a Concrete Model

At this point, it helps to step back and look at the full picture in a more compressed form. The slide discussed earlier is not meant to introduce a new workflow or propose another layer of automation. It is a visual summary of the ideas explored throughout this article, showing how engineering change work can be reorganized once it has a shared place to live.

The flow starts with released product data coming from CAD, PLM, and ERP systems. This is intentional. Agentic ECOs do not replace existing systems of record. They depend on them. Change always begins from a known baseline, and that baseline must remain authoritative. What changes is what happens next.

Instead of immediately creating an ECO, released structures are pulled into a collaborative BOM sandbox that acts as a shared change context for both humans and AI agents. This workspace is where redlining, alternatives, and what-if scenarios happen, where discussions unfold, and where multiple parallel explorations can coexist over time without interfering with released data. The workspace is not a staging area for an ECO. It is the environment where change actually happens.

Inside that shared context, multiple specialized AI agents operate continuously. Each agent focuses on a narrow responsibility such as part number and structure completeness, quantity and effectivity validation, vendor and sourcing consistency, cost and impact analysis, or delta comparison against the released BOM. None of these agents owns the change. None of them decides what should be done. Their role is to observe, validate, and surface issues while change is still forming, when corrections are cheap and context is still fresh.

Human-in-the-loop review sits above this activity, not as a bottleneck but as the place where judgment is exercised. Engineers review alternatives, resolve tasks, make tradeoffs, and approve decisions with full visibility into what has changed and why. AI contributes by summarizing intent and highlighting open issues, but responsibility remains clearly human.

Only at the end of this process does the ECO appear. It is generated as a structured, auditable outcome of the work already done in the workspace and then pushed back into PLM or ERP systems. The ECO no longer needs to reconstruct intent or reverse-engineer decisions. It reflects reality because reality was captured as it evolved.

This model is not speculative. It directly connects to ongoing OpenBOM research and development work, which focuses on three foundational technologies that make this approach practical rather than theoretical.

The first is the collaborative BOM editing workspace itself. Without a shared, persistent environment for multi-user change exploration, neither humans nor AI agents have stable context to work on. The workspace is the coordination layer that replaces ad-hoc communication with visible, connected change activity.

The second is automatic history tracking combined with comments and tasks that are natively tied to product structures. Change intent, discussions, and decisions are not treated as external artifacts. They become part of the product data over time, creating continuity across exploration, review, and formal release.

The third is the ongoing development of AI agents that operate on this context. These agents are designed to be narrow, long-running, and assistive, focusing on reducing coordination overhead rather than exercising judgment. Their value comes from persistence and specialization, not from autonomy.

Together, these technologies shift the role of AI in change management away from automation theater and toward something more grounded: making complex, collaborative ECO work easier to reason about as it happens.

Conclusion: Toward Agentic ECOs to Fit Engineering Work

In this article, I have tried to make a simple argument. Engineering change does not fail because people are slow or because approvals are inefficient. It fails when the real work of change has no place to live and must be reconstructed after the fact. ECOs were never meant to carry that burden alone.

Agentic ECOs work when change is treated as a collaborative, time-based process supported by a shared workspace. They work when AI is applied not as a single decision-making entity, but as a set of specialized agents that quietly reduce coordination overhead while humans remain fully responsible for judgment, tradeoffs, and accountability.

This is the direction OpenBOM continues to explore, both in product development and in research around how AI agents can be introduced safely and usefully into complex ECO workflows. The goal is not to replace existing systems or engineering practices, but to complement them with tools that respect how change actually happens.

If you are working with complex products, distributed teams, or ECO processes that feel heavier than they should, we are always interested in discussing how collaborative workspaces and agent-assisted change exploration could apply to your environment. These problems are rarely solved by theory alone. They are solved by working through real change scenarios together and learning where AI genuinely helps and where it should stay out of the way.

Are you interested in getting involved in OpenBOM research work? Please contact us to talk. 

Best, Oleg