Every fleet should learn from its own experience.

Consider a vehicle approaching a construction zone that changed overnight. Its model struggles to interpret the new layout. The recording should become more than a log file or a one-off investigation. With the right context, it can help the team understand the failure, prepare better training data, and test whether the next model handles that situation more reliably.

That is the future we want for autonomous machines: experience that becomes useful learning, repeatedly, from the first demonstrations a team records to the fleets it eventually operates. A delivery robot, a harvesting machine, and an industrial arm face different problems. Their builders share a need to connect what happens in the world to what changes in the model. We want that connection to become dependable infrastructure.

At Tesla Autopilot, I was the first engineer to work on fleet learning: the systems that turned fleet edge cases into model improvements. That work taught me to look beyond the model itself: how the team finds useful examples, preserves sensor context, decides what happened, and turns those decisions into the next training set. The ability to repeat that process matters as much as any individual breakthrough.

I founded Avala because other Physical AI teams should not have to build that entire foundation from scratch. They should be able to put their best engineering into the machines and models that distinguish them. Avala should give them a dependable way to learn from the world, from their first production workflow to the fleets they eventually operate.

The AI stack has five layers, from the machine at work down to the electricity that powers it. 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.

1. Apps

   What a machine does for someone: the robot, the vehicle, the drone at work.

2. Models

   The brain and what teaches it: the customer’s model and the customer’s data. Evaluation and post-training happen here, on the customer’s own compute.

3. Infra

   What models are built, improved and run on: everything to do with the data that creates them, from collection to verified release, and the tooling, compute and cloud beneath.

   Avala is here

4. Chips

   The silicon.

5. Energy

   The electricity that bounds all of it.

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.

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. The first task is to understand the gap.

Our vision is a system that connects a learning objective to an explicit data plan: what existing experience to use, what new experience to acquire, how to qualify it, and what experiment will establish whether it helped. Broad coverage and targeted learning belong together. The goal is not simply a larger dataset. It is a better-supported decision about what to do next.

That discipline cuts both ways. 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.

A dataset is evidence, not the objective. For each learning objective we keep the capability being tested, the situations that exercise it, the evidence used to train it, the standard used to evaluate it, and the result.

That makes a learning program reproducible. The same capability can be tested against a new data release, a new model, or a new runtime without reconstructing the reasoning that produced it. Over time, those versioned capabilities become the operating history of how a machine learned.

A useful physical-world example is more than an image of an object. The task may depend on what happened before, what the machine or person attempted, and what happened afterward. We connect sensor observations with the context available for the task: timing, geometry, trajectories, actions where they were recorded, outcomes, and human interpretation.

That context stays inspectable through collection, review, dataset preparation, and evaluation. Missing or uncertain information is visible, not hidden behind a completed label. A reconstructed 4D scene preserves physical context so that it can be inspected; it does not stand in for measured actions, contact, or validation where a task requires them.

Our work starts with a fleet's production data: multimodal sensor recordings reconstructed into 4D data, labeled by AI and expert reviewers, and released as versioned datasets the customer trains on. MCAP and ROS recordings, camera images, LiDAR, and robot trajectories need to stay connected to the context that makes them useful. We bring software and expert operations together to prepare data that meets the customer’s training requirements.

Begin with a recurring problem: inconsistent labels, missing examples, or a training set that needs another round of repair. Define what acceptable means. Measure turnaround, quality, and total effort. Then make the next release easier to produce. That is how a specific data engagement can become a system the customer relies on, rather than another disconnected delivery.

By 2028, Avala is the open infrastructure on which any operator of machines in the physical world turns its own experience into its own intelligence, with data, models and deployment under its own control, so that everyone can be an owner of their intelligence, not a tenant of someone else’s. We intend to earn that position through four connected phases.

1. 01

   Prove one production workflow.

   Solve a problem a customer needs solved now. Deliver against a clear acceptance standard and measure the result against the previous process. Make the next cycle more reliable, not just the first delivery impressive.

2. 02

   Become the foundation across models and teams.

   Carry the same dataset identity, review history, and quality policies into more workflows. Each expansion should reuse the infrastructure already in place. The test is whether another team or model can benefit without another bespoke engineering project.

3. 03

   Automate the research between discovery and improvement.

   Build toward research agents that can investigate a fleet failure, retrieve the evidence, compare it with prior cases, propose an experiment, find or commission the missing examples, and evaluate the result. Their conclusions stay traceable to physical evidence, their evaluators are tested against hidden standards, and consequential changes remain reviewable and reversible. The aim is not an agent that produces more data. It is a system that gets better at deciding which experiment is worth running next.

4. 04

   Make learning portable across the ecosystem.

   Connect robot stacks, models, and infrastructure through open interfaces. Teams should be able to adopt better tools without abandoning their history. Shared datasets and models can extend that foundation where their owners choose to share them and reuse is permitted. Interoperability should widen access, not require surrendering control.

Useful physical-world experience already exists, but it is incomplete, unevenly covered, and mostly disconnected from the decisions that would improve a particular model. The experience that matters most is still produced one deployment at a time, by the companies that own the machines, and it is mostly exceptions: the situations no one simulated. No single company will hold it. That is why the infrastructure that finds, qualifies, combines, and supplements it has to be independent, and why it has to leave ownership where the data came from.

Customers should retain their proprietary advantage. Learning from a fleet’s experience must not mean quietly pooling its data with a competitor’s. A customer’s recordings, annotations, evaluation results, and models never become another customer’s advantage without that customer’s explicit agreement. A shared dataset is shared by agreement, with reuse made explicit. Open means something specific to us: interoperable interfaces, exportable data and history, clear usage rights, and customer-controlled deployment. Independence means your infrastructure partner is not owned by a model lab, a robot maker, or a hyperscaler. Avala should earn its place through the value of the system, not the difficulty of leaving it.

The people who teach and evaluate machines contribute more than annotation capacity. They define tasks, recognize meaningful mistakes, judge outcomes, and set the standards that automated systems are tested against. Their judgment deserves good tools, fair compensation, and paths to more skilled work. We want automation to remove repetitive effort while making expertise more valuable: better decisions captured in the process, better software supporting the next task, and fewer mistakes repeated.

The larger purpose is safer, more productive physical work and useful services that more people can afford. We want a small robotics team to build on capabilities that would otherwise demand a large internal organization. Better machines are the means. More people able to build, earn, and benefit from them is the goal.

Physical AI will change what work is, who can afford care, and how goods and food move. We want that change to be good for people in a way that can be checked, not assumed. Four commitments shape how we build.

1. 01

   The people who teach machines are paid and trained for it.

   Avala’s coworkers are paid for accepted work, at rates above the norm for the work and the place, with training built in. Automation removes repetition; the skilled judgment stays with people.

2. 02

   The owner of the machine owns the model.

   A company’s fleet data and the intelligence learned from it stay under its control, on open formats it can leave with. No lab, robot maker, or cloud sits between a team and its own experience.

3. 03

   Measured before it is trusted.

   Every release is scored against a baseline the customer sets, including what did not improve. A machine earns wider use by evidence, one evaluation at a time.

4. 04

   Small teams get large-company capabilities.

   A robotics team of ten should be able to learn from the world the way a fleet of thousands does. Lower the cost of that loop and more people get to build, earn from, and benefit from better machines.