The first thing I learned on Tesla Autopilot was that the car got better every week and nobody touched the hardware. Same cameras, same computer. What changed was the data. Recordings from the fleet came back to us, the strange moments got labeled, the model retrained, and the next version drove a little better than the last. I was the third software engineer on Tesla's Autopilot AI team and the first to work on fleet learning: the systems that made that loop run. It is the most useful thing I know about how machines learn to work in the real world, and it is the reason I started Avala.
Avala is the infrastructure behind that loop for Physical AI teams: the system that helps a team decide what its model needs to learn next, develop the right physical-world data, and measure what changed. We turn raw sensor recordings into training data a model can learn from, and keep the dataset versions, the review history, and the results connected to the work. I started the company because other teams should not have to build that foundation from scratch.
Every fleet should learn from its own experience. Our ambition is to make that a dependable capability for the builders of autonomous machines. Here is how I see the industry, where we start, what we are optimizing for, and how that work can earn a much larger position.
This market is different in kind
Cars, computers, and phones extend what people can do. They put better tools in a person's hands. Autonomous machines can take the next step and perform the task.
That changes what the market is. The pool a robot addresses is not a product category. It is physical work: the cost of doing it, the output a machine can produce, and the useful hours it can operate. The scale of that opportunity explains why this industry matters. Avala's opportunity is the part customers will pay us to run: preparing useful data and making the next improvement cycle repeatable.
Two things make this different in kind and not just in size. A robot replaces work rather than assisting it. And a robot can help build the next robot. Once that loop closes, growth is no longer limited by how many people you can hire.
Take the boldest version seriously: a billion humanoid robots each doing the work of five people. That scenario implies five billion workers' worth of additional output. Both the number of robots and their productivity are assumptions, not observations. I don't think that arrives when the loudest voices say it will. I do think it arrives.
One honest note on the title. "Largest market in history" describes the pool of work these machines can do. It is not an estimate of Avala's addressable revenue. The market for the training data they learn from is much narrower. Everything that follows is about how a company can earn a place in that larger transition.
Where I think this goes
I hold three beliefs about this.
I expect autonomous machines to take on more physical work. The timing is much less clear. If you made me put numbers on it, I am around 70 percent confident the direction holds and compounds over the next three years, and maybe 25 percent that the most aggressive timelines do. Those are personal judgments, not measured probabilities.
The robots come slower than the headlines, and the reason is atoms. Omdia's January 2026 estimate puts 2025 humanoid shipments at about 13,000, including wheeled robots with humanoid upper bodies. On a smooth growth path, reaching a billion cumulative shipments by 2036 from that base would mean roughly tripling annual production for a decade and ending above five times global vehicle output in 2025. That is scenario arithmetic, not a production forecast. Actuators, hands, batteries, and rare-earth magnets have to scale alongside intelligence. I think a billion robots is a 2040s story.
Software gets cheaper to produce. My bet is that more value moves to the things software cannot produce on its own: energy, physical operations, and useful experience of the physical world. Data processing still needs compute and electricity. But buying more compute does not, by itself, give you the recording of a failure your fleet has not encountered.
Why data is the bottleneck
A robot is only as good as three things: its software, its chip, and its hands. Chips and hands improve on hardware timelines. Software improves as fast as the data it learns from.
Language models could draw on an internet of text people had already written. Physical work needs recordings that preserve actions, sensor context, and the conditions a machine must handle. A video of someone folding a towel is not automatically a training example for a robot with different hands. Useful experience already exists, in public datasets and in every fleet's own logs, but it is incomplete, unevenly covered, and mostly disconnected from the decision a particular model needs. The experience that matters most is still produced one deployment at a time. Teams still have to find, qualify, and supplement it for the tasks and environments they care about.
It gets made three ways. People wear cameras while doing real tasks. Operators steer a robot by hand. And robots in the field report back what worked and what didn't. The failures are worth more than the successes when they reveal what the model still needs to learn. A repeated failure is not necessarily new information, and a recording still needs context and review before it becomes useful supervision.
Simulation and better models can reduce the real data required for a particular task. That is useful progress. Our bet is that teams will still need to test what works in their deployment conditions, investigate what fails, and decide what to collect next.
What becomes cheap, and what doesn't
The same force that makes software cheap sorts this business too. The labeling tool itself becomes cheap. A string of one-off labeling projects is a services business, however you package it.
What holds value is different. A verified capability: the thing the machine must do, the situations that exercise it, the evidence it was trained on, the standard it was scored against, and the result, kept together so the same capability can be tested again against the next release or the next model. A repeatable process for collecting and correcting the next useful examples. And people whose experience helps them recognize when apparently plausible data is wrong.
That history helps a team investigate a failure. It does not, by itself, establish which training example caused a particular prediction. Data attribution is a separate technical problem. The useful promise is that the team can recover what went into the model and inspect the evidence, rather than start the investigation with missing records.
The industry's attention is on robot brains and robot bodies. The layer that decides how well either one learns gets treated as a line item. That is the mistake we are betting against.
What we are building
One way to place it. The AI stack has five layers, from the machine at work down to the electricity that powers it: apps, models, infra, chips, energy. Data is not a layer of its own. It lives in the model layer, as the customer's asset, because it is what the model learns from. Infrastructure is what a model is built, improved and run on: everything to do with the data that creates it, and the compute beneath. Avala is in the infra layer, directly under the customer's model. We do not build robots, own the customer's model, sell compute, or make chips. We build the data and learning infrastructure by which the customer's own model learns from its own fleet.
Avala is Fleet Learning Infrastructure for Physical AI. We start with production data: multimodal recordings, annotation, and quality review. A camera image, a LiDAR point cloud, and a robot trajectory describe related parts of an event. Their timing, geometry, and review history matter to whether the resulting training data is usable.
Consider a vehicle approaching a construction zone that changed overnight. Its model struggles with the new layout. Finding the recording starts the investigation. The team still has to check the sensor context, decide which examples are useful, correct or collect the data, and accept a training release. Then it can test whether a candidate model handles that situation more reliably. That is the work we want to make repeatable.
The next dataset should answer a question. A machine can fail because it has not encountered a situation, because its supervision is inconsistent, or because the problem lies somewhere other than its training data. Sometimes the right intervention is to repair a calibration, change an ambiguous annotation policy, or rebalance the data a team already has. A credible data partner should sometimes tell a customer not to buy more data.
Our entry point is a specific problem a team needs solved now: inconsistent labels, missing examples, or a training set that needs another round of repair. Define what acceptable means. Compare turnaround, quality, and total effort with the previous process. A faster delivery matters; whether the model improves is a separate result to establish with the customer's evaluation.
The commercial threshold is practical. If the team can repeatedly get accepted data with less coordination and rework, it has a reason to bring us the next workflow. Expansion has to reuse the same infrastructure: another release, another model, another team. If each one requires another bespoke engineering project, we have more projects, not an infrastructure position.
Better data has to be demonstrated, and three questions stay apart because each needs its own evidence: did the data meet its specification, did producing it get more effective, and did the model perform better under an evaluation the customer runs. Passing a quality check does not, by itself, prove that a model improved.
Data versioning already exists. The harder connection is between sensor context, expert decisions, dataset releases, and the next data requirement. Mission Control brings software and expert operations together around that work. Our ambition reaches further into the learning operation, while customers retain authority over training and deployment.
Two systems should improve. The customer's model should have a clearer path from an observed failure to a tested improvement. The system that develops its data should get more capable with every program: a production error we observe or a disagreement between experts we adjudicate becomes a better check, a clearer instruction, or a better tool, validated on held-out evidence before it reaches the next release. What compounds for Avala is method: reusable software, integrations, review standards, and operating experience. A customer's recordings, labels, evaluation results, and models stay inside its own program. Making the next deployment easier must not depend on quietly pooling one customer's information with another's.
People are part of that foundation. The difficult cases need judgment and domain knowledge. We want that experience to accumulate, supported by good tools, fair compensation, and paths to more skilled work. Automation should remove repetitive effort while giving experts better ways to investigate the cases that matter.
People hear "labeling" and think that is the business. It is how we start with a customer. The business is the loop.
Here is where we want it to go. A machine encounters something unfamiliar. Its team can find the recording, commission the corrective data, accept a versioned release, and evaluate a candidate model. What happens after deployment informs the next cycle. We want a small robotics team to depend on that process as readily as a large company with its own infrastructure organization.
We intend to earn that position one working process at a time: prove a production workflow, extend the foundation across models and teams, automate the research between discovery and improvement, and make it portable across the ecosystem. That is the bet behind our vision for the decade ahead.
What we are optimizing for
The bet is not on a hype cycle, and it is not on data volume. Both will be won and lost several times before this transition is finished. The bet is on the engine underneath them, the one I watched work at Tesla and have not seen disproven since: machines get better by continually learning from their own experience, and the people and companies who own that experience should own what it teaches.
So we optimize for the long term, and for one outcome: that this technology is good for people, sustainably, and for as many of them as possible. Physical AI will change what work is, who can afford care, and how goods and food move. We want that change to be checkable, not assumed. Machines measured before they are trusted. The people who teach them paid and trained for it. The owner of the machine owning the model. Small teams able to build on what only the largest companies could afford before.
Two commitments follow. Continual learning is the engine, so we build the infrastructure that runs it, not a product that sells one turn of it. And ownership stays sovereign: a fleet's experience, and the intelligence learned from it, belong to the people who produced it, on open formats they can leave with, never pooled with another company's and never rented back to them.
That is what Avala is: the open fleet learning infrastructure for people-first AI and robotics. Everything above is how we earn the right to be it.
The short version
The dates will move. The work is concrete: start with one capability a model needs to learn, help the team turn what its machines experience into the next useful training release, measure what changed, then make the next cycle easier. The size of Physical AI does not guarantee Avala a place in it. We have to earn that place through systems customers can depend on.
If you want the detail on how the different kinds of robot data compare, on cost and on what each one teaches a model, read our buyer's guide to the robotics data pyramid.
Building robots? Bring us a production workflow worth improving.
Want to build the infrastructure behind better machines? Join the team.
Emal Alwis is the founder and CEO of Avala.
