When reviewing an automation proposal, it is easy to treat a longer list of capabilities as evidence of a better solution. But the list tells us what the robot can do. It does not tell us what the operation gains.
Asking the robot to do more may remove labor, equipment, or handling elsewhere. It may also consume picking time or introduce more conditions the system needs to manage.
That can be a good trade. It can also be an expensive way to keep a robot busy.
At Berkshire Grey, we believe the evaluation should establish what work disappears, what demands are added, and whether the complete operation benefits.
Start by identifying the specific work an added capability would remove. Does a manual task disappear? Is a separate workstation no longer needed? Or does the work simply move to another part of the process?
Direct-to-carton placement is one example. Where placing items into the outbound carton eliminates a later transfer or packing step, those savings belong in the business case. If the application requires additional robot time or more complex placement, those costs belong there too. The destination alone does not establish either outcome.
An evaluation focused only on robot speed could miss the work saved elsewhere. An evaluation focused only on the eliminated step could miss the demands added to the robot. One useful test is to finish this sentence:
This improves the operation because it removes or reduces ______, at the cost of ______.
Both blanks matter. If we can describe the capability in detail but cannot fill them in, we have more work to do.
When an added capability uses robot time, the next question is whether that time affects the output the operation needs.
When picking limits the operation’s output, the arm’s time is a scarce resource. Adding another task can reduce the capacity available to fulfill orders. That task needs to deliver enough value elsewhere to justify the trade.
But reducing robot cycle time is not a universal design rule either.
Consider a simple illustration: inventory presentation supports 200 pick opportunities per hour, while the robot can already process 230. Increasing the robot’s capacity to 260 will not increase current system output. The robot will spend more time waiting for inventory.
In that situation, using some spare robot time to remove work elsewhere may be worthwhile. If the robot is already limiting output, the same choice could reduce the number of orders the operation completes.
That is why I would be cautious about judging a design by an isolated pick rate. We need to understand what limits completed work and how the proposed change affects it.
That raises the harder question: where should the robot’s responsibilities begin and end? In our white paper, The Right Automation Boundary, I work through that decision in more detail, with cycle-time examples and a framework for comparing robotic picking architectures.
The normal cycle time is only part of the calculation. An added capability can also introduce more conditions the system must recognize and manage.
What happens when a scan fails, a destination is unavailable, or a placement cannot be completed? How does work resume, and who needs to help?
Those conditions affect commissioning, operator training, maintenance, and recovery. They belong in the business case alongside the expected savings.
Some complexity is worth taking on if it removes difficult or expensive work. But a feature that saves routine labor may deliver less value than expected if it frequently requires specialist intervention.
For me, the useful question is what the operation gains.
Sometimes the answer supports a broader robot role. Sometimes the work is better handled by surrounding equipment, software, or a person.
The decision should follow the throughput, reliability, and economics the operation needs. It should also make the tradeoffs clear enough that the people responsible for running the system know what they are accepting.
A longer capability list is easy to produce. A convincing reason for each capability takes more thought.
