Software Gets Cheap Consequence Does Not

Michael Carroll | The One-Degree Dispatch | Industrial AI and Software Architecture Software Gets Cheap. Consequence Does Not. As reasoning platforms absorb workflow, code, visualization, and application logic, the industrial software market will be repriced around the few things customers cannot safely build for themselves.

By Michael Carroll Founder, The One-Degree Dispatch | Industrial Transformation Leader | Advocate for Agentic AI and Automated Reasoning

Lead image. The software portfolio review becomes the place where the old category model starts to look less like protection and more like a bill for separation. The renewal review does not begin as a revolt. It begins with a spreadsheet open beside a software portfolio, the kind every large industrial company now carries because the systems that were supposed to make work easier have become a second operating structure of their own. ERP maintenance. MES support. PLM renewal. CAD seats. Historian costs. Connected worker licenses. Quality modules. Maintenance systems. Integration spend. Analytics tools. Digital twin subscriptions. Workflow software. AI add-ons now attached to applications that were already expensive before they learned to speak. The CIO is not careless. The CFO is not cheap. The COO is not nostalgic for clipboards and hallway decisions. The engineering leader is not trying to protect old habits. Each person at the table has a defensible concern. The ledger must remain official. The product record must remain controlled. The plant cannot be governed by improvised code. A bad action near the process can injure people, damage equipment, contaminate product, violate compliance, break customer trust, and show up later in a place where no software vendor will be standing beside the operator who approved it. Still, the question has changed. It no longer sounds like a procurement question. It sounds like an exposure. Why is the company still buying so many separate categories of software when so much of the work inside those categories is now beginning to look like generated logic, API movement, workflow assembly, documentation, search, routing, reporting, display, and human reconciliation? That is the question the old market does not want asked too clearly. The company may still need the function. It may not need the category. It may still need product truth, but not PLM as a large workflow fortress. It may still need production authority, but not every screen and report that grew around MES. It may still need worker guidance, but not connected worker as a separate software kingdom. It may still need visualization, but not every digital twin product sold as if the mirror itself were the work. It may still need ERP, but not ERP as the forced path through which every person must move to make the business official. The crack appears first in the place everyone trusted because it was humble. Excel. The engineer’s tool of choice was never only a spreadsheet. It was where belief went when the enterprise system could not reason with uncertainty. Assumptions were placed in cells. Scenarios were built across tabs. Data was exported from three systems, reconciled by hand, and turned into a working model of what someone thought was true. Excel became the unofficial theater where belief, evidence, and action were negotiated before the official system was touched. Now a reasoning system can do much of that differently. It can hold the assumption, test the logic, build the model, inspect the evidence, ask what is missing, create the visualization, write the code, call the API, draft the workflow, and explain why the proposed action should or should not be allowed. The spreadsheet is not gone. It is demoted. It becomes one possible surface of output, not the place where the reasoning must live. That is the beginning of the market break. The category was the moat. The function is what the customer actually needed.

This is not an argument that enterprise software disappears. That would be easy to say and wrong. It is an argument that the category structure begins to fail. ERP, MES, PLM, QMS, EAM, CAD, SCADA, historians, connected worker, digital twins, BI, workflow, planning, and customer systems became separate categories because software was hard to build, integration was hard to maintain, and people had to carry context between systems. The category had a budget owner, a user interface, a workflow, a permission model, a support contract, and a vendor moat. That arrangement made sense when software was scarce. Software is no longer scarce in the same way. The scarce thing is now architecture. Not architecture as diagrams. Not architecture as governance theater. Architecture as the living structure that determines what the company knows, what it believes, what it can prove, what it may change, who has authority, what must remain official, what can be generated, what must be bought, what can be automated, what must be reviewed, and what consequence the system is allowed to shape. When code gets cheap, the application is no longer the rare asset. The rare asset is the architecture of consequence.

Supporting image. The first break in the old software market is not the software bill itself. It is the moment leaders see how much judgment still sits between categories. The old software market sold categories because customers could not carry functions themselves Enterprise software did not become fragmented because buyers were foolish. The problems were real. Finance needed an official ledger. Operations needed execution records. Engineering needed product definition. Quality needed disposition and evidence. Maintenance needed asset history. Supervisors needed process visibility. Workers needed instructions. Customers needed commitments. Each function required software that could be built, deployed, maintained, secured, supported, validated, taught, and governed. So the market gave each function a category. A company did not simply need controlled product memory. It needed PLM. It did not simply need to execute production. It needed MES. It did not simply need to guide workers through safe work. It needed connected worker. It did not simply need to represent state, projection, and expected consequence. It needed a digital twin. It did not simply need financial truth. It needed ERP. The naming made buying easier. It made analyst coverage easier. It made vendor comparison easier. It also hid the more important question. What function is this category actually carrying, and does that function still need to be bought this way? That question was hard to act on when software was expensive to create and difficult to change. If a company needed a workflow, it bought the application that contained the workflow. If it needed a report, it bought the module or asked IT to build it. If it needed a screen, it accepted the vendor interface. If it needed a cross-system answer, people exported data, rebuilt context in Excel, reconciled fields, argued over definitions, and carried the result into a meeting. The vendor category remained defensible because the cost of building around it was high enough to make the category feel inevitable. Claude-like systems, internal skills, plugins, code generation, governed APIs, and reasoning platforms change the economics underneath that inevitability. The marginal cost of creating application logic falls. The cost of designing the right architecture does not. A company can now generate screens, workflows, summaries, reports, APIs, code, documentation, visualizations, and local applications far faster than the old software economy assumed. But speed of creation does not answer whether the thing created should exist, what it should be allowed to touch, what evidence it should trust, or who owns the bill when it acts. This is why the first wave of enthusiasm around cheap software will be dangerous. A weak company can create software sprawl faster than it could ever buy it. A strong company can use the same technology to remove category dependence and carry more of its operating intelligence itself. The difference is architecture. Cheap code without architecture becomes the new spreadsheet sprawl, only more convincing, more connected, and closer to consequence. The old application had one accidental virtue. It constrained the company. Sometimes badly, sometimes expensively, sometimes in ways that made work absurdly slow, but it constrained the range of action. When a reasoning system can create software on demand, the constraint moves from the vendor application to the customer’s own architectural discipline. The company has to know what should be built, what should be forbidden, what should remain official, what can only recommend, what can write back, what requires human judgment, and what must stop. That is why software becoming cheap does not reduce the need for architecture. It raises the price of not having it. When software gets cheap, architecture becomes the scarce asset.

The old make-versus-buy question asked whether a company could build an application more cheaply than it could buy one. That is no longer enough. The new question is which functions should remain bought because they carry specialized, consequence-bearing trust, and which functions should be owned because they express the company’s own context, judgment, permission, and operating intelligence. A manufacturer should not casually build its own safety control platform, financial ledger, certified control system, or high-fidelity physics engine. It may still buy CAD kernels, simulation engines, historians, industrial cybersecurity, identity infrastructure, cloud services, control platforms, regulated records, OEM support, and specialized engineering tools. But it should hesitate before buying the architecture of its own judgment from a vendor whose economics depend on keeping that judgment trapped inside a category. Companies do not want to buy the things that define how they think. They do not want a vendor to own how they define evidence, how they trade risk, how they permit action, how they connect product to plant to customer to finance, how they learn from outcomes, or how they decide what must become true. Those are not software features. They are the company’s operating intelligence.

Lead figure: The category can weaken even when the function remains essential. The new economic test is whether the function still requires a standalone buying category. The category breaks when the platform can carry the function The next industrial platform is not just another integration layer. It is not simply a data lake with better language. It is not a chatbot attached to a workflow. It is not a low-code tool with a more fluent interface. If it is serious, it carries customer-owned context, enterprise ontology, product memory, asset memory, process memory, evidence standards, permission rules, decision rights, API orchestration, skills, plugins, code generation, visualization surfaces, workflow generation, simulation, audit, writeback, and learning. That kind of platform does not replace every system. It changes what every system is for. The ERP may remain the official economic record. The platform carries the work around planning, variance explanation, procurement reasoning, approval preparation, and customer promise. The PLM system may remain the product authority. The platform carries change-impact reasoning, requirements comparison, supplier communication, and lifecycle workflows. The MES may remain the production record. The platform carries schedule reconciliation, crew handoff, exception handling, and production narratives. The QMS may remain the quality authority. The platform carries deviation packet creation, containment reasoning, and evidence assembly. The historian may remain the trusted time-series memory. The platform carries explanation, comparison, anomaly reasoning, and visualization. The function remains. The category weakens. This is where skills become the new applications. A PLM skill assembles a change package. A quality skill builds a deviation record. A maintenance skill reasons through deferral risk. A production skill reconciles schedule and line state. A connected-worker skill generates safe guidance at the edge. A digital mirror skill shows current condition and expected consequence. An ERP skill prepares a permitted writeback. A customer-promise skill tests whether the company can make a commitment without borrowing from quality, inventory, or maintenance in a way the ledger cannot see. These skills are not standalone applications in the old sense. They are executable capabilities inside a governed platform. They use vendor systems when vendor systems hold protected truth. They use internal context when the company’s own operating logic matters. They generate software when software is needed. They do not force the company to buy another category every time the work crosses a boundary. That is why the category structure becomes vulnerable. The old market sold containers. The new platform carries capabilities. Then the market put a price on the control point Then the market gave the argument a live object. Autodesk, the company whose name still carries AutoCAD in the industrial memory, announced a definitive agreement to acquire MaintainX for approximately $3.6 billion. MaintainX is expected to exceed $135 million of annualized recurring revenue in calendar 2026. On ordinary software math, that is a large number to pay for a maintenance and operations company. It is large enough that the first market response had reason to be skeptical. That skepticism matters. A premium is not proof of wisdom, and a strategic explanation is not the same thing as integration success. MaintainX still has to be folded into a larger company without losing the frontline simplicity that made it useful. Autodesk still has to prove that the operating evidence created by inspections, work orders, asset histories, and maintenance patterns can strengthen the broader platform rather than become another product layer with a new logo. The deal could disappoint, and that possibility is part of the discipline. But if MaintainX is judged only as a CMMS, EAM, or connected-worker application, the transaction is being read in the old market language. The more important question is what a strategic buyer believes the asset makes possible inside a platform. Autodesk already has a powerful position in design, engineering, construction, manufacturing, simulation, and digital representation. MaintainX gives it a stronger route into the operating life of the asset, where design intent is tested by maintenance, inspection, failure, repair, use, downtime, and field evidence. That is why the deal belongs near the front of this article, not as a footnote to valuation. It puts a public price on the missing distance between what was designed, what was built, and what actually happens after the asset is placed into service. A work order is not merely documentation when it becomes operating memory. An inspection is not merely compliance when it becomes evidence. Maintenance history is not merely a record when it helps a platform understand how the asset behaves over time. A financial buyer can value MaintainX as a high-growth software company. A strategic buyer asks a harder question. What can this asset let the platform know, reason over, and make useful that it could not know as well without it? If the answer is only workflow, the multiple is exposed. If the answer is operating evidence that connects design intent to asset reality, then the deal is less about buying a category and more about buying a control point. A deal does not rewrite the Purdue stack. It tells us where a strategic buyer has started looking. The signal is not that every software company is worth more because AI is coming. It may be the opposite. Ordinary applications become less valuable when reasoning platforms can carry their functions. A small number of assets become more valuable when they sit where work becomes evidence and evidence can become permitted action. That keeps the argument honest. Autodesk may be early, right, early and wrong, or simply willing to pay more than a financial buyer would pay because the asset completes something larger. But the acquisition makes the capital question visible. The market is beginning to separate applications from control points, and it is beginning to ask which categories are containers and which ones sit at the place where consequence is made observable. The distinction between category, capability, and consequence becomes the economic map. A category is how the vendor sold the market. A capability is the actual function the enterprise needs. Consequence is what makes the function dangerous to self-perform. A category becomes vulnerable when the capability can be recreated inside a platform and the consequence risk is low enough to govern. A category remains protected when the function touches physics, safety, official records, regulated release, financial truth, deterministic control, cyber exposure, uptime, liability, or third-party trust. That means the repricing will not follow the names on the software invoice. It will follow consequence. The repricing will not follow software categories. It will follow consequence.

The functions most exposed are the ones that mostly help people move through software. Forms, screens, static dashboards, report packs, workflow routing, approval packet creation, meeting preparation, exception summaries, SOP retrieval, training content, search, basic analytics, variance narratives, ECO documentation, supplier communication packets, connected-worker checklists, local apps, role-based views, transaction guidance, data comparison, and manual reconciliation all sit close to the surface of application logic. These were valuable when they were hard to build and hard to integrate. They are less defensible when a reasoning platform can create them, govern them, and retire them when the work changes. The functions most protected are the ones that define whether action can be trusted. Deterministic control, safety-rated systems, industrial cybersecurity, identity, time-series integrity, official financial record, regulated batch record, quality disposition authority, released engineering configuration, authoritative geometry, simulation solvers where physics matters, master data governance, validated compliance records, audit history, uptime guarantees, liability-bearing support, embedded firmware, and certified change control do not become free because code can be generated. They become more important because cheap code increases the need for trusted boundaries. The vendor community needs to see this before end users force it. The customer does not stop needing capabilities. It stops accepting the category wrapper as the natural unit of value. The vendor that defends the wrapper will sound increasingly like it is protecting its revenue model rather than the customer’s consequence. The vendor that exposes the protected core, opens governed pathways, and allows the customer’s platform carry more of the work may become more important than it was before. This is the hardest part for investors and boards that finance these vendors. Revenue that looked durable because a category was embedded may actually be exposed because the category carries too much workflow and not enough protected consequence. Installed base is not the same as future pricing power. A system may be hard to rip out and still be easy to surround. The customer does not have to remove the castle if the work can move around it.

Figure 2: The skill does not replace the need for control. It changes where the application function lives and who governs it. The Purdue stack becomes a pricing stack

Supporting image. Near the asset, the question is not whether software can be written. It is whether the action can be trusted when physics answers back. The Purdue model was never a mistake. It gave industry a disciplined way to separate physical process, control logic, supervisory systems, operations systems, and enterprise systems. That separation existed because physical consequence is different from administrative consequence. The plant should not be treated like an office network with larger machines. A command near a process does not carry the same risk as a field in a report. That same structure now helps explain where vendors remain protected and where categories are exposed. The closer one moves to the asset, the more vendors survive because specialty, physics, validation, certification, deterministic control, hardware, uptime, and liability matter. The farther one moves toward enterprise context, workflow, judgment, decision logic, customer promise, and cross-system reconciliation, the more customers will want to own the architecture and self-perform the application layer. At Level 0, the physical process remains stubbornly real. Machines, materials, sensors, actuators, drives, instrumentation, robotics, process equipment, and field hardware do not become free because a reasoning system can write code. The company does not want to build these things unless building them is its business. It wants OEM expertise, calibration, durability, service, safety, warranty, and engineering depth. The platform can interpret, monitor, visualize, and reason about physical conditions. It cannot repeal physics. At Level 1, control logic remains strongly protected. PLCs, DCS, RTUs, interlocks, safety systems, control configuration, and deterministic execution require engineering discipline. AI can help document logic, compare versions, generate tests, simulate change impact, explain dependencies, and support management of change. It should not casually rewrite control logic near physical consequence. The vendor survives where safety, deterministic behavior, engineering tools, and certified execution matter. The customer owns the permission boundary, change authority, safety rules, and judgment about when intervention is legitimate. Level 2 begins to split. SCADA, HMI, historians, alarm systems, and industrial connectivity remain valuable where trust, fidelity, uptime, and operator safety matter. Operators need reliable signals. Time-series integrity matters. Alarm integrity matters. Cyber boundaries matter. But static HMI views, routine alarm summaries, trend interpretation, crew notes, and basic event narratives become more exposed. A reasoning platform can ask the historian questions, compare patterns, generate visual overlays, and produce explanations. The vendor survives where the system must be trusted in operation. The platform carries much of the interpretation. Level 3 becomes the battleground. MES, MOM, QMS, EAM, LIMS, WMS, connected worker, maintenance systems, quality systems, operating procedures, production records, work instructions, and scheduling tools sit close enough to know constraint but far enough from deterministic control to shape broader operating choices. This is where companies spend enormous hidden capacity reconciling schedule, quality, labor, material, asset state, yield, service, and risk. It is also where many software categories contain the most exposed work. Routing, exception handling, evidence gathering, deviation packets, status reports, crew handoffs, connected-worker forms, and schedule reconciliation are all vulnerable to platform absorption. The protected part of Level 3 is real. Regulated batch records, production genealogy, quality disposition authority, maintenance history, asset criticality, controlled procedures, compliance evidence, and official operating records remain important. The exposed part is the administrative and cognitive burden that grew around those records. A company may still buy a production record core, a quality record core, and an asset history core. It will increasingly question why it needs separate categories for every workflow that touches those records. Level 4 remains protected as official truth and exposed as forced interface. ERP, finance, procurement, planning, inventory, orders, tax, master data, controls, and compliance remain essential. Business must be made official somewhere. The company needs a ledger. It needs legal entity structure. It needs financial close discipline. It needs an audit trail that survives examination. But menu navigation, transaction guidance, variance commentary, approval routing, report creation, planning preparation, procurement workflows, and status lookup become increasingly vulnerable. The platform can carry the interface. ERP keeps the official record. The design and product layer follows the same rule, though it does not fit neatly inside Purdue. CAD, CAE, simulation, PLM, product configuration, requirements, engineering release, supplier specifications, and design visualization all carry consequence. But they do not carry it equally. CAD has a stronger protected center because geometry, spatial truth, manufacturability, tolerance, fit, assembly, and simulation still need inspectable representation. PLM has protected product memory, but much of the category is workflow around that memory. That difference matters. Customer-facing systems split as well. Pricing authority, customer commitments, warranty exposure, regulated claims, contract terms, and service obligations remain protected because the company is binding itself. Status updates, exception narratives, quote preparation, promise-date explanations, service summaries, and routine communication are more exposed. The platform can communicate if it knows the operating truth and the permission boundary. It cannot be allowed to promise what the company cannot make true. This is the new gradient. Closer to the asset, vendors retain more power because consequence is physical, specialized, and certified. Closer to enterprise context, customers want more ownership because the function expresses how they think, decide, trade risk, and make commitments. The old software category map does not show that gradient. The Purdue stack begins to.

Figure 3: The stack is not only an architecture of separation. It becomes a practical test of which functions vendors can defend and which functions customers will absorb. The closer software gets to consequence, the less free it becomes.

PLM is the exposed category because product truth cannot disappear

Supporting image. Product truth still needs a mirror. CAD, simulation, and visualization survive where people must see consequence before it becomes physical. PLM is the category most likely to reveal how much of the old market was workflow rent wrapped around protected truth. Product lifecycle management sounds too important to be vulnerable. Product truth cannot disappear. A company must know what product is released, which revision is official, which BOM governs, which supplier part is approved, which requirement applies, which drawing controls, which change was authorized, and which compliance record proves it. That is not paperwork. It is the memory of what the company has agreed to make, sell, support, and defend. That is exactly why PLM is vulnerable. When a category wraps something sacred inside a great deal of administrative burden, the sacred part does not protect the burden forever. Product memory remains. Released configuration remains. Requirements traceability remains. Engineering signoff remains. Compliance evidence remains. But ECO packet preparation, routing, document search, status reporting, dependency summaries, supplier notifications, requirements comparison, review preparation, and impact explanation are all exposed to reasoning platforms. The platform does not need to replace product truth to reprice PLM. It only needs to surround the workflow and make much of the old interface unnecessary. PLM survives where it becomes trusted product memory. It weakens wherever it remains rented workflow. That sentence should matter to every PLM vendor, every industrial buyer, and every investor underwriting the category. If the vendor’s value is mostly that the product record is trusted, the vendor can remain important. If the value is mostly that people are forced to move through the vendor’s workflow to keep product truth alive, the category has a problem. The customer will increasingly ask whether those workflows can become skills inside a customer-owned architecture. A PLM skill can assemble a change package, identify affected parts, compare requirements, draft supplier communication, inspect downstream production impact, prepare review views, and request signoff from the right authority. The official product record may still sit in a bought system. The reasoning around that record may increasingly sit in the customer’s platform. That is the economic break. The record remains bought. The work around the record gets self-performed. CAD is different, but not immune. Geometry is not a memo. Design still has to be seen, manipulated, constrained, simulated, manufactured, and released. Engineers still need visual and geometric authority. Suppliers need drawings and models. Manufacturing needs tolerances and process constraints. Service needs access and fit. Quality needs specifications. A reasoning system may propose a design, but human judgment and engineering discipline still need a mirror through which the proposal can be inspected. That is why CAD survives better than PLM as a category, though parts of CAD work get repriced. Routine drafting, drawing cleanup, variant generation, documentation, design explanation, tolerance assistance, manufacturing notes, and early concept generation can be compressed. CAD kernels, modeling environments, simulation integration, manufacturability tools, and high-fidelity visual representation remain more protected. The distinction is not whether a system has AI. The distinction is whether the system carries geometry and consequence that cannot be reduced to workflow. Digital twins need the same treatment. The word twin has been sold too broadly. Some twins carry high-fidelity asset behavior, process physics, product geometry, simulation, and operational trust. Those remain valuable. Other twins are visual dashboards with better graphics. Those are exposed. In a reasoning platform, visualization becomes native. The system needs mirrors of what exists, what is happening now, what should happen, what the reasoning system believes, what would happen under another intervention, and what is permitted. The mirror remains. The standalone category weakens. Visualization becomes more important, not less, because reasoning systems need inspection surfaces. People must see what the system believes before they allow it to shape consequence. If the system recommends advancing a production run, deferring maintenance, releasing material, changing a supplier, accepting a deviation, altering a design, or promising a customer date, the human needs to inspect the condition the system thinks it is acting on. A visualization that makes the recommendation look polished is not enough. A visualization that exposes evidence, uncertainty, constraints, and consequence becomes part of control. The mirror remains valuable when it shows belief, evidence, and consequence.

Connected worker becomes the human edge of the platform

Supporting image. The worker remains the point where instruction becomes evidence, permission becomes action, and consequence leaves the screen. Connected worker is exposed if it remains a category of digitized instructions, checklists, forms, training content, SOP retrieval, skill matrices, and guided workflows. Those things were useful. They replaced paper, improved visibility, supported standard work, and helped frontline teams in settings where systems were disconnected and work was hard to see. But they also created another category, another interface, another data model, another implementation, and another claim on the worker’s attention. A reasoning platform asks the harder question. If the platform knows the worker, the asset, the procedure, the current condition, the risk class, the quality requirement, the worker’s authorization, the safety rule, the evidence that must be captured, and the exception path, why does the company need a separate connected-worker category for much of that work? The platform can generate the instruction, adapt it within permitted boundaries, retrieve the procedure, capture evidence, recognize when the work is no longer routine, and escalate when judgment is required. The worker still matters. More than ever. But the software category changes. The surviving value is the governed human touchpoint where instruction, evidence, permission, safety, exception, and learning meet at the moment of work. The tablet is not the product. The checklist is not the product. The product is the permissioned connection between human judgment and operating consequence. That has to be said carefully because connected worker touches safety. A bad instruction at the edge is not a bad report. It can become an injury, a quality escape, asset damage, contamination, regulatory exposure, or customer harm. The reasoning platform must not personalize standard work into unsafe variation. It must know where adaptation is allowed and where it is forbidden. It must preserve procedure discipline where procedure discipline protects people and product. It must capture evidence while work happens, not after memory has been converted into a form. The same logic applies to maintenance. The platform can inspect asset history, current condition, vibration trends, work orders, parts availability, schedule pressure, production need, safety risk, and cost. It can recommend repair, deferral, inspection, shutdown, or run-to-failure analysis. But the decision is not merely a workflow. It is an intervention with consequence. Vendors may still own asset record cores, OEM expertise, condition monitoring tools, reliability models, and specialized equipment knowledge. The customer should own the operating logic that decides when risk can be accepted. Quality follows the same pattern. A company still needs controlled specifications, sampling plans, batch records, deviation history, disposition authority, inspection evidence, and compliance records. It cannot let a model release product because the narrative sounds convincing. But quality routing, deviation packet assembly, containment options, supplier notification drafts, root-cause summaries, and review preparation can be carried by a platform. QMS survives where it carries quality authority. It weakens where it carries administrative traffic. This is what many vendors will not want to confront. The customer does not stop needing connected work, maintenance reasoning, or quality control. It stops accepting the standalone category as the default container. It wants the function carried inside the architecture that already knows the worker, the asset, the product, the order, the customer, the policy, and the permission boundary. ERP survives as record, not as the shape of work ERP will not disappear because money must be official. Orders, invoices, inventory, procurement, tax, cost, financial close, legal entity structure, compliance, and master data require discipline. A company cannot run its financial truth through a collection of improvised applications. The ledger exists because the business must be able to prove what it did. Banks, auditors, regulators, boards, suppliers, and customers all depend on that proof. But ERP as the forced work interface is exposed. If a planner wants to know whether a supplier constraint should change the schedule, the value is not in clicking through screens. If a controller wants to know why margin moved, the value is not in exporting reports and rebuilding the story in Excel. If procurement wants to know whether a material substitution is safe, available, approved, economical, and customer-compatible, the value is not in moving from ERP to PLM to QMS to supplier email to meeting. The value is in forming a permitted action from evidence that crosses systems. Application-native AI will help. It will make ERP easier to use. It will make PLM easier to search. It will make QMS easier to summarize. It will make CAD easier to interrogate. It will make MES easier to use. Each improvement may be real. But the operating burden does not live cleanly inside one application. It lives where customer promise meets supplier availability, product configuration, quality risk, asset condition, production capacity, labor, inventory, cash, and service obligation. If every assistant remains trapped inside its category, the human remains the cross-system platform. The system of record says what has been made official. It does not, by itself, decide what should be made true next. That decision depends on objective, question, evidence, causal reasoning, authority, risk, reversibility, and accountability. A company trying to improve service while reducing working capital cannot get there by making ERP screens easier if the signal still appears in one system, evidence sits in another, authority sits in a meeting, and action arrives after the cost is already in the ledger. This is where incumbent walls become contested. Vendors have legitimate reasons to restrict uncontrolled agentic access. No serious buyer should want agents scraping, bypassing, extracting, or writing through undocumented paths. Regulated records and industrial systems cannot become playgrounds for clever integration. But the wall becomes suspect when it prevents governed movement and calls that prevention safety. Customers are not asking for open chaos. They are asking for governed relief from the human burden of crossing systems that were never designed to reason together. A customer-owned context layer becomes necessary because no single vendor should define enterprise context only inside its own product. Operating intent, decision rights, evidence standards, risk classes, escalation rules, reversibility rules, customer promise logic, and causal journals belong to the enterprise. They may rely on vendor systems. They should not be imprisoned by them. The system of record survives. The forced interface weakens.

The strongest incumbents will understand this. They will expose richer events, permission hooks, audit trails, semantic context, and governed writeback pathways. They will accept that some intelligence will sit above the application and that being trusted inside that architecture may be more valuable than forcing every future action through the old interface. The weaker incumbents will defend the category because the category is where their economics live. They will protect the route to work and call it safety until customers can measure the cost of that protection.

Figure 4: The old make-or-buy line was application cost. The new line is whether the function carries external trust or internal operating intelligence. End users need a new buying logic Industrial buyers have to stop buying software as if category names answer operating questions. They need to buy according to consequence, not according to market taxonomy. That requires a harder conversation than procurement usually owns. It requires operations, finance, engineering, IT, quality, legal, cyber, and the business to ask what the function actually does, what it is allowed to touch, what proof it must preserve, and whether the platform can safely carry it. The first question is not whether the company needs PLM, MES, connected worker, digital twin, QMS, EAM, or BI. The first question is what condition the company is trying to make true. Faster product change. Lower working capital without service failure. Better quality. More reliable assets. Safer work. Faster order fulfillment. Stronger customer promise. More resilient supply. Better learning. The objective creates the question. The question determines what data can become evidence. The evidence supports the causal model. The causal model determines what intervention might change the condition. The software is useful only if it helps that chain become real. That changes the buying test. Does the software carry a protected record the company cannot safely build? Does it provide certified capability, specialized engineering, uptime, security, regulatory support, or third-party trust? Does it hold official truth? Does it improve the evidence required for action? Does it reduce the distance between signal and permitted intervention? Does it preserve human judgment where accountability belongs? Does it help the system learn from outcomes? Or does it mostly add another interface, another workflow, another reporting path, another reconciliation layer, and another vendor boundary around work the platform should carry? End users have to become more demanding. A vendor should be asked which part of its product is protected consequence and which part is workflow. Which functions are records, controls, proofs, or certified capabilities? Which functions are screens, forms, routing, summaries, reports, and administrative movement? Which APIs allow governed access? Which writebacks are supported? How is permission handled? What evidence is logged before action? What happens when the platform recommends but the vendor system owns the record? Can the customer control context and decision rights, or must all intelligence remain inside the vendor’s product? The useful life of software also changes. When application logic was expensive, companies tolerated long life cycles and slow change because the cost of replacement was high. When generated software can create new workflows, screens, skills, and tools quickly, the value life of interface-heavy software shortens. A workflow bought today may be obsolete before the contract has finished depreciating. A static dashboard may have less life than the question it was built to answer. A connected-worker form library may lose value if the platform can produce governed instruction from live context. Buyers should stop treating all software assets as equally durable. This does not mean companies should shorten every contract or avoid large systems. It means they should separate durable value from temporary shape. A financial ledger may have long durability. A control platform may have long durability. A historian may have long durability. A CAD kernel or simulation engine may have long durability. A workflow around those systems may not. A user interface may not. A reporting layer may not. A point solution that digitizes an old process may not. Buying decisions should match the half-life of the value being purchased. End users should also recognize the new internal burden. If they want to self-perform more software, they need more architects. Not more people making diagrams for review. More people who can define systems of consequence. Architects who know where records live, where authority sits, where APIs can be trusted, where cyber boundaries matter, where evidence is weak, where human judgment must enter, where action is reversible, where action is not, and where software should be forbidden from acting. The company that thinks cheap code eliminates architectural talent will create a faster mess. A serious buyer should begin dividing its portfolio into bought primitives, protected records, platform-carried functions, and disposable generated software. Bought primitives are things like control systems, CAD kernels, simulation engines, historian technology, cybersecurity, identity, cloud infrastructure, and certified tools. Protected records are ERP ledgers, product configuration, batch records, quality disposition, maintenance history, and compliance evidence. Platform-carried functions are workflows, reasoning skills, visualizations, summaries, planning views, change packages, and cross-system decision tools. Disposable generated software is the local screen, report, workflow, or app created for a specific need and retired when the need changes. That buying logic will be awkward because it cuts across vendor categories and internal budgets. It will threaten established owners. It will make some software renewals look bloated and some underappreciated infrastructure look strategically critical. It will also make the real architecture visible. A company will see which parts of the portfolio carry trust and which parts carry habit. Vendors need to stop defending the wrapper The vendor community has a choice. It can defend category boundaries, or it can defend consequence. Defending the category may protect revenue for a time. Defending consequence may protect relevance. A vendor that provides a system of record should ask whether its future value lies in trapping more work inside its interface or becoming the most trusted authority service inside the customer’s reasoning architecture. The second path is harder because it requires opening governed pathways, improving semantic access, exposing events, supporting customer-owned context, clarifying writeback permissions, and accepting that not every workflow must remain inside the application. But that is where the market is moving. The customer wants the function. It no longer wants to inherit every boundary that came with the category. A PLM vendor should separate product authority from workflow burden before customers do it for them. Product memory, configuration control, requirements traceability, engineering release, and compliance evidence are defensible. Slow change workflows, difficult search, status reports, approval staging, and document traffic are not. The vendor that exposes product authority cleanly into customer platforms can remain central. The vendor that insists lifecycle work must remain inside its own application may find itself surrounded. An MES or MOM vendor should do the same. Production records, genealogy, traceability, batch execution, and regulated operating evidence matter. But dispatch logic, production narratives, crew handoff, exception summaries, and status reporting may be absorbed. If the vendor becomes the trusted production authority and permits governed reasoning around it, it can matter more. If it tries to own every action because every action once passed through MES, it becomes a bottleneck. A connected-worker vendor should stop selling forms as if forms are the future. The future is the human edge of permission. That means identity, skill, procedure, condition, hazard, evidence, exception, and learning. If the vendor can make frontline work safer, more reliable, more auditable, and better connected to the operating platform, it has a role. If it is mainly digitizing checklists, the platform will absorb it. A digital twin vendor should decide whether it sells a specialized mirror of consequence or a visual category that can be recreated. High-fidelity physics, asset behavior, product geometry, process simulation, and trusted operational state remain valuable. Decorative visualization, static scenes, and disconnected dashboards weaken. The mirror survives when it helps people inspect belief, evidence, and consequence. It weakens when it merely displays a world the platform can already reason about. ERP vendors face a harder but more protected position. Their records are deeply embedded and difficult to replace. That gives them time. It does not guarantee pricing power for the interface layer. The vendor that gives customers governed access to official economic truth can remain critical. The vendor that forces all reasoning and action through its own assistant risks giving customers local convenience while preserving the cross-system burden that created the need for the platform in the first place. The investor community should look at vendors through this lens. How much revenue is tied to protected consequence? How much is tied to workflow rent? How much depends on seat-based interaction with interfaces that reasoning systems may reduce? How much depends on reports, dashboards, routing, forms, and administrative burden? How much of the product becomes more valuable when platforms rise, and how much becomes redundant? How open is the architecture? How defensible is the record? How costly is it for customers to surround the system without replacing it? Those are not small diligence questions. They go to valuation. A vendor that protects the old category may lose the future function. Finance will have to learn the difference between software revenue and consequence revenue Autodesk is useful here because it creates a live classification problem for capital. Was MaintainX priced like an application, or was it priced like a control point in a larger platform? That question will now sit behind many industrial software valuations. It will not be enough to ask whether the revenue is recurring. Capital will have to ask what the recurrence is attached to, and whether that attachment survives when customers can surround the application without immediately replacing the record. A PLM vendor may keep the product record and lose much of the lifecycle workflow. An ERP vendor may keep the ledger and lose the interface as the primary path of work. A connected-worker vendor may keep high-trust frontline evidence capture and lose generic forms. A BI vendor may keep visualization capability and lose static dashboards. An MES vendor may keep production authority and lose much of the reporting and reconciliation traffic. The contract may not disappear immediately. The pricing story changes first. Investors will need to separate four kinds of software revenue that currently look too similar on a spreadsheet. Some revenue is attached to protected primitives. Some is attached to protected records. Some is attached to exposed workflow. Some is attached to interfaces that may soon be generated. These are not the same asset. A protected primitive may deserve durability. A protected record may deserve patience. A workflow may deserve suspicion. A generated interface may deserve almost no premium at all. The danger is that all four currently appear as software revenue. That is how repricing surprises markets. The income statement does not label workflow rent as workflow rent. It arrives as subscription revenue, maintenance, seats, modules, services, and expansion. The customer’s operating frustration arrives somewhere else, as integration cost, manual reconciliation, delayed action, premium freight, meetings, rework, inventory buffers, and management attention. The vendor sees retention. The customer sees a bill that no longer matches the value. At some point the customer becomes more willing to surround, compress, or self-perform. Private equity and venture investors should also reconsider the roll-up logic. Buying several workflow-heavy industrial software categories may look like building a suite. It may actually assemble exposed functions that a reasoning platform will carry natively. The question is not whether the markets sound adjacent. The question is whether the acquired products own protected consequence or merely own work that used to require a separate application. A suite of exposed categories is not safer because it has more categories. It may simply have more surface area to be repriced. The better investment thesis will look for companies that own trusted primitives and can live inside customer-owned reasoning platforms. Control. Cyber. Identity. Historian fidelity. Simulation. CAD kernels. Product authority. Regulated records. Compliance evidence. High-fidelity visualization. Asset-specific intelligence. Safety-rated capability. Systems that know how to expose trust without surrendering control. These may not always look as glamorous as the newest AI application. But when software gets cheap, trusted primitives become more valuable. This also changes services. System integrators, consultants, and implementation partners built large businesses around the difficulty of connecting categories. Some of that work gets compressed by reasoning systems and code generation. But the need for architecture, validation, cyber, permission design, process redesign, and change discipline increases. The services market does not disappear. It moves away from configuration labor and toward architecture of consequence. The firms that can help customers decide what to buy, what to own, what to generate, and what to forbid will matter. The firms that only wire old categories together will be repriced with them. The strongest counterargument is not wrong The strongest objection to this argument is that large companies have heard the promise of internal software freedom before, and many were burned by it. Custom applications multiplied. Shadow IT grew. Data definitions drifted. Local workflows diverged. Security teams lost visibility. Business units built tools that nobody maintained. People left, and their logic left with them. The result was often a second software estate under the official one. That history should not be dismissed. It is the reason the argument must be disciplined. Cheap software does not justify careless self-performance. It makes careless self-performance more dangerous. When software generation becomes easier, architecture, governance, testing, permission, audit, and support become more important, not less. The enterprise cannot replace vendor lock-in with internal chaos and call it progress. There is another fair objection. Vendors carry knowledge customers often underestimate. Industry patterns, regulatory updates, hardened security, uptime, support, domain depth, and failure history matter. A company that builds because it can may discover too late that the bought product carried institutional memory it did not know how to replace. Some categories exist because customers tried to self-perform and failed. That is true. It will remain true. The answer is not to build everything. The answer is to understand what is being bought. Buy what is hard to trust yourself with. Buy what others must trust. Buy what must be certified, supported, audited, secured, and maintained at a level the company cannot reasonably match. Buy the tools that carry physics, safety, financial truth, product authority, compliance, and specialized depth. But do not confuse those with every workflow, screen, report, routing path, and interface that grew up around them. There is also a human counterargument. People need visible tools. They need work surfaces. They need ways to understand what the system is doing. They need training, routine, trust, and a place to go. If everything becomes generated through a reasoning platform, the work may become opaque. That risk is real. It is why visualization does not disappear. It is why digital mirrors matter. It is why judgment-in-the-loop is stronger than human-in-the-loop. The human should not merely approve a machine-shaped answer. The human needs to inspect evidence, understand uncertainty, see consequence, and have authority to dissent. That is the moral limit of the platform. It cannot become a new invisible bureaucracy made of generated software. If the old problem was that humans had to move through too many applications, the new problem could become that humans cannot see how the platform formed the action. The winning architecture will not hide complexity behind fluency. It will expose the right complexity at the right moment so judgment can survive. The coming market will punish the wrong kind of AI Many vendors will respond to this transition by adding AI to the existing product and calling it a strategy. In some cases, that will help. A good assistant inside CAD, ERP, PLM, QMS, MES, or EAM can reduce burden. It can make search better, documentation faster, reports easier, and workflows less painful. These improvements matter. They do not necessarily defend the category. The wrong kind of AI makes the old application easier to tolerate. The right kind of architecture asks whether the application still needs to carry the work. That is a much harder question for vendors because it attacks the basis of category economics. If the vendor’s AI only makes its own interface more convenient, it may improve local productivity while preserving cross-system latency. If the customer’s platform carries context across systems, the vendor’s assistant becomes one helper inside one house. The customer’s burden lives in the street between houses. The test is operational. When a material exception appears, how long passes between the first trustworthy signal and the first permitted intervention? How many systems must be touched? How many people translate context? Which system holds the record? Which person holds the authority? Which meeting becomes the decision point? Which cost appears because evidence and permission were separated? If AI improves search but those answers do not change, the company has not changed the operating system. It has made the old burden more fluent. By the end of 2028, this should be measurable. Companies that rely mainly on application-native assistants should show useful task productivity within domains, but weaker improvement in cross-system decision latency where product, plant, quality, maintenance, finance, supplier, and customer evidence must meet before action. If that is wrong, the evidence will appear in real cycle-time reduction across cross-system workflows, not in demo quality, prompt counts, adoption charts, or hours saved inside a single application. The embarrassing result for this argument would be clear. Local AI would have been enough. My judgment is that it will not be. The vendor that wins will not be the one with the most theatrical assistant. It will be the one whose protected function can be trusted inside the customer’s architecture. It will expose the right APIs, preserve audit, define permission, support writeback, make context intelligible, and let the customer reason across systems without corrupting the record. That vendor may sell less workflow and more trust. The revenue shape may change. The strategic importance may increase. The customer that wins will not be the one that generates the most software. It will be the one that knows what generated software is allowed to do. It will know where to buy, where to build, where to compose, where to forbid, where to require human judgment, where to demand visual proof, and where to preserve old disciplines because physical consequence has not been repealed. Cheap software without architecture becomes faster confusion.

The company becomes a software constructor, but not in the old way

For years, executives were told every company would become a software company. The phrase was useful, then it became too broad to guide judgment. Industrial companies are not trying to become software companies in the sense that they should build everything vendors once built. They are becoming software constructors in a different sense. They can increasingly describe what they want, define how it should work, generate the application logic, connect it through APIs, govern it through permission, and retire or change it when the work changes. That is a different operating model. It places architects closer to value. It makes context an asset. It makes permission a design discipline. It makes the half-life of software shorter. It makes vendor selection less about feature comparison and more about architectural fit. It makes finance ask whether the company is buying durable trust or temporary shape. It makes IT ask whether it is protecting systems or preserving vendor boundaries. It makes operations ask whether software changes the condition or only reports the consequence. The functions remain the same because the work remains. Products still have life cycles. Manufacturing still has execution. Quality still has proof. Maintenance still has assets. Workers still need guidance. Customers still need commitments. Finance still needs official truth. Engineering still needs geometry. Operators still need visibility. The fact that categories weaken does not mean the enterprise becomes simpler. It means the enterprise stops accepting the old category map as the architecture of work. This is why full-stack platforms matter. Not full stack in the consumer software sense. Full stack in the industrial consequence sense. A platform that can reason over product, asset, process, worker, supplier, customer, finance, and control-adjacent evidence can carry functions that once required separate applications. But it can only do that safely if it knows where the official record lives, what action is permitted, what evidence is sufficient, what risk class applies, what must be visualized, what can be reversed, and what must be escalated. The platform carries burden. The architecture governs burden. The human remains accountable where judgment belongs. That balance is easy to say and hard to build. It requires companies to stop treating architecture as an IT artifact and start treating it as the operating structure of agency. The architecture must define what the company can know, what it can ask, what it can infer, what it can change, and what it can learn. It must connect objective to question, question to evidence, evidence to causal model, causal model to intervention, intervention to control, control to condition, condition to outcome, and outcome back to learning. If software does not help that chain, it is only activity. This also explains why many AI pilots fail to become material. They improve a task but leave the operating condition unchanged. They summarize, search, draft, classify, and route. Those are useful actions. They are not enough if the signal still waits for authority, if evidence is still weak, if the system of record is still isolated, if governance still adds review without moving judgment closer to work, and if no one can say what outcome the system is allowed to shape. The platform must not merely accelerate mitigants. It must improve controls. A mitigant manages the consequence after the system has already produced it. A control changes the condition that makes the consequence more or less likely. Many software categories sold mitigants in digital form. More reports. More workflows. More reviews. More dashboards. More escalations. The new architecture should ask whether those things reduce the need for the same activity next time. If they do not, they are not control. They are polished burden. The future software estate will look less recognizable than the functions it carries ERP will still exist, but not in the same role. MES will still exist, but not as the single container for operating work. PLM will still exist where product authority must remain trusted, but much lifecycle work will be carried elsewhere. CAD will still exist because geometry and visualization remain indispensable, but reasoning will surround it. Digital twins will exist as mirrors of belief, state, projection, and permitted action, not necessarily as standalone buying categories. Connected worker will exist as the human edge of the operating platform, not as forms on a tablet. BI will exist as visual evidence, not as dashboard accumulation. That future will be confusing because the names may survive after the economics have changed. Vendors will still call products ERP, PLM, MES, QMS, EAM, digital twin, and connected worker. Analysts will still track categories. Procurement will still use familiar labels. But the real question will be underneath. Is this a protected function, or is this a function the platform can now carry? Does this vendor own consequence, or does it own yesterday’s packaging? Some categories will consolidate. Some will be absorbed. Some will shrink into trusted primitives. Some will become skills marketplaces. Some will become records only. Some will become API services. Some will become embedded capabilities inside larger platforms. Some will remain strong because they touch physical, financial, regulatory, or engineering consequence too directly to be casually rebuilt. The market will not collapse evenly. It will sort by trust. The end user should expect hybrid architectures. A company may keep SAP or another ERP as the financial record, Siemens or Dassault or PTC or another system as design and product authority, Rockwell or Siemens or Schneider or Honeywell or Emerson or ABB near control and automation, OSIsoft-style historian capability for time-series trust, and specialized QMS or EAM records where needed. But the work surface above those systems may become customer-owned. The skills that move across those records may be built internally or composed through a platform. The interface may become generated. The workflow may be generated. The vendor record may become a service rather than the place where the human lives. This is not science fiction. It is the practical consequence of code generation, reasoning, plugins, APIs, and platform context meeting a software estate that was built for a different cost structure. The old architecture assumed software was expensive and human reconciliation was tolerable. The new architecture assumes software can be generated and human reconciliation is the bill customers increasingly refuse to pay. That bill has been hidden because it appears in many places. It appears as integration cost for the CIO. It appears as working capital for the CFO. It appears as delays for the COO. It appears as frustration for engineers. It appears as exceptions for quality. It appears as premium freight for supply chain. It appears as meetings for managers. It appears as customer concessions for commercial teams. It appears as training burden for HR. The software invoice is only the visible part. The more damaging cost is the capacity spent making categories act like a system. That is why this change is enormous. It is not just vendor disruption. It is a reallocation of agency. Companies that once bought categories because they could not carry functions themselves will increasingly own the architecture that carries those functions. Vendors that once sold workflows because customers needed packaged software will have to prove which parts of their products carry protected consequence. Investors that once valued categories because they were sticky will have to ask whether the stickiness is trust or friction. Operators that once tolerated manual reconciliation will ask why the platform cannot carry the work. The old moat becomes the new liability Every incumbent has to ask what its moat is made of. If it is made of official truth, certified control, physical trust, regulatory proof, or deep engineering capability, it may remain strong. If it is made of interface dependence, workflow captivity, integration difficulty, data access control, or customer fear of change, it may hold revenue longer than it deserves, but it will not hold trust. That distinction will matter more each year. Customers are learning that they do not have to replace everything to change the route of work. They can surround systems. They can use APIs. They can generate interfaces. They can build skills. They can create platform logic above the record. They can reduce seats. They can compress workflows. They can refuse modules. They can demand semantic access. They can ask vendors to expose authority without owning every interaction. The vendor wall may slow this, but it will not settle it. Some walls are necessary. They protect records, safety, cyber, audit, and operating discipline. Other walls protect economics. The market will eventually learn to tell the difference. A wall that prevents unsafe action is a control. A wall that prevents governed movement is rent. The board of a software vendor should ask whether its product becomes more valuable when customers build reasoning platforms, or less. Does the product become a trusted primitive the platform needs? Does it become the official record around which action is governed? Does it become the high-fidelity mirror through which consequence is inspected? Or does it become a workflow layer the platform can generate? That answer should shape strategy, product road map, pricing, partnerships, API policy, and capital allocation. The board of an industrial company should ask the matching question. Which parts of the software estate carry trust we should continue to buy? Which parts carry work we should now own? Which vendors are becoming more strategic because they protect consequence? Which vendors are becoming less strategic because they sell category shape? Which internal capabilities must be built so that cheap software does not become cheap disorder? Which architects do we need because the next advantage will not come from buying another application, but from knowing what our own system is allowed to become? This will be difficult for finance because the old budget categories will mislead. Capex and opex will not tell the story. Subscription and maintenance will not tell the story. Seats will not tell the story. The better economic question is whether the spend buys durable consequence or temporary form. Durable consequence deserves long-term commitment. Temporary form should be generated, changed, and retired. This will be difficult for IT because the old posture of either blocking or enabling will not be enough. IT has to become the builder of governed movement. Not merely access. Permission. Not merely integration. Context. Not merely security. Trust. Not merely architecture review. Architecture as the operating design of action. That is a larger role than managing applications. It is also more exposed because it sits closer to business consequence. This will be difficult for operations because it removes a familiar excuse. If the old category structure made action slow, it was easy to blame the systems. If the company now owns the reasoning layer, it has to own the quality of its questions, evidence, decision rights, and learning. A platform can carry burden. It cannot make weak judgment strong by itself. Buy protected consequence. Own the architecture of judgment.

What remains after the categories weaken

After the old categories weaken, the work remains. That is why the change will be easy to underestimate. The plant still runs. Products still change. Customers still call. Auditors still ask for proof. Machines still fail. Suppliers still miss. Quality still escapes. Engineers still need to see what they are designing. Operators still need trustworthy signals. Finance still needs the ledger. The ordinary continuity of work will make the change appear less radical than it is. But underneath, the unit of value changes. The customer stops buying a category because the market named it. The customer buys what it cannot safely self-perform and owns the architecture of everything else. The vendor stops assuming that control of a workflow equals control of the future. The investor stops treating sticky category revenue as automatically durable. The architect becomes more important than the application. The platform becomes the place where functions are carried, tested, governed, visualized, and changed. The company that understands this will not rush to rip out systems. That would be reckless. It will classify them. It will identify protected records, protected primitives, exposed workflows, generated interfaces, platform skills, and consequence boundaries. It will keep what must be trusted. It will surround what must be accessed. It will absorb what no longer deserves category economics. It will build only what its architecture can govern. It will buy only what carries trust it should not pretend to own. The company that misses this will keep buying categories and then pay again for people to make the categories work together. It will add AI assistants inside each system and wonder why cross-system latency remains. It will digitize workflows that should have been eliminated. It will create dashboards for consequences it has not learned to control. It will defend governance that only adds review. It will confuse software activity with operating agency. There will be a period when both worlds exist at once. The old categories will remain in contracts, analyst reports, renewal cycles, and operating habits. The new platform logic will appear first in pockets, skills, internal tools, generated workflows, and API-connected reasoning layers. Some will look small. Some will look like productivity. Some will look like shadow IT. Some will be dangerous. Some will become the new operating architecture. The difference will be whether they are governed by consequence. The future does not belong to free software. Free software is too small a frame. The future belongs to the enterprise that understands what should be made, what should be bought, what should be trusted, what should be forbidden, and what must be made true. Software gets cheap. The architecture of consequence does not. References This article draws conceptually on Herbert Simon’s work on bounded rationality and satisficing, Daniel Kahneman and Amos Tversky’s work on judgment under uncertainty, Richard Cyert and James March’s behavioral theory of the firm, Jay Galbraith’s information-processing view of organization design, W. Edwards Deming’s work on systems, variation, and management, Judea Pearl’s work on causality, counterfactuals, and intervention, IEC 62264 and ISA-95 for the enterprise-control boundary, and IEC 62443 and NIST industrial control system cybersecurity guidance for the discipline required near physical consequence. It also draws on Anthropic’s public documentation and engineering writing on agent skills, tool use, and executable capabilities, Autodesk’s May 2026 announcement of its agreement to acquire MaintainX, Reuters reporting on the transaction, and market coverage of investor concern about valuation, premium, and execution risk. It also draws on Michael Carroll’s prior work on Critical Decision Infrastructure, Purdue stack reconciliation, permission architecture, customer-owned context, judgment-in-the-loop, and the principle that data does not become evidence until there is a question. These sources matter because the argument is not that enterprise software vanishes through enthusiasm. It is that bounded human judgment, fragmented systems, decision latency, causal ambiguity, cyber risk, and the separation between official records and operating consequence are now colliding with reasoning systems that can generate software, compose skills, call APIs, and carry functions that once required separate categories.