Why Change Is Outpacing Absorption Capacity

AI has reduced the effort required to create software, automate a task, configure an agent, or build a narrow internal tool. Microsoft reported that active Microsoft 365 agents increased fifteenfold during 2025 and eighteenfold in large enterprises. HEINEKEN described employees creating more than 45,000 agents on its internal AI platform, while Network Rail reported more than 4,000 employee-built applications. These examples do not establish a market rate, but they show that solution creation no longer sits only with central projects and technology groups.

A new application may replace a process, add a step, alter an approval, redirect an exception, or remain unused. Administrative systems can count applications, agents, runs, and users, but they generally cannot show how many distinct changes reached a team, which existing practice each displaced, or whether the new practice persisted.

Latent Variables’ own usage records show the same direction: we have seen a rapid increase in locally initiated agents, tools, and workflow changes within active work. We do not yet have a stable denominator that would support a market claim, so we treat this evidence as directional.

A later publication will define and track internally initiated changes to work by origin, affected workflow and population, the work they replace, and their persistence over time.

In 102 of 199 threads, or 51 percent, leaders described at least one failure in the information layer used to understand their organization. The most common form was an observability gap. It appeared in 67 threads, or 34 percent. Leaders described processes that took months to map, different local practices behind one formal policy, functional metrics that did not explain the end-to-end result, and programs with no owner who could describe the full workflow.

Listening problems formed a related subset. In 59 threads, or 30 percent, leaders described at least one failure in how the organization gathered or used employee input. Twenty-eight distrusted their own engagement data. Twenty-five said official channels missed people whose behavior would affect the outcome. Fourteen described diagnoses based on a narrow set of informal conversations. Twelve said employees had supplied input without seeing action, which reduced the value of later requests for input.

This condition affects how an organization evaluates a proposed solution because teams need to know the actual workflow, the local variants, the exception paths, and the reasons for current behavior.

Without that baseline, a new tool can automate the documented process while leaving the operative process unchanged. It can also remove an informal workaround without replacing the function that workaround served.

The data does not imply that every organization lacks documentation. It shows that many leaders questioned whether formal documentation described daily work closely enough to guide change.

Solution abundance raises the consequence of that uncertainty because more teams can act on an incomplete map at the same time.

The overlap matters. Concurrent change appeared 1.7 times as often as chance would predict in threads that also involved M&A. Reports of missed voices appeared 1.9 times as often in the M&A threads. Distrust of employee data appeared 1.7 times as often. These are associations within this working record, not causal estimates. They indicate that the organizations carrying high integration loads were often the same organizations reporting weak visibility and listening.

Solution abundance adds smaller interventions to this portfolio. A locally built agent or automation may look immaterial beside an enterprise implementation. Its effect depends on where it lands. Several small changes can alter the same handoff, role, or approval path.

Organizations that track only named programs can miss that cumulative load.

The same problem appears in an M&A integration, system implementation, or operating-model change when one named program produces different behavioral shifts across roles, locations, and exception paths.

change capacity scarce, reduced, or newly established — 17%

threads contained both rising demand and constrained capacity

capacity constraints, versus chance, in threads describing concurrent change

12 managers expressing agreement while withdrawing support informally

5 behavior the leader considered deliberate obstruction

4 teams waiting for an initiative to pass

In our platform, Latent Variables uses a unit of analysis called a change to work. One unit is the smallest material shift that requires a defined population, under materially similar operating conditions, to perform one observable behavior differently. That behavior may involve a task, handoff, decision, approval, exception path, tool, source of information, or assignment of responsibility.

The unit is deliberately smaller than a project or solution. One system implementation can contain dozens of changes to work. A locally created agent can create several if it changes the behavior of analysts, managers, and an exception owner in different ways.

This approach has helped us separate the amount of technology entering an organization from the amount of adaptation the organization must manage. We share it because leaders can use the unit without adopting a new change-management methodology or working with our lab.

Anticipated impact is only the starting point. The card develops into a living operating record that incorporates undocumented variants, encounter frequency, concurrent load, replacement status, and persistence as evidence emerges.

The unit follows the required behavior, not the project boundary. If the same population must perform the same behavior under substantially similar operating conditions, we treat it as one unit. If one solution requires different behaviors from different roles, or if the same behavior meets materially different local conditions, we separate the units.

For example, an AI tool for invoice exceptions might appear as one deployment in the technology portfolio. In the operating record, it could contain separate units for analysts classifying an exception, supervisors approving a high-risk case, and finance operations resolving an output the tool cannot classify. A region with a different regulatory handoff may require another unit because the receiving conditions and exception path differ.

We apply four practical counting rules.

Persistence completes the unit.

Usage data may show that a tool remains active, but it does not establish that the intended behavior replaced the prior practice. The operating record should test whether the new behavior appears in actual work, whether exception volume changes, whether local workarounds remain, and whether the unit still holds after launch support declines.