Why ECOs Need a Workspace: Rethinking the ECO for Agentic Change

I’ve spent a lot of time this week rereading notes from past conversations about ECOs, AI, and collaboration, and one thing stood out: we keep trying to automate change without fixing where change actually happens. This is a reflection on that mismatch and on what might finally move us forward.

Change Is Still the Hard Part

Efficient management of change has always been positioned as one of the core promises of PLM. Over the years, we built systems to route approvals, track revisions, and provide traceability, and in many organizations those mechanisms function exactly as intended. Yet when I speak with engineering teams, change management still comes up as one of the most frustrating and least trusted parts of product development. Engineers rarely complain that approvals are missing. What they describe instead is the disconnect between how change actually unfolds and how change is represented inside formal systems.

Most ECO processes are optimized to record decisions after they are made. The work of exploring alternatives, understanding impact, negotiating tradeoffs, and gradually converging on a solution still happens elsewhere—inside CAD sessions, spreadsheets, supplier emails, meetings, and side conversations. 

When ECO is created, it typically represents a list of changes in a BOM – here are items added, here items replaced, here are some edits, effectivity changes, etc. All together they represent actual instructions about “what to do to move from a BOM v1 to a BOM v2. 

This gap is not accidental. It reflects a deeper assumption that change is an event rather than a process that unfolds over time. As long as that assumption holds, adding more workflow steps or more automation does little to improve the real work of engineering change.

Here is the thing, by the time an ECO is created, much of the important context has already disappeared. The ECO becomes a reporting artifact rather than the place where change happens. In a good system, it will have some form or section where the team engineers and other involved people will put the reason behind the change (eg. supplier replacement or design change, etc) 

Change Doesn’t Happen All at Once

If there is one consistent lesson from years of observing product teams, it is that change is rarely linear. A design change often starts as a vague concern: a cost risk, a supply issue, a manufacturability question, or a performance margin that feels uncomfortably thin. From there, it evolves through partial investigations, competing alternatives, temporary conclusions, and sometimes reversals. People join late, others drop out, and constraints shift as new information appears. The “final” decision is usually the result of negotiation and compromise rather than a clean analytical answer.

Traditional PLM ECO systems compress all of this into a single object with a start date, an end date, and an approval path. That compression is useful for governance, but it hides how the work actually happens. Engineers compensate by doing the real thinking outside the system and using the ECO only as a formal checkpoint. Over time, this creates a familiar pattern: the system is where decisions are recorded, while the real work happens somewhere else.

This is also why many attempts to apply AI to change management have felt underwhelming. AI can summarize, compare, and even propose edits, but it struggles when the underlying process is fragmented. The limitation is not intelligence. It is the absence of a stable place where context can accumulate.

The Cost No One Accounts For

Change management is dominated by coordination and workflow process. Clarifying scope, checking dependencies, understanding configuration effectivity, packaging the exact content of a change, preparing review material, and following up on open questions each take a modest amount of time. Taken together, they account for most of the effort involved in executing change.

These activities are often faster to do manually than to formalize, which is why they remain informal. Any system that requires engineers to over-specify work before it can begin will be bypassed. Engineers will do the work themselves because it is arithmetically cheaper. As long as the cost of explaining, supervising, and verifying exceeds the cost of execution, delegation simply does not make sense.

This is the core reason AI has a difficulty to transform current ECO and change processes. The problem is not that AI cannot generate proposals. The problem is that the system makes it expensive to coordinate safely. Until that overhead drops, engineers will continue to carry the burden themselves.

Context Is the Missing Primitive

Most PLM systems understand product structure, configuration rules, and relationships, but they do not instantiate those elements as a working environment for change. Instead, engineers are asked to reconstruct context repeatedly: which parts are affected, which variants are in scope, which alternates are valid, and which downstream systems are impacted.

A working context for change should not be a document or a reference. It should be a live environment that contains the relevant slice of the product definition and that persists for the duration of the change. Without this, every discussion starts from scratch, and every summary risks losing nuance.

This realization has shaped how change is approached in OpenBOM. Instead of treating change as a form to be filled out, the system creates a workspace that already contains the relevant product context. Engineers do not need to explain what they are working on; the workspace makes it explicit.

Where Change Actually Lives

An OpenBOM collaborative workspace, often described as a BOM sandbox, is a controlled environment where product structures can be explored and modified without impacting released data. In OpenBOM it is called “Latest” state. It is created from real product definitions and remains connected to the underlying data model. It is a space where everyone can make changes without affecting the released baseline. 

What matters for change management is not isolation alone, but persistence. The workspace becomes the place where edits, discussions, and decisions accumulate over time. Structural changes, alternates, cost adjustments, and comments are captured in context. Tasks and responsibilities are attached directly to the product elements they concern, rather than floating in external tools.

This shifts the role of the ECO. Instead of being the container for change, the ECO becomes the result of work done in the workspace. The workspace holds the reasoning; the ECO records the outcome.

Parallel Is the Default, Not the Exception

Real change work is collaborative by necessity. Mechanical, electrical, manufacturing, procurement, and quality perspectives intersect, often asynchronously. A system that forces all of this into a single linear workflow either blocks progress or encourages workarounds.

Collaborative workspaces support a different model. Changes can be isolated when needed, allowing engineers to explore alternatives without interference. Parallel changes can exist side by side, supporting competing solutions or fast-track fixes alongside longer-term redesigns. At the same time, shared snapshots allow teams to bring their work together for review when alignment is required.

The system does not assume a single path. It supports branching and convergence as normal behavior rather than as exceptions. This alone reduces friction, because engineers no longer need to hide unfinished work to avoid disrupting others.

Why Agents Need Time, Not Prompts

Once change has a stable home, the role of AI changes fundamentally. Instead of being asked to answer isolated questions, AI can operate as a long-running assistant that observes how change evolves over time. This distinction matters. Chat-based interactions are session-based, while change management is time-based.

A long-running AI agent embedded in a collaborative workspace can track what has changed, why it changed, and what questions remain open. It can monitor consistency across structures and configurations, flag missing information, and prepare summaries that reflect the current state rather than a snapshot from days earlier. Importantly, it can do this without requiring engineers to restate context repeatedly.

The agent does not replace engineering judgment. Its value lies in reducing coordination overhead and preserving context that would otherwise be lost.

Control Without Freezing Progress

Introducing AI into change management raises legitimate concerns about control and trust. The answer is not to avoid automation, but to design clear boundaries.

In OpenBOM, the separation between exploration and release provides a natural governance model. Workspaces allow reversible experimentation, while promotion to released structures is a deliberate and controlled action. Permissions determine who can propose changes, who can review them, and who can finalize them. Every edit and discussion is recorded, creating an audit trail that reflects not only what changed, but how the decision was reached.

AI agents operate within these boundaries. They can propose, summarize, and highlight risks, but irreversible actions remain gated. This mirrors how experienced engineers already work: exploring freely, then slowing down when consequences become real.

An ECO That Emerges, Not Executes

Consider a common scenario: a supplier notifies the team of a looming component shortage. The initial signal is vague, but the risk is real. Instead of immediately opening an ECO, a workspace is created that contains the affected BOM context. Engineers add potential alternates, procurement contributes lead-time and cost information, and manufacturing reviews compatibility.

As this unfolds, a long-running agent tracks the evolving picture. It notes which alternates meet requirements, where cost deltas appear, and which configurations are affected. It highlights unresolved questions and prepares a clear summary when the team is ready for review.

Only when the team converges does the formal ECO emerge, derived from the workspace. The ECO reflects a decision that has already been explored, documented, and understood. Downstream systems receive a clean, precise change, while the reasoning remains available for future reference.

From Change Records to Product Memory

The long-term value of this approach extends beyond individual changes. When reasoning, alternatives, and constraints are captured as part of the change process, they become part of the product’s memory. Future teams can see not just what was changed, but why certain paths were rejected. AI systems, in turn, have access to grounded context rather than guessing intent from final states.

This is where agentic change management connects to broader discussions about product memory and AI-ready data. AI becomes useful not because it is autonomous, but because it operates on a rich, structured record of human decision-making.

Conclusion: The Real Opportunity To Transform ECO Process

Agentic ECOs do not require abandoning governance or embracing fully autonomous systems. They require acknowledging that change is a collaborative, time-based process and giving it a proper home. A collaborative workspace provides that home. Long-running AI agents become practical once they have persistent context and clear boundaries.

The opportunity is not to make ECOs faster, but to make change work more coherent. When context is captured as it forms, coordination becomes cheaper, decisions become clearer, and AI finally has something meaningful to work with.

We are embarking on the process to re-think change management and invite you to join the discussion. We have a limited space for design partnership with companies that want to work with us on the ideas of new change management processes using AI. 

Contact us and we would be happy to discuss more.

Best, Oleg