The Embodiment Problem

Part 01What a robot actually is

Chapter 01The lab I learned in

Before bitcoin, before any of the rest of it, I spent eight years at a robotics company outside Toronto building control systems, mechatronics and haptic devices. We sold them into university research labs. MIT, Stanford, Georgia Tech, and a few hundred others. If a control theory group somewhere was teaching state feedback on real hardware, there is a reasonable chance the hardware on the bench came out of a building I worked in.

That work was unglamorous in a specific way that shaped everything I think about this field. Nobody in a research lab is impressed by your marketing. A professor buys a device to teach a concept, and if the device does not exhibit the concept cleanly, the concept does not get taught and you get the phone call. Our customers could read a Bode plot. They knew what a phase margin was. If we shipped a rotary servo with a resonance we had not characterised, somebody in Cambridge or Palo Alto found it in the first week and told us the frequency.

I want to be precise about what that does to your thinking. In software, a claim can be wrong for a long time and nothing visible happens. In robotics, a wrong claim falls over. The pendulum drops, the arm oscillates, the gripper crushes the part. Physics is the fastest code reviewer ever built and it does not care who you are.

I have carried that into everything since. I sat on the board of a publicly traded humanoid robotics and embodied AI investment issuer, and in August of 2026 I became its chief executive officer. This book is not written in that company's voice and it is not a company communication. It is my personal view, formed at a bench with an oscilloscope on it, and updated across several hundred conversations with founders who are building machines right now.

The reason I am writing it is that robotics is having its loudest decade and most of the noise is being generated by people who have never had to explain a sampling rate to a customer. There is an enormous amount of commentary and very little field knowledge. The commentary is about what robots will do. The field knowledge is about what a robot is, why it breaks, what it costs to keep running, and what has to be true for a customer to sign the second purchase order.

That second purchase order is the whole book, really. Everybody in this industry can get the first one. The first one is bought on hope, on a demo, on a budget line somebody wanted to spend before year end. The second one is bought on evidence. It is bought because the machine did the job for six months and the plant manager would rather have another one than have his old process back.

So this is a field manual for the gap between those two orders. It is written for founders building machines, for operators evaluating them, and for anybody who wants to understand this sector at the level of mechanism rather than at the level of headline.

I am going to be honest about what I do not know, because the sector's chief pathology is confident prediction. I will describe how things work and what has been demonstrated. Where the future is genuinely open, I will say it is open and leave it there. Nobody needs another forecast. What people need is the ability to look at a robot and know which questions to ask.

Let me start with the most basic one, which almost nobody asks, because they assume they know the answer.

Chapter 02A robot is a control loop wearing a costume

What is a robot?

The popular answer involves intelligence, or autonomy, or a humanoid shape. The engineering answer is much older and much more useful. A robot is a closed loop control system that acts on the physical world.

Four things happen, over and over, forever. The system senses its state. It compares that state to a desired state. It computes a correction. It applies that correction through an actuator, which changes the physical world, which changes the state, which gets sensed again. Sense, compare, compute, actuate. Then again. Then again.

Everything else, and I mean everything, is a detail of how those four steps are implemented. A six axis industrial arm and a bipedal humanoid and a warehouse mobile base are the same object at this level of description. They differ in how many loops they run, how fast the loops run, how good the sensing is, and how the desired state gets chosen.

This framing is not academic. It is the most practically valuable lens I know for evaluating a robotics company, because it tells you immediately where a claim has to be true.

If someone says their robot is more intelligent, the loop question is: which loop got better, and at what rate does it run? If someone says their robot is safer, the question is: what does the loop do when the sensor lies, and how quickly does it notice? If someone says their robot generalises to new environments, the question is: does the policy that chooses the desired state degrade gracefully, or does it fail into an unstable region?

The reason this matters more now than it did when I was building the hardware is that the machine learning wave changed exactly one part of the loop and left the other three alone. Learned policies are enormously better at the compare and compute step, particularly at the higher level where the desired state is chosen from messy perception. That is a genuine and large change and I do not want to undersell it. Tasks that used to require a team of engineers hand tuning behaviour for a specific factory cell can now be learned from demonstration.

But the sensing is still sensing, the actuation is still actuation, and the physics between them is unchanged. A learned policy that outputs a joint torque command still has to get that torque out of a motor through a gearbox with backlash and compliance and thermal limits, and the arm still has inertia. The intelligence got better. The body did not get a free upgrade.

This is the single most common category error I see, in pitches and in press coverage alike. People observe rapid progress in the cognitive layer and assume proportional progress in the physical layer. The physical layer improves on the timescale of supply chains and materials science, not on the timescale of model releases.

I would go further. In most robots that fail in the field, the failure is not cognitive at all. It is a connector that vibrated loose, a bearing that ingested dust, a calibration that drifted with temperature, a cable that fatigued at a flex point after two hundred thousand cycles. I have watched more robotics programmes die from cable routing than from insufficient intelligence, and I am not being cute about that.

So when you look at any machine, mentally decompose it into the loop. Ask what is being measured, how often, with what noise. Ask what is being commanded, through what mechanism, with what authority and what limit. Ask what happens between those two things. Then ask the question that separates the demo from the product, which is what the loop does on the ten thousandth cycle, in a place nobody swept, at the end of a shift when the batteries are warm.

Chapter 03The three numbers that decide almost everything

When I evaluate a machine now, I want three numbers before I want anything else. Loop rate, latency, and authority. If a founder cannot give me those quickly, we are not talking about a product yet, we are talking about a video.

Loop rate is how many times per second the control loop closes. A position loop on a well built industrial joint runs somewhere in the kilohertz range. A whole body balance controller on a legged machine needs to run at hundreds of hertz at minimum, because the machine is an inverted pendulum and an inverted pendulum diverges. A high level task policy that decides which object to pick can run at a handful of hertz and be perfectly fine.

That hierarchy is the important part. Real machines run nested loops at wildly different rates, and the discipline is knowing which decision belongs at which rate. The fast inner loops keep the machine stable and safe. The slow outer loops make it useful. When people talk about a robot being controlled by a large model, what they almost always mean is that a slow outer loop is being chosen by a model while fast inner loops made of ordinary control code hold the machine up. That is a sensible architecture. It is also very different from the impression left by the video.

Latency is how long it takes for a change in the world to produce a change in the machine's behaviour. It is not the same as loop rate, and conflating them is a classic mistake. You can run a loop at a thousand hertz and still have forty milliseconds of latency hiding in a camera pipeline, a network hop, a filter, and a serial bus. Latency is the sum of every delay in the chain, and in a feedback system, delay eats your stability margin. This is not an opinion. Add enough phase lag and a stable system becomes an oscillator, and there is no amount of clever software that repeals it.

This is why the question of where inference runs is a physics question and not a preference. If a decision has to be inside a fast loop, it cannot make a round trip to a data centre. The speed of light is generous but the rest of the network is not, and a balance controller cannot wait on a retransmit. Machines that must react to contact in real time need compute close to the joints. Machines that are choosing what to do next, over seconds, can afford to think elsewhere. Most sensible architectures do both, and the split between them is one of the more revealing things about how well a team understands its own product.

Authority is how much the machine can actually do to the world. It is torque, force, reach, payload, speed. Authority is where safety lives, because a machine with high authority near a person is a hazard by construction and everything downstream is about managing that. It is also where the bill of materials lives, because torque density is expensive and always has been.

Here is the part that took me years to internalise. These three numbers trade against each other and against cost, constantly, and a robotics company is essentially a set of decisions about where to sit in that space. You can buy loop rate with better electronics. You can buy latency with local compute and a tighter sensor pipeline. You can buy authority with bigger actuators, which costs you weight, which costs you power, which costs you runtime, which costs you the duty cycle you promised the customer.

None of this is solvable in general. It is only solvable for a specific job. Which is the reason the next chapter exists.

Chapter 04The demo was never the hard part

Robotics has always been able to produce a stunning demo. That is not a modern phenomenon and I want to be blunt about it, because a lot of current excitement is being read as unprecedented by people who did not watch the previous rounds.

I have watched machines do genuinely remarkable things on a bench, in a lab, in a controlled cell, for twenty five years. Backflips, door opening, dexterous in hand manipulation, dancing. Each time, a portion of the audience concluded that general purpose robots had arrived. Each time, the gap between the video and the deployment turned out to be enormous, and the gap was not intelligence.

The gap is commercialisation. Cost per unit. Reliability in an environment nobody curated. Integration into a workflow somebody is willing to pay for. A service model that survives the third breakdown. Unit economics that improve rather than degrade with scale.

I said this on my own site before I ran anything in this sector and I will repeat it here because it is the load bearing sentence of the whole book. The hard part of robotics was never the demo. It is commercialisation.

Why is the demo easy, relatively? Because a demo is allowed to be a single trajectory. You get to choose the lighting. You get to choose the object, and its pose, and its colour, and its friction coefficient. You get to run it forty times and publish the good one. You get to have the engineer who wrote the code standing off camera. None of those affordances are available in a warehouse at three in the morning.

The transition from one to the other is not a matter of polish. It is a change in what the machine is being asked to be. A demo has to work once. A product has to work when nobody who built it is present, on inputs nobody anticipated, for years, while being maintained by somebody who has other things to do.

I learned this at the robotics company because our products actually shipped. We had customers on six continents running our hardware in undergraduate teaching labs, which is genuinely one of the more hostile environments you can put a machine into. Students do things to equipment that no failure mode analysis will predict. They will command a step input of maximum amplitude because they want to see what happens. They will leave the emergency stop engaged and file a bug. They will plug the encoder into the wrong port.

That taught me that shipping is a different discipline from inventing. Shipping rewards yield, documentation, support, spare parts, honest specifications and the ability to diagnose a fault over the phone from four thousand kilometres away. None of those are exciting. All of them decide who is still operating in five years.

So when you watch a robotics video, run the same three questions I do. What was curated that will not be curated in the field? What is the mean time between failures on that mechanism, and how do we know? Who fixes it when it breaks, how fast, and who pays?

If the company has good answers, they are much further along than the video suggests. If they have never been asked, the video is the product, and the product is a video.

Chapter 05Every degree of freedom is a tax

Here is a piece of engineering intuition that I wish were more widely held, because it explains a great deal about why humanoid form factors are hard and why specialised machines ship first.

Every degree of freedom you add to a machine costs you at least six things.

It costs an actuator, which is money, weight and a heat source. It costs a transmission, which is backlash, compliance and a wear item. It costs a sensor, usually at least one encoder, and possibly a torque sensor, which is money and a calibration. It costs cabling and connectors routed across a joint that moves, which is the single most common source of field failure I have ever seen. It costs a calibration procedure, which is time on the line during manufacture and time in the field after service. And it costs dimensionality in the control problem, which makes both the engineering and the learning harder.

That is per joint. A common industrial arm has six. A humanoid with two arms, two legs, a torso and a neck is somewhere in the thirties before you get to hands, and a pair of genuinely dexterous hands can double that.

So a humanoid is not a robot arm with a body attached. It is roughly an order of magnitude more mechanism, and mechanism is the part that does not benefit from a model release.

I am not saying this to argue against the form factor. There are strong arguments for it and I will make them properly later. I am saying it because the tax is real and any honest analysis has to pay it. When somebody tells me their general purpose machine will be cheaper than a specialised one, the burden of proof is heavy, and the argument has to run through volume manufacturing rather than through architecture, because architecturally the general machine costs strictly more.

The corollary is the design principle that has produced almost every robotics business that works. Remove degrees of freedom until the job stops being doable, then add one back.

The most profitable robots in the world are stunningly dumb by the standards of a research lab. A gantry with three linear axes. A delta robot with four. A mobile base with two driven wheels and a caster. These machines have been running twenty four hours a day for decades in facilities you have never heard of, and they are ruthless about not paying for a degree of freedom that does not earn its keep.

The founders I take most seriously are the ones who arrived at their form factor by subtraction. They started with the job, watched it being done for a hundred hours, worked out the minimum mechanism that accomplishes it, and built that. The ones I worry about started with a form factor because it was exciting and went looking for a job it could do.

There is a version of this discipline that applies to sensing too. Every sensor you add is a data stream you must fuse, a failure mode you must detect, a calibration that will drift and a cost you must carry on every unit forever. Adding a sensor is easy in a prototype and expensive in a product. The good teams treat sensor addition as a decision requiring justification, not a default.

Chapter 06What embodied AI means once you take the marketing out

The phrase embodied AI is used to mean a dozen different things, which makes it close to useless in a pitch and worth defining carefully here.

Stripped down, it means a learned policy that closes a loop against physics. That is it. The distinguishing feature is not that a model is involved. It is that the model's output changes the world, the changed world is then observed, and the observation feeds the next decision. The model is inside the loop.

That is a categorically harder setting than the one most machine learning systems live in, for three reasons that are worth understanding properly.

The first is that errors compound. A language model that produces a mediocre sentence produces a mediocre sentence. A policy that produces a slightly wrong joint command produces a slightly wrong state, from which it makes its next decision, and small errors accumulate along a trajectory until the machine is somewhere its training data never described. This is a well studied problem and the mitigations are known, but it means that per step accuracy is a misleading metric. What matters is behaviour over a horizon.

The second is that the data does not exist. Text and images were lying around on the internet in quantities that made the last decade possible. There is no equivalent corpus of a robot's own sensorimotor experience. Every hour of it has to be produced, either by teleoperating a real machine, which is slow and expensive and produces data specific to that machine's kinematics, or in simulation, which is fast and free and slightly wrong in ways that matter. Data in this field is a capital expenditure, not a download. I will come back to this because I think it is the central structural constraint of the sector right now.

The third is that the consequences are physical. A wrong output in a chat interface is an annoyance. A wrong output from a machine with authority is a broken part, a damaged product, or an injured person. This changes the engineering posture entirely. You cannot ship a system whose failure mode is unbounded, which means every serious machine has layers of ordinary deterministic safety underneath the learned parts. Torque limits. Velocity limits in the presence of a human. Watchdogs. Certified emergency stop circuits that are not software at all.

Notice that all three of these are physical constraints rather than intelligence constraints. That is the theme. The cognitive layer has genuinely and impressively improved. The constraint moved. It did not disappear.

What I find most interesting about the current moment is not any single capability. It is that a set of costs came down at roughly the same time. Sensing got cheap because phones consumed the world's supply of cameras and inertial measurement units and drove the price to nothing. Compute at the edge got cheap and power efficient for reasons that had nothing to do with robotics. Actuator supply chains matured on the back of other industries. And methods arrived that let a machine learn a behaviour from demonstration rather than requiring an engineer to specify it.

Any one of those is interesting. Together they change which projects are worth attempting. That is a real shift and I am not going to be coy about it. But it is a shift in what is worth attempting, not a guarantee about what will succeed, and the distance between those two statements is where this book lives.

Part 02The physics you do not get to negotiate with

Chapter 07Power, mass, and the circular argument

Every mobile robot contains an argument that runs in a circle, and how a team resolves that circle tells you most of what you need to know about their engineering judgment.

It goes like this. The machine needs to do work, so it needs actuators with enough torque. Torque costs mass. Mass has to be carried, which costs power. Power costs battery. Battery costs mass. Which costs torque. Around it goes.

The circle closes at some operating point, and where it closes determines the machine's duty cycle, which is the fraction of the day it can actually be working. Duty cycle is the number that decides whether the economics work, because a machine that runs four hours and charges for two is a fundamentally different asset from one that runs a full shift.

Batteries improve slowly. That is not pessimism, it is the observed rate. Energy density in commercially available cells has improved at a modest compound rate for decades, and the improvements arrive as incremental chemistry and packaging gains rather than as step changes. A robotics company that needs a battery breakthrough to work does not have a plan, it has a wish.

So the levers that are actually available are the boring ones, and the good teams pull them hard.

You can reduce mass, which is materials engineering and structural design and a willingness to spend money on things the customer never sees. You can improve transmission efficiency, which means paying attention to gear choice and lubrication and bearing preload. You can recover energy, which legged machines can do at certain gait phases and which is genuinely useful. You can lower the duty cycle requirement by designing the workflow around charging, which is often the smartest available move and is a business decision rather than an engineering one. Or you can eliminate the battery entirely by tethering the machine or putting it on a rail or bolting it to the floor, which is why so much of the world's productive robotics is bolted to the floor.

I want to underline that last option because it gets dismissed as unambitious. It is not unambitious. It is the correct answer whenever the job comes to a fixed location, and a startling number of jobs do. Choosing to be stationary buys you unlimited power, unlimited compute, no battery mass, a rigid known kinematic base and a dramatically simpler safety case. That is an enormous set of gifts, and you should only refuse them if the job genuinely requires travel.

The related trap is thermal. Motors dissipate heat roughly with the square of current, and current is roughly proportional to torque. So a machine holding a heavy load in a static pose, which looks like it is doing nothing, can be running hotter than the same machine moving quickly. Continuous torque ratings and peak torque ratings differ by a large factor and the gap between them is thermal. A machine specified on peak numbers will derate in the field, and derating shows up to the customer as the robot getting slower in the afternoon.

I have seen that specific failure kill a pilot. The machine worked in the morning, worked in the demo, and slowed down under sustained load in a warm building in August. The customer did not describe it as a thermal derate. The customer described it as the robot not working, and cancelled.

Chapter 08Actuators, where the money and the failures both live

If you want to understand a robotics company's cost structure and its reliability profile at the same time, look at the actuator. It is usually somewhere between a quarter and a half of the bill of materials on a machine with many joints, and it is where a very large share of field failures originate.

The core problem is that electric motors are efficient at high speed and low torque, and robots need low speed and high torque. So almost every joint contains a transmission, and the transmission is where the engineering tradeoffs get made.

A high ratio precision gearbox of the sort used in industrial arms gives you excellent positional accuracy and very low backlash, and it is expensive, heavy for its output, and largely non backdrivable. Non backdrivable means you cannot push the joint and have it move, which is fine for a caged arm and problematic for a machine that has to sense and modulate contact with the world.

Planetary and cycloidal gearing sits at a different point, generally cheaper, with more backlash. Series elastic actuation deliberately puts a spring between the motor and the load, which gives you force sensing and shock tolerance at the cost of bandwidth, because a spring is a low pass filter and you have just added one to your control loop. Quasi direct drive uses a low ratio with a large diameter motor, which gives you backdrivability and good force control, at the cost of torque density and therefore mass.

None of these is correct in general. Each is correct for a particular job. The reason I am walking through them is that this choice is the most consequential single decision in a machine's design, it is close to irreversible after the first prototype, and it is almost never discussed in public material about robotics companies. If you get one chance to ask an engineering question, ask about the actuator and listen to whether the answer includes the tradeoff they accepted.

On the failure side, the pattern I have seen most often is not the motor. Motors are mature. It is everything around the motor. Bearings that ingest particulate because the seal was specified for a cleaner environment than the one the machine ended up in. Lubricant that migrates or degrades under thermal cycling. Backlash that grows over a hundred thousand cycles until the positional repeatability drifts out of spec, which the customer experiences as the machine becoming inaccurate for no apparent reason. Encoder mounts that shift. And cable flex fatigue at the joint, which I have already named and will name again, because it is genuinely that common.

The unglamorous truth is that a robotics company's second most important document, after the specification of the job it does, is the maintenance schedule. Teams that write that document early build differently. They design for service access, they make wear items replaceable without a full teardown, and they instrument the joints so a drift can be detected before it becomes a stoppage. Teams that write it late discover in year two that servicing the machine requires removing eleven fasteners in a specific order in a space nobody can reach, and their service cost per unit per year quietly eats their margin.

Chapter 09Sensing, and the gap between measuring and knowing

A sensor does not tell you what is true. It gives you a noisy, delayed, partially observed function of what is true, and the entire discipline of state estimation exists to close that gap.

I find this is where non engineers most consistently misjudge robotics, because the outputs look so clean. A depth camera produces a beautiful point cloud on a screen. It is easy to conclude that the machine knows where things are. It does not. It has a measurement with a noise model, a calibration that was correct at some temperature on some day, an occlusion structure, and a set of materials that will defeat it entirely.

Every sensing modality has a specific set of things it is blind to, and knowing the blind list is the actual expertise.

Structured light and time of flight depth sensors struggle with transparent and specular surfaces. Glass, polished metal, clear plastic film, liquid surfaces. A warehouse full of shrink wrapped pallets is a harder perception environment than it looks, and shrink wrap is everywhere. Stereo vision needs texture, so it degrades on blank walls and uniform floors. Lidar is excellent geometrically and gives you nothing about material or colour, and it has its own problems with retroreflectors and rain. Cameras are cheap and information dense and are a function of lighting, which changes across a day in any building with windows.

Proprioception, meaning the machine's sense of its own configuration, is usually the most reliable channel it has, which is why so much good engineering leans on it. Joint encoders are accurate and fast. But the map from joint angles to the position of the end effector runs through the kinematic model, and that model is only as good as its calibration, and calibration drifts with temperature, with wear, with a collision nobody logged.

Force and tactile sensing is the modality that matters most for manipulation and is the least mature. A human hand has an extraordinary density of mechanoreceptors and uses them continuously, mostly below conscious awareness, to detect slip and adjust grip in milliseconds. Robotic tactile sensing has real and interesting approaches, and the ones I have seen work do so in constrained settings. Making a tactile skin that is dense, durable, cheap and manufacturable, and that survives being wiped down and knocked against things every day for three years, is genuinely unsolved and I am comfortable saying so.

The practical consequence is sensor fusion, which is the art of combining several partially wrong sources into one estimate that is less wrong than any of them. This is old, well understood mathematics for the linear cases and an active area for the rest. What I want to flag is the operational side rather than the mathematical one. Fusion is only as good as the calibration between the sensors, and the extrinsic calibration between a camera and an arm base is a thing that must be established, verified, and re established after service. A machine that requires a specialist to calibrate is a machine with a support cost problem. A machine that can self calibrate against a known fixture in ninety seconds is a machine that can be serviced by the customer's own maintenance technician, and that difference decides the shape of the business.

Chapter 10Accuracy, repeatability, and the specification games

There is a set of numbers that appear on every robot datasheet and that are routinely misread, including by buyers who should know better, and understanding them properly is a cheap way to avoid an expensive disappointment.

Repeatability is how closely a machine returns to the same place when commanded to the same place, over and over. Accuracy is how closely it reaches the place you actually meant in the real world. These are entirely different quantities and industrial robots are typically excellent at the first and mediocre at the second.

The reason is structural. Repeatability depends on the joints being consistent, which encoders and good mechanics deliver. Accuracy depends on the kinematic model being right, which requires that the link lengths, joint offsets and deflections in the physical machine match the numbers in the controller. They never quite do, because parts are manufactured within tolerances, because the structure deflects under load, and because everything expands with temperature.

So a machine can return to a taught point beautifully and be several millimetres off if you ask it to go to a coordinate it was never taught. Traditional automation solved this by teaching every point, which is why traditional automation requires the world to be fixtured and unchanging. If a machine is going to work from perception rather than from taught points, accuracy suddenly matters a great deal, and calibration becomes a first class engineering problem rather than a factory step.

There is a second specification game worth knowing about, which is payload. A payload figure is usually stated at the wrist, at a particular reach, with the load's centre of mass at a particular distance. Move the mass further out and the effective payload drops, sometimes dramatically, because what the joint actually experiences is a moment rather than a force. A machine rated for a given payload that is asked to hold that payload at the end of a long tool will not deliver its rated performance, and the failure appears as position error, oscillation or thermal derating rather than as an obvious refusal.

Speed figures play a similar game. A maximum joint speed is not a cycle time. Real cycle time is dominated by acceleration and deceleration, by settling at the end of each move, and by the time spent waiting for perception. I have seen quoted cycle times miss reality by a factor of two, not through dishonesty but because the quote assumed continuous motion and the real task has a settle and a decision in the middle of every cycle.

The practical advice is to specify and evaluate machines on task level metrics rather than component level ones. Not joint speed, but completed items per hour with the actual objects. Not repeatability, but placement error on the actual part in the actual fixture. Not payload, but whether the machine holds your heaviest item at your longest reach for your full shift without derating.

Insisting on task level numbers has a useful side effect, which is that it immediately reveals whether the vendor has run the task. A company that has genuinely done it will answer with a number and a caveat. A company that has not will answer with component specifications and an assurance.

Chapter 11Why manipulation is harder than walking

There is a widespread assumption that locomotion is the hard part of humanoid robotics, presumably because falling over is visually dramatic. In my view it is the reverse, and the reason is instructive.

Locomotion is a problem with relatively few contact events, mostly predictable geometry, and a well understood underlying physics. A legged machine is a controlled inverted pendulum with intermittent contact, and while that is not easy, it is a bounded problem that a great deal of excellent research has attacked directly. The floor is usually flat, usually rigid, usually where you expect it, and the number of things you are touching at any moment is small.

Manipulation is the opposite in every respect. The objects are unknown. Their mass, mass distribution, friction, deformability and fragility are unknown and cannot be observed directly. The contact geometry is complicated and changes continuously during the task. The number of simultaneous contacts is large and shifting. Small differences in where you touch an object produce entirely different outcomes. And a great many tasks are not about grasping at all, they are about a sequence of contacts, like opening a drawer, threading a cable, or peeling one item off a stack.

Here is the physical detail that convinced me. Contact makes the dynamics non smooth. In ordinary motion, a small change in your command produces a small change in the result. At the moment of contact, that stops being true. Touch a surface a millimetre earlier and the force history is completely different. Mathematically this is a discontinuity, and both classical control and gradient based learning find discontinuities difficult. That is not an implementation problem. It is a property of the world.

Then add the hand. A gripper with two parallel jaws is enormously capable for a narrow set of tasks and is why so many working systems use one. It is also incapable of most of what a human hand does, and it achieves what it does by requiring that objects be presentable, roughly known, and approachable from a good angle. Adding fingers adds degrees of freedom, with all the taxes from the previous part, plus the need for tactile sensing distributed across surfaces that will be abraded daily, plus a very large increase in the difficulty of both control and learning.

So the honest state of things as I see it is this. Constrained manipulation in structured settings with known object classes works and is deployed at scale. General dexterous manipulation of arbitrary objects in unstructured settings is an active research frontier with real progress and no settled answer. Anyone who tells you where that line will be in five years is guessing, including me, so I will not.

What I will say is a practical thing for founders. If your product depends on general dexterity, you have taken on a research risk and you should say so plainly, price your runway accordingly, and find a narrower job that pays the bills while you work on it. If your product works with constrained manipulation, you have a much better business and you should resist every temptation to widen the scope before the first version is boringly reliable.

Chapter 12Reliability arithmetic and the serial chain problem

I want to do a piece of arithmetic that changes how people look at machines, because it is simple and it is routinely ignored.

Suppose each of your joints has a ninety nine percent chance of getting through a given week without a fault. That sounds excellent. Now build a humanoid with thirty joints. If those failures are independent, the probability that the whole machine gets through the week is ninety nine percent raised to the thirtieth power, which is about seventy four percent. So roughly one week in four, that machine stops.

Now add the sensors, the compute, the power system, the network, the software and the mounting hardware. The chain is much longer than thirty. A serial system is only as reliable as the product of its parts, and products of numbers slightly below one fall off a cliff as the chain grows.

This is the mathematical version of the intuition that complex machines break more. It is also the mathematical reason that removing degrees of freedom is not just a cost decision, it is a reliability decision, and the two compound.

There are only a few real responses, and mature robotics organisations use all of them.

Raise per component reliability, which means better parts, derating, and design margin, and which costs money on every unit. Shorten the chain, which is the subtraction discipline. Break the serial dependency with redundancy where it is affordable, which is common in aerospace and rare in commercial robotics because of cost. Detect degradation before it becomes a stoppage, using the machine's own sensors to watch for rising current draw, growing position error, changing vibration signature or thermal creep. And design for fast recovery, so that when it does stop, the time to running again is short.

That last one is underrated and it is where I would put effort if I were building. Customers do not actually experience mean time between failures. They experience availability, which is uptime divided by total time, and that depends on both how often you fail and how long you are down. A machine that fails monthly and is back in twenty minutes with a swappable module can deliver better availability than a machine that fails quarterly and is down for three days waiting for a field engineer and a part.

Availability is the number the customer's operations team will actually put in a contract, and if you have not built a service model that hits it, you cannot sign that contract, no matter how good the machine is.

I would go one step further. In my experience the single most valuable engineering investment in a young robotics company is not capability, it is observability. Instrument everything. Log every joint's current, temperature, position error and cycle count. Ship the fleet with the ability to phone home. The teams that do this can diagnose a fault remotely, spot a wear pattern across the fleet before it becomes a recall, and answer a customer's question with data instead of an apology. The teams that skip it spend year two flying engineers to sites to find out what happened.

Chapter 13The simulation gap, and how it is actually crossed

Simulation is how modern robot learning gets enough experience to be useful, because real hours are expensive and simulated hours are nearly free. It also produces policies that work beautifully in simulation and fall over in a hallway, and the difference between teams is entirely in how seriously they treat that.

The gap has specific, nameable causes rather than being a vague mystery.

Contact and friction models in simulators are approximations, and they are the approximations that matter most for exactly the tasks we care about. Actuator dynamics are usually idealised, so the simulated motor produces the torque you asked for instantly, while the real one has current loop dynamics, thermal derating, backlash and compliance. Sensor models are optimistic, with clean images, exact depth, no motion blur, no rolling shutter, no lens dirt. Mass and inertia parameters come from a computer aided design model that does not match the built machine, because the built machine has cable bundles and adhesive and a part somebody substituted. And latency, which I keep returning to, is frequently absent from simulation entirely, so the policy learns to act on information it will never have that fresh.

The techniques for crossing the gap are known and unglamorous.

System identification, which means measuring your actual machine's parameters and putting the measured values into the simulator rather than the design values. This is the highest return activity available and it is routinely skipped because it is tedious.

Domain randomisation, which means training across a distribution of physical parameters so the policy is robust to being wrong about any one of them. It works, and it costs you performance, because a policy that is robust across a wide distribution is by construction not optimised for the true one.

Deliberately modelling the ugly parts, which means putting real latency, real sensor noise, real actuator limits and real quantisation into the simulator even though it makes everything slower and harder.

And structured real world fine tuning, where the simulated policy is a starting point and a limited quantity of carefully collected real data closes the last distance.

The thing I want to leave you with is a diagnostic. When a team tells me their policy transfers, I ask what broke the first time they tried it on hardware. If the answer is specific, mechanical and slightly embarrassing, they are real. If the answer is that it just worked, either their task is simple enough that it should have, which is fine and they should say so, or they have not run it enough times, in enough conditions, to have met the failure yet.

Chapter 14Dust, temperature, and the other things that end pilots

I want to close this part with the list of things that actually kill deployments, because it is almost never the thing the engineering team was worried about.

Particulate. Warehouses have dust, food facilities have flour and sugar and water, construction sites have everything. Dust gets into bearings, coats lenses, blocks vents and changes the thermal behaviour of the whole machine. Ingress protection ratings are cheap to specify and expensive to actually achieve, and the difference shows up nine months in.

Temperature. Buildings are not climate controlled the way labs are. A machine validated at twenty degrees may behave differently at thirty five, because clearances change, lubricant viscosity changes, electronics derate and batteries lose capacity. Cold is worse for batteries and worse for lubricant and can shift a kinematic calibration measurably.

Vibration and shock. Every fastener in a machine that vibrates wants to come loose. Every connector wants to walk out of its socket. This is a solved problem in industries that have been fighting it for a century, using thread locker, lock washers, strain relief and connectors with positive retention, and it is a problem young robotics teams rediscover from first principles at customer sites.

Electromagnetic environment. Industrial facilities are electrically noisy. Variable frequency drives, welders and large contactors generate interference that will find your encoder cable if you routed it next to a power line, and the symptom will be an intermittent fault that nobody can reproduce.

Network. Facility wifi is a hostile environment with dead zones, roaming failures and traffic you do not control. Any architecture that assumes reliable connectivity will be tested by a building with a metal mezzanine.

People. This is the big one. Humans will move the thing your robot was calibrated against. They will stack a pallet in the aisle. They will unplug it to charge a phone. They will disable a safety interlock because it slows them down. They will not follow the procedure. This is not a criticism of them, it is what a real workplace is, and a machine that requires a disciplined environment is asking the customer to change in order to accommodate your product, which is a request that gets refused.

Every one of these is boring. Collectively they are the reason pilots do not convert, far more often than any deficiency of intelligence. If I could get one message to a founder who is about to run their first pilot, it would be to spend the week before it in the customer's building, at the hour the machine will run, looking specifically for these six things.

Part 03Humanoids, argued honestly in both directions

Chapter 15The case for the human shape, made properly

I run a company whose stated business is humanoid robotics and embodied AI, so you should discount my enthusiasm accordingly and I would rather say that out loud than have you discover it. What I can do is give you the strongest version of the argument, and then the strongest version of the counterargument, and let you weigh them.

The case for the human form factor is not that it is elegant or inevitable. It is an argument about the environment, and it has three legs.

The first is that the built world is dimensioned for human bodies. Doorways, stair risers, counter heights, shelf depths, tool handles, vehicle cabs, valve wheels, ladder rungs, the height of a light switch and the width of an aisle are all what they are because of the animal that built them. A machine with roughly human proportions can operate in that world without the world being modified. A machine with different proportions requires the world to change, and changing a building is slow, expensive and often impossible in a leased facility.

This matters more than it sounds. A very large fraction of the cost of deploying industrial automation historically has not been the machine. It has been the integration, which frequently means rebuilding the workspace around the machine. Fixturing, conveyors, cages, part presenters, floor marking, guarding. If a machine can slot into an unmodified space, an enormous cost line disappears, and it disappears at exactly the sites that could never justify traditional automation.

The second leg is tooling. Human workplaces are full of tools that assume a hand. Not just hand tools but interfaces of every kind. Buttons sized for fingers, handles sized for grip, screens at eye level, containers with lips designed to be lifted a particular way. A hand shaped end effector can use the existing tool inventory rather than requiring a custom end effector per task, and custom end effectors are a substantial hidden cost in conventional automation.

The third leg is the one people find least intuitive and I find most interesting. If you want to learn behaviour from demonstration, and demonstration means watching a person, then a machine whose kinematics resemble a person's can use that demonstration more directly. The mapping from a human arm's motion to a robot arm's joint commands is a real problem, and it gets easier the more similar the two are. There is a very large amount of recorded human activity in the world. Whether and how well it can be used is an open technical question that I am not going to pretend is settled, but the argument that anthropomorphic kinematics lowers the barrier is a coherent one.

Put those together and the humanoid case is essentially an argument about the cost of integration and the cost of data, not an argument about capability. That is a more sober case than the one usually made, and I think it is a better one, because it is falsifiable. If integration costs for specialised machines fall dramatically, the first leg weakens. If demonstration data turns out to transfer poorly across morphologies, the third weakens.

That is the shape of the argument I hold. Now let me make the other one properly, because I think a lot of people in this sector have never heard it stated well.

Chapter 16The case against, made just as properly

If I were arguing against the humanoid form factor, and I have made this argument in private more than once, I would make it on unit economics and I would make it hard.

Start with what I established in part one. A general purpose machine costs strictly more mechanism than a specialised one. More joints, more actuators, more sensors, more cabling, more calibration, more failure modes, a longer serial reliability chain and a harder control problem. Every one of those costs is permanent and recurs on every unit and in every service visit.

Against that, the general machine offers flexibility. The question is whether the customer's actual job requires flexibility, and the honest answer in most industrial settings is no. A facility does the same things every day. It has been engineering the variance out of its processes for decades, because variance is what makes a facility unprofitable. The workflows that remain are often extremely repetitive, and a repetitive workflow is exactly the case where a specialised machine wins on every metric that matters.

Then consider the historical record, which is not on the humanoid's side. Automation has advanced overwhelmingly through specialisation. The gantry, the conveyor, the delta picker, the fixed arm in a cage, the automated storage and retrieval system, the wheeled transport robot. Each of those won its job by being extremely good at exactly one thing and extremely cheap because it did not carry the cost of being anything else. Whenever a general solution has competed with a specialised one on a repeatable task, the specialised one has generally won, and it has won on cost.

The rebuttal to this is volume manufacturing, and it deserves to be stated because it is the real argument. If one machine design can address many jobs, then it can be produced in far greater volume than any specialised machine, and volume drives cost down through amortised tooling, supply chain leverage and learning effects. In that framing, the general machine loses on architecture and wins on scale. That is a genuine possibility and it is the crux of the whole disagreement.

I do not know how that resolves. I want to be clear that I do not know, because this is precisely the sort of question the sector answers with a confident number and no mechanism. What I can say is what would have to be true for the scale argument to work. It would require that a single machine design actually addresses many jobs without per job engineering that eats the savings. It would require that the manufacturing volumes materialise, which requires demand, which requires the jobs to be economic at the price the early units cost. And it would require that the reliability chain problem be solved well enough that service costs do not consume the savings.

Those are three hard, empirical requirements. They are checkable. Anyone evaluating this sector, including me, should be checking them rather than debating the concept.

There is a third position, and it is where I actually spend most of my attention. The two form factors are not in a fight. Specialised machines will keep taking the high volume, low variance, fixed location work because that is what they are for. The interesting question is what happens to the long tail of work that is too varied to specialise for and too physical to software away, in buildings too small or too changeable to re engineer. That tail is enormous and it has never been addressable. Whether it becomes addressable is the open question of the decade, and it is a better question than which shape wins.

Chapter 17Legs are an argument about floors

Bipedal locomotion attracts more attention than any other part of this field and deserves less of it than it gets, so let me try to put it in proportion.

Legs exist to handle terrain that wheels cannot. That is the entire functional argument. Stairs, kerbs, thresholds, debris, uneven ground, gaps, ladders, and the general condition of a space that was not built for a machine to roll through.

So the question of whether a machine needs legs is a question about the floor it will work on. And most industrial floors, by design and at considerable expense, are flat. Warehouses are flat because forklifts and pallet jacks need them flat. Factories are flat. Distribution centres are flat. Data halls are flat. Cleanrooms are flat. In all of those places a wheeled base is superior on essentially every axis. It is cheaper, lighter, more energy efficient by a wide margin, more stable, mechanically simpler, and it does not have to solve balance at all.

Wheels also have a decisive advantage that is rarely stated. A wheeled machine that loses power stops. A bipedal machine that loses power falls, and something that falls is a hazard, and a hazard changes the entire safety case, which changes what certification you need, which changes where you are allowed to operate, which changes your addressable market. That is a long chain of consequence hanging off one property.

Where legs earn their cost is the built environment for people that has not been flattened. Stairs in a commercial building. A residential home. A construction site mid build. A ship's interior. Older industrial plants with thresholds and floor drains and equipment pads. Anywhere a wheel gets stuck two centimetres from where it needed to be.

There is also a middle ground that gets less attention than it should, which is legs with wheels, or wheeled bases with an ability to handle small obstacles, or tracked bases. These hybrids give a lot of the terrain capability at a fraction of the control complexity and energy cost. I find teams that have seriously evaluated the hybrid options tend to have thought harder about their actual deployment environment than teams that went straight to two legs.

The energy point is worth a sentence of its own because it links back to part two. Legged locomotion is substantially less efficient than rolling for the same distance and payload, for straightforward mechanical reasons involving repeated acceleration of limbs and the energy lost in each impact. That inefficiency comes directly out of duty cycle, which comes directly out of unit economics. A legged machine is buying terrain capability with runtime, and if the terrain is flat, it has bought nothing and paid full price.

So my working rule is simple. If the job is on a flat floor, legs are a liability and I want to hear a very specific reason for them. If the job crosses a stair, legs or a hybrid are the only honest answer. And if a team has not walked the actual route the machine will take, with a tape measure, they do not yet know which one they need.

Chapter 18Hands, and the frontier nobody has crossed

If I had to name the single hardest unsolved engineering problem standing between the current state of humanoid robotics and the thing people imagine when they hear the word, it is the hand.

Not the arm. Arms are good. Six and seven degree of freedom arms with excellent repeatability have been an industrial commodity for decades and the control problem is well understood. The hand is a different order of difficulty and the difficulty is not primarily about the fingers.

A human hand has something in the region of twenty seven degrees of freedom, and if you tried to build that with conventional robotic joints you would produce something enormous, fragile and unaffordable, which is why nobody does. Real robotic hands underactuate, meaning fewer motors than joints, with tendons and mechanical linkages coupling the motion so that a single actuator produces a compliant, self adapting grasp. This is clever, mature engineering and it works well for wrapping around an object.

The gap is sensing and durability, not actuation.

Human grip is a continuous closed loop control problem running on tactile feedback. You pick up a paper cup and you apply just enough force. You do not compute that. Mechanoreceptors detect incipient slip and reflexes increase grip force within tens of milliseconds, below conscious awareness. Take that channel away and the strategy collapses to squeezing hard enough for the worst case, which crushes the cup.

So a robotic hand without dense tactile sensing must either know the object in advance, which means the environment is structured, or squeeze conservatively, which limits it to robust objects. Both are entirely workable product strategies and a lot of good deployed systems rely on exactly that. Neither is general dexterity.

Building the sensing is where it gets brutal. You need it distributed across curved surfaces, at reasonable spatial density, with fast response, and it has to be routed out of a moving multi jointed structure without a wiring bundle that defeats the mechanism. Then it has to survive. This surface is being pressed against metal, dragged across cardboard, wiped with a cleaning agent, and occasionally hit. It has to do that for years, at a cost per unit that survives a bill of materials review, and it has to be manufacturable in volume rather than assembled by a graduate student.

There are genuinely interesting approaches in the field. Optical tactile sensing, where a camera inside the fingertip watches a deformable surface, gives remarkable spatial detail. Capacitive and resistive arrays are cheaper and coarser. Acoustic and vibration based methods detect slip differently. I have watched people work on all of them and there are real results.

What I have not seen, and I would tell you if I had, is a tactile skin that is simultaneously dense, durable, cheap and manufacturable. Until that exists, dexterity in unstructured settings stays constrained. Whether it arrives, and by what route, is an open question and I will not pretend to know.

This is the most useful thing I can hand a founder in this part of the book. If your business plan requires human level dexterity, your business plan contains a materials science and manufacturing bet that has nothing to do with your software. Know that you are making it. Do not let it hide inside a slide about AI.

Chapter 19The data problem is the actual bottleneck

I said earlier that data in robotics is a capital expenditure rather than a download, and I want to develop that, because in my view it is the structural constraint that shapes this entire sector right now.

Language models were possible because a vast corpus of human text already existed, produced for other reasons, sitting on public infrastructure. Vision models likewise. Nothing equivalent exists for embodied action. There is no internet of manipulation. The data describing how a body moves through contact with the world in service of a task was never recorded, because until recently there was no reason to record it.

So it has to be manufactured, and there are only a handful of ways to do it.

Teleoperation, where a person drives the robot through the task and the machine records its own sensors and commands. This produces exactly the right kind of data, correctly embodied for that machine. It is also slow, expensive in human hours, limited by how many machines you have, and tied to the specific kinematics of the robot used, so it does not transfer cleanly when you revise the hardware. Which you will, because you are a hardware company.

Simulation, which is fast and cheap and wrong in the ways I described in part two, and requires the whole apparatus of system identification and randomisation to be useful.

Human video, meaning learning from recordings of people doing tasks. There is a very large amount of it. The difficulty is that it lacks the action labels. You see what happened, not what forces were applied or what the person's intent was, and the mapping from a human body to a machine body is not trivial. This is an active research direction with real progress and genuine open questions.

Fleet data, meaning the machines you have already deployed logging their own operation. This is the one I find most strategically interesting, because it is the only source that scales with your business rather than with your spending. Every machine in the field is producing exactly the data most relevant to the jobs your customers actually have. It compounds.

Fleet data also has a property that makes it a real durable advantage rather than a temporary lead, which is that you cannot buy it and a competitor cannot replicate it without also deploying. That is the sort of asset I look for in any business, and it is one of the reasons I keep telling founders to get machines into the field earlier than feels comfortable, even doing a narrower job than they wanted. The narrow deployment is not just revenue. It is the beginning of the only data source that compounds.

The tension is obvious and worth naming. Getting to deployment requires capability, and capability requires data, and the best data comes from deployment. That is a bootstrapping problem, and the way out of it, historically and in every case I have watched work, is to start with a job narrow enough that current capability is already sufficient, and then let the fleet fund the widening.

I think this is the most important strategic point in the book, so let me say it as plainly as I can. In robotics, scope discipline is not modesty. It is the mechanism by which you acquire the asset that makes scope expansion possible later.

Chapter 20What would change my mind

I try to hold every position in a form that can be falsified, because the alternative is having beliefs that are just a personality. So here is what I would need to observe to change my view on humanoids, in either direction.

I would become substantially more confident if I saw fleets of the same machine design doing genuinely different jobs at different customers with no per site engineering beyond configuration. That is the load bearing claim of the whole general purpose thesis and it is directly observable. Not a demo of many tasks, which proves capability. A fleet doing many jobs with the same software build, which proves the economics.

I would become more confident if service cost per unit per year fell across successive generations of a design while availability held or improved. That would indicate the reliability chain problem is being solved by engineering rather than being absorbed by the manufacturer's margin.

I would become more confident if tactile sensing appeared as a standard, cheap, durable component rather than a research artefact, because that is the specific gate on dexterity.

I would become less confident if the pattern I have already seen a few times became the norm, which is a general machine deployed to a customer and then progressively narrowed by the integration team until it is doing one repetitive task in a fixed pose, at which point everyone involved has purchased a very expensive specialised machine. That failure mode is quiet, it looks like success from outside, and it is worth watching for.

I would become less confident if the per job engineering cost stayed high after the first ten deployments of a given design, because that is the signal that the flexibility is nominal rather than real.

And I would become less confident if the sector's public communication continued to run well ahead of its deployment evidence, because in my experience that gap is not merely cosmetic. It changes who gets funded, it changes what gets built, and it eventually produces a correction that damages the serious operators along with everyone else.

That last one is why I am writing a book with no forecasts in it. I have watched what happens to a sector when the story outruns the substance, in a different industry, at close range, and I would rather this one did not repeat it.

Part 04The commercialisation gap, where the companies actually die

Chapter 21The gap, described precisely

I have said the gap between the demo and the deployment is where almost every robotics company dies. Let me describe what is actually in it, because naming it as a gap makes it sound like a distance to be crossed, and it is not. It is a set of specific requirements that appear all at once and have to be satisfied simultaneously.

A machine that works becomes a product when six things are true at the same time.

The unit cost is low enough that the customer's payback period is short enough for their finance function to approve without a special process. The machine is reliable enough that its availability meets what the operations team needs to run their day. It integrates into an existing workflow without requiring the customer to redesign their operation. Somebody can install it, and that somebody is not one of your three best engineers. Somebody can service it, and that somebody is reachable within the customer's tolerance for downtime. And the whole arrangement holds together under a commercial structure both sides can live with.

Miss any one of the six and the machine does not deploy, no matter how good the other five are. That simultaneity is the reason this gap kills companies. Teams optimise the one they are best at, usually capability, and cross four of the six brilliantly.

Here is the shape of the failure in practice, and I have watched it enough times to recognise it early. A company builds an impressive machine and finds a customer willing to pilot. The pilot is staffed heroically, with founders on site, custom code written overnight, and a level of attention no business can sustain. The pilot succeeds on its own terms. Everyone is pleased. Then the conversation turns to a rollout, and the customer asks what happens when it breaks at two in the morning, and who trains the technicians, and what the per unit price is at fifty units, and what the service contract costs, and whether it works in the other building, which has a different floor and a different process. The company has answers to none of it, because it has been building a machine rather than a business, and the rollout does not happen.

Nobody involved describes this as failure. The pilot is reported as a success. The company will say it has a deployment. It is a demonstration with a purchase order attached.

The tell, the thing I look for, is the ratio of second orders to first orders. First orders are cheap. Every large enterprise has an innovation budget and somebody whose job is to find things to spend it on, and getting a first order is a sales problem. The second order comes out of an operating budget, requires an operations person to advocate for it, and only happens if the machine actually made their life better in a measurable way. A company with twelve customers and no second orders is in worse shape than a company with three customers and eight second orders, and the first one usually looks better on a slide.

So if you are building, instrument for the second order from the beginning. If you are evaluating, ask for the number.

Chapter 22Pick a job, not a market

The single most common strategic error I see in robotics companies, and I see it constantly, is that they have chosen a market instead of a job.

A market is a category. Logistics. Agriculture. Elder care. Construction. Manufacturing. Choosing a market feels like focus and is not, because a market contains hundreds of distinct workflows with different physical requirements, different buyers, different budgets and different failure tolerances.

A job is a specific physical task, done by a specific person, in a specific place, at a specific frequency, for a specific reason. It has a name that the customer already uses. It has a person doing it today whose hours you can count. It has a cost you can measure and a pain you can hear described without prompting.

The difference is not semantic, it is the entire difference between a company that ships and one that does not, and here is why. Every design decision in a robot has to be made against something. Form factor, degrees of freedom, sensing, reach, payload, speed, duty cycle, safety category. If you have chosen a market, none of those decisions has a determinant, so they get made on aesthetics or on what the team already knows how to build. If you have chosen a job, every one of those decisions has an answer, and the answers are discoverable by going and watching.

Going and watching is the underrated activity of this entire field. Not interviewing. Watching. Standing in the building, at the hour the work is done, for long enough to be bored. I have never seen a founder spend a hundred hours doing that and come away with the same product concept they went in with, and the change is always toward something narrower and more achievable.

What you learn by watching is the stuff nobody tells you in an interview, because it is too obvious to mention. That the operator does the task in a slightly different order than the written procedure. That there is a step where they look at something and decide, and that step is the actual hard part. That the reason the job is unpleasant is not the lifting but the cold, or the noise, or the fact that it happens at four in the morning. That the bin is never as full as the specification says. That there is one item type, six percent of volume, that behaves completely differently from everything else and will break your machine.

That last category is the one that ends pilots. Every real workflow has an exception distribution with a long tail, and the tail is invisible from a conference room. A machine that handles ninety four percent of items and jams on the rest has not automated the job. It has created a new job, which is standing next to the robot waiting for it to jam, and that job costs the customer more than the one you replaced.

So the discipline is to find the job, watch it until you know its exception distribution, and then design the narrowest machine that handles enough of the distribution that the residual can be handled by an existing exception process rather than a new one.

I will put it as a rule. If you cannot describe your customer's job in one sentence using their vocabulary, including the frequency and the exception rate, you are not ready to design the machine. And if you find yourself saying your machine can do many jobs, ask yourself whether you have chosen any of them.

Chapter 23The only number the buyer actually cares about

I have sat on both sides of this conversation for a long time, and I can tell you that when a robotics company presents to an industrial buyer, most of what gets presented is not what the buyer is evaluating.

The buyer is doing one calculation. What does this cost me all in, what does it save me per period, and how long until I am ahead. Payback period. Everything else is either an input to that calculation or a risk factor that might invalidate it.

The reason payback dominates is institutional rather than intellectual. Capital approval processes are usually tiered by payback period, and below some threshold a plant manager can approve locally while above it the request goes to a committee that meets quarterly and requires a business case. So the difference between a payback that clears the local threshold and one that does not is not a small difference in attractiveness. It is the difference between a decision made by the person who wants your machine and a decision made by people who have never met you.

Which means shortening payback is not a pricing tactic. It is a change to who decides.

Now, the part robotics companies get wrong. They calculate payback using the labour hours displaced and their own machine price, and they leave out the customer's costs, which the customer will not leave out.

The customer's true cost includes your machine, plus installation, plus any facility modification, plus integration with their existing systems, plus training, plus the service contract, plus the spare parts holding, plus the internal staff time to manage the programme, plus the cost of the exceptions your machine does not handle, plus the productivity lost during the transition. A robotics company that presents a payback based only on machine price against labour saved is presenting a number the customer's finance team will rebuild and find to be roughly half as good.

Present the rebuilt number yourself. It is one of the highest trust building moves available, and it costs you nothing but the discomfort of honesty. I would rather show a buyer a defensible payback with every cost in it than a flattering one they will dismantle in the meeting after mine.

The other adjustment worth making is on the savings side, because labour displacement is often not the largest benefit and is almost always the most politically difficult one to talk about. In a lot of the workflows I have looked at, the machine's real value shows up as throughput, or as consistency, or as reduced damage, or as the ability to run a third shift that was never staffable, or as a safety incident rate that affects insurance and regulatory standing. Those are frequently larger than the wage line and they are much easier for your champion to advocate for internally, because nobody has to be let go for the business case to work.

There is a further point which I think matters and which I hold on principle rather than as a tactic. The jobs where these machines have the clearest case are overwhelmingly the ones people do not want. Repetitive lifting that destroys backs. Cold rooms. Confined spaces. Night shifts. Work with a genuine injury rate. If your machine is taking that work, say so directly and without embarrassment, because it is true and it is the strongest version of the case.

Chapter 24Robots as a service, and when it is honest

Every robotics company eventually considers selling the machine's output rather than the machine. Per pick, per hour, per unit processed, per month. It is a genuinely powerful model and it is also, sometimes, a way of hiding a problem, so it is worth separating the two cases carefully.

The honest case for it is strong. It converts the customer's capital expenditure into an operating expense, which moves the decision out of a slow capital process into a faster operating budget and removes the payback conversation entirely. It aligns incentives, because if you are paid for output you are paid for uptime, which means you carry the reliability risk rather than the customer, which is where that risk belongs since you are the only party who can reduce it. It gives the customer a way to try the machine without committing to an asset they do not know how to value. And it gives you a recurring revenue relationship, which improves the business in every way recurring revenue improves any business.

Those are real and I would encourage most robotics companies to at least offer it.

The dishonest case is when the model is being used to conceal unit economics that do not work. If your machine costs more to build and service than the output stream will ever recover, then selling output rather than the machine does not fix that. It converts a customer objection into a balance sheet problem and defers the reckoning by the length of the contract. Meanwhile every unit deployed consumes capital, and growth makes the hole deeper rather than shallower, which is the specific trap that makes this failure mode so dangerous. The company looks like it is scaling right up until it cannot fund the next batch.

So the diagnostic I would apply, and would want applied to me, is straightforward. Take one machine. Sum everything it costs you to build, deliver, install, support, service and eventually refurbish or retire over its expected life. Sum everything it will earn you over that life at the contracted rate and the realistic utilisation, not the utilisation in the proposal. Compare. If the second number does not comfortably exceed the first, the service model is not a business model, it is a financing structure for a loss.

The utilisation assumption is where these models most often break, and it is worth being paranoid about it. Machines get idled for reasons that have nothing to do with the machine. The customer's volume is seasonal. A process upstream changes. The champion who bought it moves to another company and their successor has different priorities. The building gets reorganised. If your economics require high utilisation, you are exposed to a lot of events you do not control, and the contract should reflect that with a minimum commitment rather than pure usage pricing.

There is one more variant worth naming because it is common and mostly a mistake, which is the pilot priced at or below cost in the hope of a rollout. I understand why people do it. The problem is that a free pilot is evaluated as a free pilot. It gets a low priority champion, it gets deprioritised the moment something urgent happens, and it teaches the customer that the machine's value is roughly what they paid. Charge for the pilot. Charge enough that somebody in the building has to justify it, because that person then becomes invested in its success, and an invested champion is worth more than the entire fee.

Chapter 25Integration is the product

There is a hard truth in industrial automation that has been true for forty years and that every generation of robotics founders has to learn the expensive way. The machine is a minority of the work.

In traditional automation, integration frequently costs as much as or more than the hardware. Somebody has to design the cell, specify the guarding, build the fixtures, write the interlocks, connect to the control system, connect to the software that schedules the work, define the exception handling, commission it, and train the people. That work is skilled, slow, site specific, and it is the reason automation has historically been available only to operations large enough to justify it.

Modern robotics reduces some of this and does not eliminate it. A machine that can perceive and adapt needs less fixturing, which is a genuine and large saving. It still needs to know what work to do, report what it did, hand off to the next step, and behave correctly when something unexpected happens.

That last part is where I see the most underestimation. Exception handling is not an edge case, it is a substantial share of the total engineering, and it is the part that determines whether the deployment feels good or bad to the people who work alongside it. What happens when an item is unidentifiable. When a container is in the wrong place. When the network drops. When a person walks into the space. When the machine has done half a task and lost confidence. Each of those needs a defined behaviour, and the defined behaviour has to be intelligible to the operator, because an operator who cannot predict what the machine will do will not work near it comfortably.

The strategic question is what to do about all this, and there are only three answers.

You can do the integration yourself, which gives you control and quality and makes you a services business with a hardware component, which caps your growth at your ability to hire people who can do it. You can build a partner channel of existing integrators, who already have the customer relationships and the field skills, which scales far better and costs you margin and some control over the customer experience. Or you can engineer the integration requirement down until the machine can be installed by the customer, which is the hardest path, the slowest, and the only one that produces a business that scales without a proportional increase in headcount.

Most successful companies in this space do all three in sequence. Self perform early, because you have to learn what integration actually requires and you cannot learn that from a partner's report. Partner in the middle, to grow faster than you can hire. Engineer it down continuously, and measure your progress with one number, which is engineering hours per deployment. If that number is not falling deployment over deployment, you do not have a product yet, you have a project business.

I would make that the single metric a robotics company reports internally every month. Engineering hours per deployment, trending. It captures more about the health of the business than revenue does at this stage, because revenue can be bought with heroics and that number cannot.

Chapter 26Service is the business

I want to give service its own chapter because in my experience it is the part that founders think about last and that determines the outcome most.

Here is the sequence that plays out. Company ships machines. Machines break, because machines break. The customer calls. The company sends an engineer, because there is no service organisation yet and the engineer knows the machine. The engineer flies, diagnoses, fixes, flies back. This is expensive but survivable at five machines.

At fifty machines, it is not survivable, and the transition is brutal because it arrives quickly. Service cost scales with fleet size while your service capability scales with hiring, and hiring field service technicians who can work on a novel machine takes longer than you think because the training material does not exist yet.

The companies that get through this build the service model before they need it, and it has five parts.

Remote diagnosis, which requires the observability I argued for earlier. If your first action on a fault is to look at the machine's own telemetry and know what happened before anyone travels, you have changed the economics of the whole operation. A meaningful share of faults can be resolved remotely or by talking a customer technician through a fix, and every one of those is a trip you did not take.

Modular replacement. Design so that the common failures are addressed by swapping a module rather than repairing in place. This turns a skilled repair into an unskilled swap, which means the customer's own maintenance person can do it, which collapses your response time and your cost simultaneously.

Spares logistics. Boring, decisive. The right parts in the right places before the failure, which requires knowing your failure distribution, which requires the telemetry again.

Training material that lets a customer's technician become competent. Written, filmed, tested on somebody who did not build the machine. Most companies produce documentation that is only intelligible to its authors and then conclude that customers cannot service the product.

And a preventive schedule based on measured wear rather than guessed intervals, so that wear items are replaced during planned downtime rather than during production.

None of this is inventive work and all of it is the difference between a company that can be at a thousand machines and one that cannot. When I look at a robotics company now, I spend more time on the service plan than on the technology, because I have never seen a company fail from having a slightly less capable machine and I have watched several struggle badly from having no answer to the third breakdown.

Chapter 27The four people in the room

Selling a robot into an operating business is not one sale, it is four, and they happen in a fixed order whether you manage them or not. Almost every stalled deal I have looked at was stalled because one of the four was never addressed.

The first person is the operator. The person who will work next to the machine, or whose task it changes. Their concerns are not the ones you expect. They are rarely about their job, at least not first. They are about whether the machine is predictable, whether it will make their day harder, whether they will be blamed when it stops, and whether anyone asked them. An operator who is against your machine can defeat it quietly and completely, by using it in a way that generates faults, or simply by not using it. An operator who is for it will nurse it through its bad weeks. This is the cheapest constituency to win and the most commonly ignored.

The second is the operations manager. This is usually your champion, and their concern is availability and predictability of the daily plan. They do not care about your technology and it is a mistake to spend their time on it. They care whether they can staff a shift assuming the machine runs, and what the plan is when it does not. Answer that question concretely, with numbers and a documented recovery path, and you will have an advocate who will carry the deal internally.

The third is engineering or maintenance. Their concern is what happens to them. Who fixes this, what training do we need, what spares must we hold, what does it connect to, and does it become another thing on my list. This group can veto and often does, quietly, by raising enough questions to run out the budget cycle. They are won by being taken seriously and by being given real documentation early, and they become extremely useful allies because they are the ones who know what the building is actually like.

The fourth is finance or procurement. Their concern is the number and the contract. Payback, total cost of ownership, terms, liability, what happens on failure, and whether the vendor will still exist in three years. That last one is real and you should have an answer to it rather than being offended by it. This group is the one your presentation is usually built for and it is the last one to matter, because they will not approve something nobody in operations wants and they will approve almost anything operations insists on if the number works.

There is a fifth party who is not always in the room and can stop everything, which is the safety and insurance function. I covered them in the safety chapter and I will repeat the practical point here, because it belongs in this list. Find them in the first month, not the last.

The sequencing implication is what I would take from this. Most robotics companies work this list backwards, starting with an executive presentation about the technology and the market, and arriving at the operator last if at all. The order that works is the reverse. Win the operator by being present and asking. Win the operations manager with availability and a recovery plan. Win maintenance with documentation and modularity. Then let them carry you to finance with a payback you built honestly.

That is not a sales technique. It is what happens when you have built the six conditions from the start of this part, because each of the four people is essentially auditing one of them.

Chapter 28Manufacturing is a second company

A robotics company that reaches volume discovers that it has founded a second company inside the first one, with a different culture, different metrics and different people, and that the second company is now the constraint.

Building ten machines is a workshop activity. You can hand fit. You can select components. You can have the person who designed it assemble it. Building a thousand requires design for manufacture, supply chain management, incoming inspection, process control, test fixtures, yield tracking and a factory.

The transitions that catch people out are specific and predictable.

Tolerance stack up. In a prototype, a technician adjusts things until they fit. In production, every part arrives at some point within its tolerance band, and the accumulation across an assembly produces variation the design never accounted for. This shows up as a percentage of units that fail final test for no single identifiable reason, and fixing it means going back into the design to make it insensitive to variation, which is expensive after the fact and nearly free before.

Component availability. The elegant part you selected has a long lead time, or a minimum order quantity you cannot meet, or a manufacturer who end of lifes it. Every design carries supply risk and the good teams carry a second source for anything critical, having qualified it rather than merely identified it.

Test. You cannot ship what you have not tested, and testing a robot is not trivial. It needs a fixture, a defined procedure, pass criteria and a record. Building good production test infrastructure is a real project that produces no visible product feature, and skipping it means your customers become your test department.

Calibration. Every machine needs its own calibration, stored, versioned and recoverable after a service event. Teams that treat calibration as something a technician does discover that they cannot support a fleet.

Revision control on hardware. Once units are in the field you have multiple hardware revisions running simultaneously, and your software has to handle all of them, and your service documentation has to match each one. This is a discipline problem more than an engineering problem and it goes badly when it goes badly.

I raise all of this not to be discouraging but because the timing matters. Nearly every one of these is cheap to address in design and expensive to address in production. The teams that do well are the ones who bring manufacturing expertise in earlier than seems justified, usually one full generation before they think they need it. The teams that struggle hire it after the first production run fails.

There is a corollary about the founding team. A robotics company needs somebody senior whose instinct is manufacturability, and that person needs enough authority to say no to a design that is clever and unbuildable. If the entire founding team's background is research, that voice does not exist, and its absence will not be visible until it is expensive.

Chapter 29Safety, standards, and the surface you have to know

Safety in robotics is not a compliance formality bolted on at the end. It is a design input that determines architecture, and getting it wrong late is one of the more expensive mistakes available.

The core concept is the risk assessment. You enumerate the hazards a machine presents, evaluate severity, frequency of exposure and the possibility of avoidance, and then design measures that reduce risk to an acceptable level. This is a formal process with established methodology behind it, and the important thing to understand is that it drives the design rather than documenting it. What safety category a function needs determines whether it can be implemented in ordinary software, or needs a rated safety controller, or needs redundant channels with cross checking, or needs to be hardwired.

For industrial robots there is a well established international standard framework covering the robot and its integration, and a companion technical specification specifically addressing collaborative operation, meaning a robot and a person sharing a space without a fence. That collaborative document is the one worth understanding in detail if your machine works near people, because it defines the actual methods by which such operation can be made acceptable. Safety rated monitored stop, where the machine halts when a person enters. Hand guiding. Speed and separation monitoring, where the machine slows as a person approaches and stops within a defined distance. And power and force limiting, where the machine is designed such that any contact it can make stays below documented thresholds.

Those four methods are not interchangeable and choosing among them is a design decision with large consequences. Power and force limiting, in particular, constrains your actuator authority and therefore your payload and speed, which constrains what jobs you can do. A team that chooses this route late finds that its machine is too strong for the safety case it needs, and that is not a software fix.

Mobile machines bring their own considerations around navigation safety, detection of people, and what happens when the machine is in a space with vehicles. Machines in food, medical or public settings pick up further regimes entirely.

Two practical points from watching people get this wrong.

The first is that the certification and assessment work takes calendar time you cannot compress with money, and it sits directly on your critical path to revenue. Start earlier than feels necessary. I have seen a machine sit finished in a room for months while paperwork resolved, and the company burned runway at full rate the entire time.

The second is that the customer has their own safety organisation with its own standards, its own insurers and its own veto, and satisfying the international standard does not automatically satisfy them. Meet that team early. Ask what they will require. They are not an obstacle to route around, they are the group that can approve you into the building, and a vendor who arrives with a completed risk assessment and a considered answer is treated very differently from one who arrives with a video.

Part 05The machine economy

Chapter 30A machine cannot open a bank account

I want to change register for this part, because I am going to connect robotics to the other thing I have spent fifteen years on, and the connection is not decorative. It is the piece that turns a robot from a line on a balance sheet into an economic participant, and I think it is the least understood part of this whole convergence.

Start with a plain observation. A robot cannot open a bank account.

It sounds trivial and it is structural. The financial system is built entirely around identified legal persons. Every account has a beneficial owner, an identity verification file, a jurisdiction and a human or corporate entity responsible for it. That architecture is not an accident and I am not criticising it. It exists for reasons and it does what it was designed to do.

But it means that when a machine needs to pay for something, it cannot. What actually happens is that a company holds an account, and the machine's consumption gets aggregated into an invoice, which gets approved by a person, and paid on a monthly cycle, and reconciled by a finance team. The machine is not transacting. A company is transacting on the machine's behalf, in batches, slowly, with human approval in the loop.

For most of industrial history that has been completely fine, because machines did not consume services. A lathe does not buy anything. It sits on a balance sheet, depreciates, and consumes electricity and maintenance, both of which are purchased by humans on a schedule.

That is changing for a specific technical reason, which is that autonomous machines increasingly do consume services, continuously, in small amounts, from multiple providers. A machine that uses a remote model for a perception task it cannot run locally is buying inference. A machine that pulls a map update, or a fresh policy, or a weather service, or a localisation correction stream is buying data. A machine that offloads a planning computation is buying compute. A machine that hands a task to another machine is buying labour.

Each of those is small, frequent, and would ideally be settled at the moment of use rather than aggregated into a monthly bill. And the entity that knows when the service was worth buying is the machine, not the finance department.

So there is a mismatch between how the machine wants to transact, which is often, in tiny amounts, without a human, across organisational boundaries, and how the financial system is built to transact, which is in batches, in meaningful amounts, with identified humans, mostly inside jurisdictions.

The gap has been closed so far by simply not doing it. Services get bundled into subscriptions, capabilities get run locally even when remote would be better, and inter company machine interaction barely exists because there is no way to settle it. That is a constraint that shapes architecture, and most people working in robotics do not notice it because they have never known anything else.

I notice it because I spent fifteen years in the industry that built the alternative.

Chapter 31The properties a machine actually needs from money

Let me approach this the way I would approach any engineering requirement, which is to write the specification before naming the solution.

What does a payment system need to look like for a machine to use it directly?

It needs to be permissionless in the narrow sense that a new participant does not require an approval process to hold and transfer value. A fleet that has to onboard each machine through an institutional process is back to a human in the loop, and worse, back to a counterparty who can decline.

It needs final settlement. When a machine pays for an inference call, both sides need to know the payment is done, not pending, not reversible in ninety days. Reversibility is a feature designed around human error and human fraud, and it is a serious problem for an autonomous counterparty who has already delivered the service and cannot pursue a dispute.

It needs to be native to software. Meaning a machine can hold and use it with code alone, without a legal identity, a branch visit, or a credential issued by an institution to a person.

It needs to work across borders identically, because a robot in one country routinely wants a service hosted in another, and the current arrangement for that is slow and expensive and involves correspondent banking relationships that no machine can navigate.

It needs to support very small amounts economically, because per inference and per request pricing implies transaction sizes far below what card networks or bank transfers can carry without the fee dominating.

It needs to be programmable, so that conditions can be attached. Pay on delivery of a verified result. Escrow until a task completes. Release on a signature from two of three parties. These are the primitives of any commercial relationship and a machine needs them expressible in code.

And it needs a supply that is not set by a committee, because if machines are going to hold operating balances and price services among themselves over long periods, an issuance schedule that changes politically injects a variable nobody in the system can model or hedge.

Write that specification down without naming anything and then ask what satisfies it. Permissionless participation, final settlement, native to software, borderless, small denominations, programmable, fixed and independently verifiable supply.

The honest answer is that bitcoin was designed against something very close to that specification, and that it is the only monetary system I know of that has all of those properties simultaneously and has been running continuously for long enough to be treated as infrastructure rather than as an experiment.

I hold this position strongly and I want to be clear about what I am and am not claiming. I am not telling you to buy anything and this book has no financial recommendation in it anywhere. I am making a systems argument. The properties a machine needs from money are unusual, they were not the design target of the existing financial system, and there is a monetary network that happens to have them.

That is the machine economy thesis, stated as an engineer would state it. Bitcoin fixes the incentives, meaning it provides a settlement layer that does not require anyone's permission. AI amplifies capacity, meaning the marginal cost of a decision collapses. Robotics provides the body, meaning that capacity reaches the physical world. Three layers, one system.

Chapter 32What machine to machine settlement actually looks like

I want to be concrete rather than visionary here, because this topic attracts a lot of hand waving and the mechanism is not complicated.

Consider a machine that needs a perception capability it cannot run locally. Perhaps it encounters an object class it does not recognise and wants a larger model's opinion. Today, that call goes to an endpoint the company has a contract with, authenticated by a key that was issued to the company, and billed monthly.

Now consider the alternative arrangement. The machine holds its own balance and its own key. It queries a service, receives a price, decides whether the answer is worth that price given what the decision is worth to the task, pays, and receives the result. The settlement happens in the same interaction as the service.

What changes when you do it that way?

The first change is that the machine can use providers its owner never contracted with. That is a genuine unlock. It converts a closed set of pre negotiated relationships into an open market where a machine can discover and use a capability at the moment it needs it. The company does not have to anticipate every service its fleet might want.

The second change is that pricing becomes granular and competitive at the point of use rather than annual and negotiated. Services that are worth a fraction of a cent per call can exist, which they currently cannot, because the overhead of establishing a billing relationship exceeds the value of the transaction.

The third change is that a machine can be paid as well as pay. This is the part I find most interesting. A machine that has spare sensing capacity, or spare compute, or spare time on a route, or data another party wants, has something to sell, and no way to sell it. Give it an account and it does.

The fourth change is that inter company machine interaction becomes possible. A delivery machine handing a package to a building's internal machine is currently a contractual and reconciliation problem large enough that nobody does it. As a settled transaction at the point of handoff, it is a much smaller problem.

I want to be careful about the state of this. Payment channel technology that makes very small, very fast bitcoin denominated payments practical exists and has been running for years. Cryptographic primitives for conditional and multi party release exist and are well understood. The engineering to give a machine a key, a balance and a spending policy is not research, it is implementation.

What does not yet exist at any meaningful scale is the surrounding market structure. Discovery, meaning how a machine finds a service. Reputation, meaning how it decides which provider to trust. Dispute handling, when a paid service returns garbage. Key management for a fleet, which is a serious operational problem, because a machine holding value is a machine worth stealing and a machine whose key is compromised is a spending problem. Spending controls, so a malfunctioning machine cannot drain a balance. And the accounting and tax treatment, which is a genuine and unglamorous obstacle in every jurisdiction.

Those are all real gaps. Whether and how they get filled is an open question and I am not going to forecast it. What I will say is that the gaps are in market structure and operations, which is the category of problem that gets solved by people building businesses, rather than in the underlying settlement technology, which works.

Chapter 33From cost centre to earner

Here is the conceptual shift I think matters most, and it is the reason I keep the payments thesis and the robotics thesis together rather than treating them as separate interests.

A machine that can only spend money its owner authorises in advance is capital equipment. It sits on the balance sheet, it depreciates, it consumes maintenance, and its entire contribution to the business is the cost it removes. That is a perfectly good thing to be and most industrial equipment is exactly that.

A machine that can transact on its own is a different economic object. It can buy capabilities at the moment they are worth buying, which means its behaviour can be optimised against actual value rather than against a pre purchased allowance. It can sell what it has spare. It can be metered precisely enough that its output is priced per unit rather than amortised. And it can participate in arrangements with parties its owner has no relationship with.

I described this on my site before I ran anything in this sector, and I would put it the same way now. A robot that can pay for its own services and get paid for its work is a different economic object than one that just sits on a balance sheet as capital expenditure.

The practical consequence for a founder is about business model optionality rather than about ideology. If your machine can be metered and settled precisely, you can price its output rather than its purchase, which reopens the whole conversation from part four about capital approval and payback. You can offer arrangements that were not previously administrable. You can let a customer pay for exactly what they used with no reconciliation overhead on either side.

And there is a second order effect worth thinking about, which is what happens to fleet utilisation when machines can transact across ownership boundaries. Today a machine idle in one company's building cannot do work for the company next door, because there is no mechanism to arrange, meter and settle it that costs less than the work is worth. Remove that friction and idle capacity becomes tradeable. Whether that develops into anything, and on what timescale, is genuinely open. I raise it because it is the kind of structural change that is invisible until it happens and obvious afterwards.

I will add one caution, in keeping with the tone of the rest of this book. None of this makes a bad machine good. If the payback does not work, if the availability is not there, if the service model is missing, no settlement layer rescues it. The machine economy is a capability that improves good machines. It is not an alternative to building one.

Chapter 34The honest ledger of what exists and what does not

I want to close this part with a clean separation, because I have just spent several thousand words on a thesis and I would rather you were able to check it than believe it.

What exists and is running today, verifiably.

A settlement network with a fixed and independently verifiable supply that has been operating continuously for well over a decade and that anybody can validate for themselves with ordinary hardware. Payment channel technology enabling very small, fast, low fee payments on top of it. Cryptographic tooling for multi party and conditional release. Machine readable interfaces to all of it. The ability for a piece of software with no legal identity to hold, receive and send value. Priced per call access to remote models and services, already the dominant commercial model for machine intelligence. And machines in the field that already consume remote services continuously during operation.

Every item on that list is checkable today. None of it is a projection.

What does not exist at meaningful scale, and is therefore an open question rather than a plan.

A discovery mechanism by which machines find services they were not configured to use. Reputation systems suited to autonomous counterparties. Fleet scale key management and spending controls that an operations team would actually accept. Accounting and audit treatment that a company's finance function is comfortable with. Regulatory clarity for autonomous spending in most jurisdictions. And any substantial volume of genuine machine to machine commerce across organisational boundaries.

I am not going to tell you which of those will be solved, by whom, or when. I do not know, and the people who claim to know are guessing with more confidence than I am willing to borrow.

What I will say is that the shape of the remaining work is knowable, and that it is mostly operational and commercial rather than fundamental. That is a meaningfully different situation from a thesis that requires a scientific breakthrough. It is closer to the position early internet commerce was in once the protocols worked and what remained was payments, trust and logistics.

That is where I would leave it. Not as a prediction. As a description of what is built, what is not, and what would have to happen next.

Part 06Building it

Chapter 35What I look for, after several hundred conversations

I host a show where I interview founders, and I have now recorded well over four hundred episodes. A meaningful share of them are people building hardware, and among those a substantial number are building robots or the components and software that go into robots. Warehouse automation. Robot vision. Modular hardware platforms meant to cut development time for everyone else. Factory deployment. Companion machines. Agricultural systems. Automation of home care. Rail. Inspection. Machines meant to work in places people should not have to be.

I do not name guests and I do not discuss anyone's specifics, so what follows is a pattern summary rather than a set of stories. But four hundred conversations is enough data to see patterns, and the patterns are consistent enough that I now use them as a filter.

The first pattern is that the founders who ship have almost always done the job themselves, or watched it obsessively. Not researched it. Done it, or stood next to it for a hundred hours. There is a distinctive way these people talk. They use the customer's vocabulary without translating. They know the exception rate. They know what time of day the hard part happens and why. When I ask what breaks, they answer immediately and specifically, because they have seen it break. The founders who worry me describe the market from above, in categories, and get vague exactly where the physical detail should be.

The second pattern is subtraction. The ones who ship arrived at their machine by removing things. They will tell you, usually with some embarrassment, about the version that had two more axes, or a second arm, or a mobile base, and how they took it out. That embarrassment is the signal. It means the design was tested against reality and reality won an argument. The ones who worry me have added things over time and can explain why each is necessary in principle.

The third pattern is that the good ones talk about service, spares and installation unprompted. They bring it up. It occupies real space in their thinking, often more than capability does, and they can tell you their engineering hours per deployment and whether it is falling. When I have to introduce the topic and it lands as a new consideration, that tells me the company is still in the demo phase regardless of what stage its funding says.

The fourth pattern, and this one surprised me, is that the strongest technical founders are usually the most willing to name what is unsolved. There is an inverse relationship between engineering depth and confident forecasting that I now find almost perfectly reliable. The people who genuinely understand the actuator, the tactile problem and the reliability chain will tell you plainly which parts are open. The people who say everything is essentially solved and it is now a scaling problem have generally not met the parts that are not.

The fifth pattern is about the previous life. Robotics attracts brilliant researchers, and research is genuinely necessary here. But a company that is entirely research minded builds toward capability rather than toward deployment, and capability has no natural stopping point. The companies that ship almost always have somebody senior whose formation was in production, or field service, or manufacturing, and who has enough standing to stop a design.

I would add one more thing that is not a pattern so much as a preference. I bias hard toward people doing real work over people performing it. That has been true of me for a long time and this sector tests it constantly, because robotics produces unusually good video and video is unusually persuasive. The correction I apply is simple. Ask what is running today, in a building the founder does not control, that nobody from the company is present for. The answer to that question is the company.

Chapter 36The team you actually need

Robotics companies fail from missing disciplines more often than from missing talent, and the missing disciplines are predictable.

You need controls. Somebody who genuinely understands feedback, stability, filtering and estimation, and who can look at an oscillation and know whether it is mechanical resonance, an aliasing artefact, a gain that is too high, or latency in the loop. This person is your defence against a whole category of problem that is otherwise diagnosed by trial and error over weeks. Controls people are less fashionable than they were and they are the reason your machine is smooth instead of twitchy.

You need mechanical design with manufacturing instincts. Not a designer who can produce a beautiful assembly, though that helps, but somebody whose reflex when they see a clever mechanism is to ask how it will be assembled, tolerance, serviced and sourced. This is the voice that saves you a year later.

You need electronics and firmware. Power distribution, motor drives, sensor interfaces, real time behaviour, electromagnetic compatibility, and the discipline to build the diagnostic and telemetry infrastructure that everything else in this book depends on.

You need perception and learning, which is the discipline the industry currently has the most of and which is genuinely essential. My only note is that this function should be structurally connected to the hardware rather than sitting apart from it, because a perception team that never touches the machine will build against an idealised sensor and will be surprised in the field.

You need software that is not the algorithms. The state machine, the exception handling, the fleet management, the update mechanism, the logging, the operator interface. This is a large amount of work, it is what the customer actually experiences day to day, and it is chronically understaffed in robotics companies because it is not the exciting part.

You need field and applications engineering, which is the function that goes to sites, installs, commissions, trains and diagnoses. In an early company this is often a founder, and that is correct for a while, but it has to become a real function with real process before you reach the scale where the founder cannot fly any more.

And you need somebody who owns the customer's job rather than the machine. Somebody whose entire orientation is what the customer is trying to accomplish, who spends time in their buildings, and who can tell the engineering team that a feature they love does not matter and a workflow detail they find trivial is the deal.

That is a broad team, which is one of the honest costs of hardware, and it means a robotics company is bigger earlier than a software company doing comparable revenue. Anybody funding or joining one should understand that structurally rather than treating it as inefficiency.

I would flag two hiring traps. The first is hiring entirely from research backgrounds because they interview impressively, and finding you have no one who has shipped anything. The second is hiring an entire specialised team for a phase you have not reached, most commonly building a manufacturing organisation before the design is stable, which burns money and produces frustration on both sides. The sequencing matters, and the sequencing is roughly controls and mechanical first, then electronics and the unexciting software, then field engineering, then manufacturing, with perception distributed throughout rather than concentrated in a phase.

Chapter 37Capital, and the shape of a hardware company

I am not going to talk about funding markets, valuations or returns, and this book contains no investment guidance of any kind. What I will do is describe the operational shape of a robotics company's capital needs, because it differs from software in ways that catch founders out, and the difference is a matter of physics and calendars rather than of finance.

The first difference is that iterations have a physical cycle time. A software team can try something today. A hardware team's cycle is bounded by fabrication, shipping, assembly and test. Even a fast team measures a meaningful design revision in weeks, and a change to a custom part with tooling in months. That means the same amount of learning takes longer and therefore costs more in burn, and it means the value of getting a decision right the first time is far higher than it is in software. It also means that anything you can move into simulation or into a modular test rig, so that it can be iterated at software speed, is worth a great deal.

The second difference is that inventory and components consume cash before revenue. You buy parts, you hold them, you build machines, you ship them, and depending on your commercial model you may then wait to be paid, or worse, be paid over the life of a contract. Growth in a hardware business consumes cash rather than generating it, which is the exact inverse of the software intuition, and it means that a period of rapid order growth can be the most dangerous moment the company has.

The third difference is that milestones are physical and therefore legible, which is actually an advantage if you use it. A working machine is a working machine. A machine running unattended at a customer site for ninety days is an unambiguous fact. The discipline is to define the milestones in terms of those facts rather than in terms of capability demonstrations, and to sequence them so that each one retires the largest remaining risk rather than the most interesting one.

That last point is the one I would emphasise most. Every young robotics company has a list of risks, and they are not equal. There is usually one that, if it fails, ends everything, and it is frequently not the technical risk the team is most engaged by. It might be whether the customer's exception rate is tolerable. It might be whether the safety category you need is compatible with the actuators you chose. It might be whether anyone will pay the price your bill of materials requires. Those risks are cheap to test early and catastrophic to discover late, and the natural tendency of every engineering team is to work on the interesting risk first.

So the operating principle I would hold is to spend the earliest and cheapest possible experiment on the largest risk, even when the experiment is unsatisfying. A week in a customer's building counting exceptions retires more risk than a month of engineering, and it costs almost nothing.

Chapter 38The first ninety days

If I were starting a robotics company on Monday, or advising someone who was, here is the sequence I would run. It assumes nothing except that you can build things and that you have a domain you find interesting.

Days one to thirty are for finding the job. Not the market. The job. In this month you should not design anything, and the temptation to design will be strong, because designing is what you know how to do and it feels like progress.

Spend the month in buildings. Get into as many facilities as will have you, in whatever domain you are drawn to, and watch work being done. Ask to shadow a shift. Offer to do the job yourself for a day, which is the single highest information activity available and which almost nobody does. Count things. How many items per hour, how many exceptions, what fraction of the time is the person actually doing the task versus walking, waiting or fixing something. Note the physical parameters. Mass, dimensions, reach, height, surface, lighting, temperature, floor condition, aisle width.

By the end of the month you should be able to state the job in one sentence in the customer's vocabulary, and to state its exception distribution. If you cannot, you are not done, and no amount of designing will fix a job you have not characterised.

Days thirty one to sixty are for the cheapest possible test of the biggest risk. Write down every reason this could fail, order them by how fatal they are, and attack the top one with the smallest experiment that produces a real answer.

Often the top risk is not technical. If your machine's viability depends on the customer accepting a payback of a certain length, you can test that in conversations this month, with a bill of materials estimate on a page. If it depends on handling an exception class you saw in month one, you can test that with a rig on a bench, not a robot. If it depends on being allowed to operate near people, you can test that by asking a customer's safety organisation what they would require, which is a phone call.

Do the ugly test. This month is not about impressing anyone.

Days sixty one to ninety are for the first machine that does the job badly. Not well. Badly, but end to end, on real inputs, in a real place if you can get one.

The point of an end to end machine that does the job badly is that it tells you the truth about where the difficulty actually is, which is never where you thought. Teams that build subsystems to a high standard before integrating spend their first year perfecting the wrong subsystem. Teams that integrate something terrible immediately find out in week two that the hard part is the container being slightly crushed, or the lighting at that end of the building, or that the item arrives in a different orientation than anyone said.

Then, and this is the part that matters, get it in front of the customer while it is still bad. Founders resist this because it is embarrassing. It is the most valuable thing you can do, because the customer's reaction to a bad machine doing their real job is worth more than any amount of their reaction to a good machine doing a fake one. They will tell you what they actually care about, and it will not be what they told you in the first meeting.

At the end of ninety days you should have a job stated precisely, the largest risk tested honestly, a working end to end embarrassment, and a customer who has seen it and told you the truth. That is a far better position than most companies are in after a year, and it costs almost nothing but discipline.

Chapter 39The weekly loop for a hardware team

Software teams have well developed rhythms. Hardware teams often do not, and the ones that invent a good one move noticeably faster than the ones that do not. Here is the loop I would run, and it fits in a week.

Start the week by looking at the fleet, however small the fleet is. Even at two machines, spend the first hour of Monday on what the machines did last week. Faults, near faults, cycle counts, current draw trends, thermal behaviour, position error, anything that moved. This one habit produces more useful engineering direction than any planning meeting, because it is the only input that comes from reality rather than from the team's opinions.

Then pick the week's single largest source of downtime or failure and assign it as the week's principal work. Not the most interesting problem. The largest one, by measured impact. This sounds obvious and is surprisingly hard to sustain, because engineering teams gravitate toward problems that are tractable and interesting, and the largest problem is frequently neither.

Run a physical test every week, on hardware, on real inputs. Not simulation, not a subsystem bench, the whole machine doing the whole job, even if only for an hour. Any week without this is a week where the team's beliefs about the machine drift away from the machine.

Keep a running document of every field failure with a root cause, and review it monthly. The value is not the individual entries, it is the distribution. After twenty entries you can see where your reliability actually lives, and it is essentially never where the team expected. Half of them will be in a category nobody was working on.

Track two numbers publicly inside the company every week. Engineering hours per deployment, and availability across the fleet. Those two together describe whether you are building a product or performing a service, and whether the thing you built stays running. Almost everything else a young robotics company measures is downstream of them.

And end the week by writing down what you learned that contradicted something you believed on Monday. If nothing did, the week was spent executing rather than learning, which is fine occasionally and fatal as a pattern, because it usually means the team stopped touching reality.

That is the whole loop. It is not sophisticated. Its entire value is that it forces contact with the physical machine and the actual customer at a fixed frequency, and the failure mode of every robotics company I have watched struggle is that the interval between contacts with reality got longer and longer until the company was building against a memory.

Chapter 40The shelf

A short, opinionated list, because a resource list that contains everything is the same as no list.

For control, start with a proper undergraduate feedback control text and actually work the problems. Then a text on modern and optimal control, and then one on nonlinear control if your machine has significant nonlinearity, which if it has legs or contact it does. You do not need to derive everything, but you need to be able to read a frequency response plot and know what it is telling you, because that skill converts a week of mysterious oscillation into an afternoon.

For robotics specifically, the canonical texts on modelling, planning and control cover kinematics, dynamics, motion planning and manipulation, and one of them belongs on the desk of anybody making design decisions. Read the chapters on manipulability and on contact even if you skip others.

For estimation, a good treatment of state estimation and sensor fusion is worth more practical value per page than almost anything else on this list, because estimation is where the gap between what your sensors say and what is true gets closed, and most field weirdness lives there.

For mechanical work, get a machine design reference and a materials and manufacturing processes reference, and read the sections on tolerances, fits, fasteners and joining before you design anything you intend to build twice. Then find somebody who has run a production line and buy them lunch repeatedly.

For safety, read the actual standards. Not summaries. The international standard framework for industrial robots and their integration, and the technical specification covering collaborative operation. They are dry and they are the primary source, and reading primary sources in any regulated field is the difference between knowing what is required and knowing what somebody concluded about what is required. This is a habit I formed during years of regulatory fights in another industry and it has never once failed to pay.

For learning based control, the literature moves too fast for a book to be the right medium, so read the papers, and read them with a specific bias: prefer work that reports hardware results with failure analysis over work that reports simulation results with a success rate. The former is rarer and worth ten of the latter.

For the machine economy side, read the original bitcoin paper properly, three times, spaced out. It is nine pages, it is the primary source, and almost nobody with an opinion has actually read it. Then read a serious technical treatment of how the protocol works, and the specifications for the payment channel layer if you want to build anything that settles.

For tools, the highest return spend available to a young robotics team is measurement. An oscilloscope with current probes, a decent data acquisition setup, and the discipline to instrument before guessing. I have watched teams spend a month arguing about a behaviour that a two hour measurement would have settled. Instrumentation is not overhead. It is the fastest path to being right.

And a word on what is not on this shelf. There is no certification that a customer will care about. There is no framework or methodology that substitutes for having watched the job being done. The credential in this field is a machine that runs when you are not there, and there is no way to acquire it except by building one.

Chapter 41What to do Monday

I want to end without a summary, because summaries let people feel finished, and the failure mode of a book like this is a reader who enjoyed it.

Here is the honest position. Everything in these pages is either something I have done, something I watched closely enough to be confident about, or something I have heard described consistently enough across several hundred conversations with people building machines that I trust the pattern. None of it is complicated. The physics is the physics we have had for a long time. The commercial disciplines are the ones industrial equipment businesses have used for a century. The learning methods are new and genuinely powerful and they changed one layer of a four layer problem.

I have deliberately not told you what happens next in this sector, and I want to be clear that the omission is the point rather than caution. I do not know. Nobody does. The questions that decide it are empirical, they are checkable, and I have tried to name them precisely enough that you can watch for the answers yourself instead of waiting for someone to tell you. Whether one machine design can do many jobs without per job engineering. Whether service cost per unit falls across generations. Whether tactile sensing becomes a component instead of a research project. Whether the market structure around machine settlement gets built. Those are the things to watch. Everything else is noise with production values.

What I do know is what the work looks like. It looks like standing in a cold building at five in the morning counting how many times a person picks something up. It looks like a week spent on cable routing. It looks like a machine that does a job badly, in front of a customer, while you take notes. It looks like the third breakdown, and whether you have an answer for it.

So make Monday small and specific.

Do not design anything on Monday. Do not choose a form factor, do not pick actuators, do not write a specification. Those are all things you can do alone in a room, and things you can do alone in a room feel like progress and produce nothing.

On Monday, find one building where a physical job is done badly and get permission to stand in it. Then go, and watch, and count. Take the tape measure. Write down the exception rate.

That is the whole assignment. Everything else in this book is downstream of it.

If you are building at this convergence and you want a second opinion from somebody who has shipped hardware and watched a lot of companies attempt this, my calendar is open and the conversation is free. Bring the job, not the deck.