For decades, warehouse automation has been designed around a relatively simple principle:

Determine how products need to move. Then build the machinery to move them.

Conveyors follow predetermined paths. Sorters divert products at fixed locations. Storage systems retrieve inventory through carefully engineered sequences.

The intelligence is largely in the design.

Once installed, the physical architecture determines what the system can do—and what it cannot.

But this week, Symbotic announced its acquisition of German automation company cellumation, whose technology takes a fundamentally different approach to material movement.

Instead of relying on conventional conveyor paths, cellumation’s celluveyor uses independently controlled, omnidirectional cells to move products across a surface.

Individual cells can coordinate to change an item’s direction, position, and orientation.

The physical hardware remains in place.

The movement is increasingly determined by software.

That distinction is more important than it might initially appear.

Because the next major evolution in warehouse automation may not be a better robot.

It may be the ability to change what an automated system does without rebuilding the system itself.

When the Layout Becomes a Limitation

Consider a conventional sortation system.

During design, engineers determine where products enter, how they travel, where they divert, and how different flows interact.

The system is optimized around a particular operating profile.

Expected throughput.

Product dimensions.

Order characteristics.

Destination requirements.

Peak volumes.

And those assumptions are translated into physical infrastructure.

Conveyors, merges, diverts, accumulation zones, and transfer points are installed accordingly.

The result can be extremely efficient.

Until the business changes.

A new customer requires a different flow.

Product dimensions shift.

Order profiles become more fragmented.

An additional destination is needed.

Or a bottleneck emerges in a location that was never expected to constrain capacity.

Now the question is no longer simply how to optimize the system.

It becomes how much of the physical infrastructure must change to support the new operating requirements.

This is one of the fundamental trade-offs of traditional automation.

We gain efficiency by engineering predictability into the system. But that predictability can become a constraint when the operation evolves.

Separating Movement From Infrastructure

This is what makes cellumation’s technology interesting.

Its celluveyor consists of modular, independently controlled cells capable of moving objects in multiple directions.

Instead of every product following a mechanically predetermined path, software can coordinate how individual cells interact to create different movements.

In principle, that opens the door to capabilities that are difficult to achieve with conventional conveyor architectures.

Products can be redirected without dedicated mechanical diverts.

Orientation can be adjusted during movement.

Multiple flows can potentially share the same physical surface.

And changes in routing logic may require software modifications rather than mechanical reconstruction.

Of course, there are limits.

A programmable surface still has physical capacity constraints. Cell speed, load characteristics, congestion, available space, and the interfaces connecting it to the rest of the operation all matter.

Software cannot eliminate physics.

But it can change how efficiently we use the physical infrastructure.

That is the interesting part.

The value is not simply greater flexibility.

It is the possibility of reducing the amount of physical infrastructure required to accommodate operational change.

The Cost of Changing Your Mind

Most automation business cases focus heavily on initial investment.

Equipment cost.

Installation.

Integration.

Labor savings.

Throughput.

Payback.

But there is another economic dimension that deserves more attention.

What does it cost to change the system after it has been installed?

Imagine two automation architectures.

Both deliver the same throughput today.

Both meet the required service levels.

Both have comparable operating costs.

But three years from now, the business needs to change how products move through the facility.

One system requires new conveyors, additional transfers, mechanical modifications, shutdown windows, and extensive recommissioning.

The other can accommodate much of the change through software and relatively limited physical modifications.

Those systems may have looked equivalent in the original ROI model.

They are not economically equivalent over their useful lives.

The difference is the cost of change.

And that cost becomes increasingly important as distribution networks face shorter planning horizons, changing customer requirements, SKU proliferation, and more volatile demand patterns.

We often describe flexibility as a qualitative benefit.

I think we should start treating it as an economic variable.

What is the cost of adding a destination?

Changing a routing sequence?

Accommodating a different product profile?

Increasing capacity in one part of the operation?

Reconfiguring a process without stopping the entire system?

These questions should be part of automation architecture decisions, not discussions reserved for future expansion projects.

Flexibility Has to Be Proven

There is a risk in this discussion.

Software-defined does not automatically mean flexible.

And flexible does not automatically mean economical.

A system may support dozens of routing configurations but still be constrained by its physical interfaces.

It may allow rapid changes in logic but require extensive testing before those changes can safely enter production.

It may eliminate certain mechanical components while introducing new maintenance requirements, software dependencies, or failure modes.

And a more flexible architecture may cost more initially.

That additional investment only creates value if the flexibility is actually needed and can be used.

So I would challenge automation vendors with three questions:

1. What can we change without modifying the hardware?

Not theoretical capabilities. Specific operating changes, with examples of what has been demonstrated.

2. How quickly can we make those changes?

Include engineering, software development, validation, downtime, and recommissioning.

3. What happens to performance after the change?

Flexibility has little economic value if the system can accommodate new workflows only by sacrificing significant throughput or reliability.

These questions reveal something that conventional throughput specifications often miss.

The value of an automation system is not only what it can produce today. It is also what it will cost to make it produce something different tomorrow.

A Different Way to Evaluate Automation

I would add one more dimension to the traditional automation business case.

Alongside initial capital, operating cost, throughput, and payback, evaluate the cost of change over the system’s useful life.

Consider several realistic operating scenarios.

A 20% increase in volume.

A significant change in SKU mix.

An additional fulfillment channel.

A new packaging format.

A different order-release strategy.

For each scenario, estimate the engineering effort, capital modifications, downtime, and performance implications.

Then compare architectures.

The goal is not to predict every change the business will experience over the next decade.

It is to understand how exposed the investment is when those changes inevitably occur.

A more adaptable system may justify a higher initial investment.

A simpler, more rigid architecture may still be the better choice for a highly predictable operation.

Neither is universally superior.

The right architecture depends on how much operational change the business expects—and what that change will cost.

3 Signals Worth Watching

​AutoStore addresses a physical constraint through a new workstation design

AutoStore’s FlexBinsPort allows bins of different heights to be presented at the same workstation, extending the flexibility introduced by its mixed-height FlexBins storage capability. The significance is practical: product diversity often forces compromises in storage density and workstation design. Reducing those compromises can expand the range of inventory profiles that fit within a single automation architecture.

​NAPA Auto Parts, Hy-Tek Intralogistics, and Hai Robotics prioritize flexibility across diverse SKU profiles

The companies announced a new automated fulfillment project on October 15. The proposed solution combines multiple robotic technologies within a unified storage and retrieval architecture. Importantly, the team evaluated the technology in Hy-Tek’s Innovation Lab before implementation. This is a selected project, not a completed deployment, but it illustrates how flexibility and validation are becoming explicit design requirements.

​Hesai moves deeper into the infrastructure behind physical AI

Hesai introduced Kosmo, a spatial camera combining lidar and imaging technology to capture the three-dimensional information robots need to understand physical environments. The broader implication is that advances in robotics increasingly depend on the sensing, data, and software infrastructure surrounding the machine—not only the robot itself.

For decades, we have evaluated automation primarily on how efficiently it performs a defined process.

That remains essential.

But as technology evolves and operating requirements become less predictable, another question deserves equal attention:

How expensive will it be to change our minds?

Because an automation investment doesn’t end when the system goes live.

That is when the business starts changing around it.

And the cost of keeping up may ultimately determine whether the investment was a good one.

​