There is a structural assumption buried in every automation sales pitch that nobody in the industry wants to examine too closely. The robot is sold as a labor replacement. But labor doesn't work the way the pitch implies.

When you hire a welder, you pay them Friday for work they did Monday through Friday. You have had five days of productive output before a single dollar leaves your payroll account. Scale that across a workforce of two hundred people and you are operating on a continuous float of human capital — delivered first, paid after. The amortization is built into the structure of wages. It is not a financing arrangement you negotiated. It is how labor has always worked.

The robot does not work this way. The robot costs $2 million and it sits on your balance sheet on the day it's commissioned, before it has produced a single part. The integrator gets paid at delivery. The robot manufacturer gets paid at shipment. The software vendor starts billing at installation. Every party in the automation stack front-loads their revenue, which means every party in the automation stack transfers the full capital risk to the supplier before the first production cycle runs.

This is not a small distinction. It is the reason mid-size suppliers who could automate don't, and the reason the automation industry has spent twenty years complaining that adoption is slower than it should be. The barrier isn't technical feasibility. The barrier is that they are asking their customers to pay for years of future labor on day one — something no human worker has ever been asked to accept.

How Every Other Supplier Gets Paid

The OEM knows exactly how to structure a purchasing relationship. They have been doing it for a century. When General Motors sources a door module assembly, they do not write a check on January 1st for the year's supply. They issue a blanket purchase order against a committed annual volume — say 500,000 units — and they pay a negotiated price per assembly on delivery, weekly, as parts ship to the line.

The supplier carries the tooling investment. The supplier carries the capital cost of the production equipment. But the revenue that amortizes those investments arrives in proportion to actual production, against a committed volume that the OEM has obligated themselves to purchase. The supplier is not paid in advance. But the supplier is also not asked to carry the entire capital risk without a committed revenue stream behind it.

And here is the part the automation industry has chosen to ignore: sometimes the OEM pays the tooling outright. When a die or a fixture is sufficiently program-specific — when it will produce exactly one part number for exactly one platform and has no realistic redeployment value if the program ends — the OEM frequently carries that capital cost themselves. Because they created the specificity. Because they own the platform decision that made the investment necessary. Because the risk of a stranded asset belongs to the party that controls the program, not the party that responded to the sourcing request.

A dedicated welding cell configured for a specific body-in-white assembly is not a general-purpose asset. It is a program-specific investment made in reliance on a volume commitment. The OEM already understands this logic perfectly well for steel tooling. They have simply decided that robots are different.

They are not different.

The barrier to automation isn't technical feasibility. It's that the industry is asking customers to pay for years of future labor on day one.

What Happens When You Change the Model

The automation companies will object immediately. Their business model requires capital up front. Their margins depend on it. Their investors expect it. All of this is true, and none of it is the supplier's problem.

Because here is what changes when automation is priced per cycle against a committed OEM volume: the capital barrier disappears for the suppliers who need it most.

A $2 million welding cell requires a credit facility, collateral, a bank that understands manufacturing equipment, and a CFO willing to put it on the balance sheet against a program that might not run to term. Most mid-size suppliers fail at least one of those four tests. That is why the automation industry's customer base has been concentrated in large tier-ones with sophisticated treasury functions, while the mid-market — where most of the actual parts volume lives — remains largely unautomated.

Per-cycle pricing converts a capital expenditure into an operating expense. That is not a semantic distinction. A capital expenditure of $2 million requires board approval, a depreciation schedule, and a balance sheet conversation with the bank. An operating cost increase of $X per unit shipped is a plant manager decision. The approval path is completely different. The adoption rate changes overnight.

The irony is real and it deserves to be named: the financing model the automation industry has chosen is the primary obstacle to the broad, deep market penetration they claim to want. They have been optimizing for margin per transaction at the expense of total market size. Per-cycle pricing is a smaller margin per unit and a vastly larger addressable market.

The Three-Tier Model

Not every automation investment carries the same risk profile, and the financing model should reflect that. The same logic that governs tooling agreements can govern automation — tiered by how program-specific the asset is and who controls the decision that creates that specificity.

Tier One — General Purpose
Supplier carries the investment. Amortizes per unit.
Commodity automation — general-purpose collaborative robots, standard vision systems, flexible assembly cells that can be redeployed across programs and platforms. The supplier buys or leases the equipment, amortizes the cost into the per-unit price, and manages the asset across programs. Same as any other capital equipment. The redeployment value is real. The supplier owns the risk because the supplier controls it.
Tier Two — Program-Specific
Shared investment. Per-cycle pricing against committed volume.
Configurable but not easily redeployed — cells designed for a specific product family but potentially adaptable with significant rework. The OEM commits to a production volume. The automation is priced at a per-cycle rate against that committed volume. Early termination triggers a settlement equal to the unamortized balance, exactly like a tooling write-off. The integrator retains ownership or assigns to a financing entity. The supplier pays for productive output, not capital equipment.
Tier Three — Dedicated
OEM carries the capital cost. Same as dedicated tooling today.
Fully dedicated automation — single program, single platform, no realistic redeployment path if the program changes. The OEM created the specificity through their platform decision. The OEM carries the capital cost, exactly as they carry the cost of dedicated dies and fixtures today. This is not a new concept. It is existing practice applied consistently.

The OEM will resist this because it transfers risk back to them — which is precisely why it is the correct structure. The current arrangement transfers all capital risk to the supplier against a program commitment the OEM can exit at any time. That is not a partnership. That is a financing arrangement with asymmetric downside, dressed up as a sourcing relationship.

The Task Programming Problem

There is one more item the automation industry has been quietly passing to suppliers without acknowledgment or compensation: task programming.

A robot cell does not arrive ready to run. Someone has to program every motion path, every sensor threshold, every exception condition, every handoff with the adjacent cell. On a complex welding or assembly application, that programming effort can run to thousands of hours. It requires specialized skills that most suppliers do not have in-house, which means they either hire integrator engineers at integrator rates or they develop internal capability from scratch against a program timeline that does not wait for them to get good at it.

In the per-cycle pricing model, task programming is an integrator cost. The integrator is selling productive cycles, not capital equipment. A cycle that doesn't run because the programming is wrong is a cycle they don't get paid for. The incentive to get the programming right, quickly, belongs to the party that controls it — which is the integrator.

The automation companies will grumble about this. They will say it's not their business model, that they sell hardware and integration services separately, that programming responsibility belongs to the customer. All of this is the sound of an industry that has not yet been forced to compete on outcome rather than deliverable.

They will adapt. Because they already know how to solve the programming problem at scale — the same way every other knowledge-intensive industry is solving repetitive technical work in 2026. They will train their own AI on ten thousand past programming projects. They will generate motion paths automatically from CAD geometry. They will reduce a two-thousand-hour programming engagement to a two-week validation exercise. The capability exists. The incentive to deploy it at scale has been missing because the programming cost has been someone else's problem.

Per-cycle pricing makes it their problem. Which means they will solve it. Which means the total cost of automation deployment drops, the timeline compresses, and the mid-size suppliers who couldn't afford the programming engagement suddenly can.

Current Model — Who It Serves
  • Large tier-ones with sophisticated treasury functions
  • Programs with long, stable horizons
  • Suppliers willing to carry full capital risk
  • Integrators who front-load revenue and exit
  • OEMs who want automation benefits without the commitment
Per-Cycle Model — Who It Serves
  • Mid-size suppliers currently priced out of the market
  • Programs of any length — risk matches commitment
  • Suppliers who pay for output, not equipment
  • Integrators who compete on performance, not delivery
  • OEMs who get broader adoption and lower total system cost

Why the Automation Industry Gets What It Claims to Want

The automation industry has spent two decades arguing that manufacturing's problem is insufficient adoption of automation technology. They are correct. They have also spent two decades structuring their business in a way that makes adoption as difficult as possible for the customers they most need to reach.

Per-cycle pricing is not a punishment. It is an alignment of incentives. The integrator who gets paid per productive cycle has every reason to ensure the cell runs, the programming is right, the uptime is high, and the supplier's production costs actually decline as promised. The integrator who gets paid at commissioning and moves on to the next project has no such incentive after the check clears.

The OEM that commits to a volume and pays a per-cycle rate has every reason to protect the program, honor the commitment, and think carefully before shortening the platform life. The OEM that can exit a program without financial consequence will exit programs without financial consequence. The Commercial Model series established this. The automation financing model is the enforcement mechanism the Commercial Model was missing.

The leasing analogy is not accidental. Caterpillar Financial Products has been doing this for decades. You lease the excavator. You pay per hour of operation. The machine is maintained by the lessor because a machine that doesn't run is a machine they don't get paid for. The alignment is perfect and the adoption curve in construction equipment reflects it. Every contractor in America has access to a Cat machine regardless of their balance sheet because the financing model was designed for the actual customer, not the ideal customer.

There is no structural reason the automation industry cannot operate the same way. There is only the preference not to — which is a preference, not a constraint, and preferences change when the alternative is watching your addressable market stay permanently smaller than it should be.

The OEM has been forcing terms on suppliers for forty years. They decide the price. They decide the delivery cadence. They decide the quality standard. They decide the payment schedule. They do all of this because they have the volume and the suppliers need the business.

The automation industry wants that volume. Every mid-size supplier in America that doesn't yet have a robot cell is potential revenue they haven't captured. The price of that volume is the same price every other supplier has always paid to do business with the OEM.

Play by the same rules as everyone else. You'll grumble. You'll adapt. And you'll build more robots than you ever would have otherwise.

Michael Russo is the founder of PolicyTorque and an automotive engineer with eight years of OEM experience across Ford, GM, and Stellantis programs. · policytorque.com
← The American Factory Series · Part (VN12)7 — The Proof Ford didn't retire the Econoline because it couldn't meet the future. They retired it because it was too good at the present.