In robotics, “platform” often becomes shorthand for everything around the autonomy stack: data infrastructure, simulation, deployment, fleet operations, hardware integration, and developer tooling. However, the list describes what a platform team builds, not what the platform is for.
After a decade building autonomous machines and large-scale AI infrastructure, I have come to see the purpose of a physical AI platform as enabling intelligent machines to learn efficiently from real-world experience at scale. Platform is the learning system.
At Bonsai, we bring intelligence to OMC tractors and shakers, Flory sweepers, and our own Amiga Max, Trax, and Flex vehicles. We need one platform that lets us improve quickly, operate reliably across a distributed fleet, and extend to new machines and jobs without starting over.
A robot is only as good as its ability to learn from yesterday. The goal is a learning machine: one whose field experience can be turned into verified improvements and deployed back across the fleet. The physical AI platform makes that cycle possible. It must support different machines without fragmenting the autonomy stack, evolve without disrupting machines already in the field, and make each machine work coherently from user intent through physical action and feedback.
The Engine of Continuous Improvement
Learning from the Field
Continuous improvement begins with a trustworthy record of what happened in the field. The goal is not to collect everything. It is to preserve the right data, with enough context to make it useful.
An off-road machine can produce far more sensor data than a rural connection can upload. The onboard system has to decide what is worth keeping, how much context to preserve, and when to send it, while autonomy is running, storage is limited, and connectivity comes and goes. An autonomous Amiga has no cab and no operator available to swap a drive or restart an upload. Data collection has to run whenever the machine runs, without human attention.
Learning from the field is broader than model training. A machine learning engineer may need examples of a difficult visual condition. A firmware engineer may need to know whether a motor overheated. An on-call engineer may need to reconstruct the seconds before a machine stopped. The same data foundation should support all of them.
Answering those questions requires a coherent record of each event. Camera frames need to line up with IMU and GNSS measurements, vehicle motion, machine state, and autonomy decisions. An engineer investigating an event should be able to see what the operator asked the machine to do, what the machine sensed, what the autonomy stack decided, what commands were issued, how the controllers and actuators responded, and what the machine did as a result. That same record should support model development, engineering diagnosis, and fleet operations, giving each of them a consistent account of what happened.
Verifying Before Deployment
Learning from the field gives us new examples, failures, and opportunities to improve. The next question is whether the resulting change is ready to control a real machine.
As AI makes code generation faster, verification becomes the limiting factor. AI does not make software engineering disappear. It moves engineering effort from implementation to verification.
This does not reduce the need for engineering judgment. It changes where confidence comes from. As AI writes more code, we cannot assume that an engineer has reviewed and understood every line before the system runs.
That is not entirely new. Software teams already depend on compiler output, generated bindings, third-party libraries, and vendor firmware that nobody on the team has read line by line. We trust them because we test their behavior and constrain how they interact with the rest of the system. AI-generated code needs the same discipline, but code written specifically for our machines has not already been exercised by thousands of other users. The evidence has to come from our own testing. Safety-critical paths still require their own review, analysis, and process.
Software products need a software testing harness. Physical AI needs a physical testing harness.
At Bonsai, that harness spans software tests, model evaluation, log replay, simulation, control simulation, and hardware-in-the-loop (HIL) simulation. Hardware-in-the-loop simulation runs production software on the actual onboard computer, through the same sensor interfaces and under realistic compute and timing loads. It exposes problems a software-only environment may never reveal, such as CPU saturation, timing drift, thermal constraints, device-driver failures, and integration problems at the hardware-software boundary.
The harness also has to improve with the fleet. Once we fix a field issue, the relevant scenario should become a permanent regression test. Field logs provide real situations, engineers construct focused cases, and synthetic scenarios can eventually expand coverage to situations our machines have not yet encountered.
AI increases the rate at which we can make code changes. The testing harness has to increase the rate at which we can trust them. That is how we gain speed without lowering the bar for deployment.
Shipping and Operating at Scale
An improvement only becomes useful when it reaches the fleet and works reliably there.
A physical AI release is rarely a single binary. It may span models, autonomy software, platform services, vehicle firmware, machine configuration, cloud services, and the operator application. These components may ship on different schedules, but they still have to work together as one compatible system. We need to know which versions can run together, which interfaces must remain stable across releases, and which changes must be deployed in coordination.
A fleet never updates all at once. Machines may be offline, connectivity may fail midway through an update, and different customers may accept releases at different times. Deployment therefore requires controlled rollouts, a clear view of what each machine is running, health checks, and a reliable recovery path. With A/B system partitions, a machine can return to a known-good version after a failed or interrupted update without requiring service in the field.
Deployment also has to remain observable after the software reaches the machine. If a machine stops halfway through a cycle, an engineer should be able to inspect the software and firmware versions, machine state, sensor context, and system health around the event. That context helps us understand the failure, determine whether it is isolated or widespread, and decide whether a release should continue, pause, or roll back.
What we learn from fleet operation feeds the next change. A field issue may become a new test case, reveal a missing diagnostic signal, or lead to a change in the model, software, firmware, or machine configuration. The improvement then returns to the fleet through the same controlled deployment process.
One Platform for Every Machine
At Bonsai, our goal is to run one autonomy stack across every vehicle we support. We standardize onboard compute, sensors, and the software environment wherever practical, but the machines underneath remain physically different. Their geometry, dynamics, sensor layouts, controllers, and actuation systems vary. The platform handles those differences so autonomy can perceive and control each vehicle through a consistent set of interfaces.
Some machines steer like a car, while others use skid steering or drive geometries that allow sideways motion. Their actuation systems may range from electro-hydraulic valves on a diesel-powered machine to direct motor control on a battery-electric vehicle. Autonomy may control both the vehicle and an implement that sprays, shakes, sweeps, mows, lifts, or hauls.
To the autonomy stack, these machines should expose the same basic concepts. Cameras, IMUs, GNSS, vehicle motion, machine state, and health information arrive in a standard form. Autonomy expresses the motion and implement behavior it wants, and the platform translates those requests into commands the specific machine can execute. Vehicle-specific drivers, calibration, control adapters, and implement integrations remain close to the hardware.
The same approach extends beyond vehicle control. Data collection, configuration, deployment, health reporting, and debugging should remain shared across the fleet. Supporting a new machine should not require a separate data pipeline, deployment system, or set of operational tools.
This common foundation also gives us a path toward one model across machines and jobs. When sensor data, actions, and machine responses are represented consistently, field data from different vehicles can feed the same model-development and evaluation process, while the platform handles the hardware-specific details.
None of this is free. A vehicle-specific shortcut can sometimes make one integration move faster, but we avoid it when it would push machine-specific logic into autonomy, data infrastructure, deployment, and operations. Unifying systems that developed separately creates short-term complexity. Allowing each vehicle stack to keep diverging creates a cost that grows with every new machine and every future improvement.
Every new machine still requires serious integration work. That work should expand the shared platform and make the next integration easier. It should not create another stack the company has to build and maintain.
Built to Evolve
The rate at which intelligence improves is eventually limited by the rate at which the platform can safely evolve.
A physical AI platform has to support generations of models, sensors, compute platforms, operating systems, robotics frameworks, and middleware. Without deliberate design, the stack fossilizes around the versions it started with. Dependencies become fragile, builds slow down, coupling spreads, and a routine upgrade turns into a major migration.
Replaceability has to be built in before the system becomes painful to change. That means controlled dependencies, fast and reliable builds, clear boundaries between components, and infrastructure that can be upgraded without rewriting the rest of the stack.
At Bonsai, we are adopting Pixi to create hermetic, reproducible development environments. We are moving more system services toward Rust where memory safety and operational reliability matter, and treating ROS 2 upgrades as routine platform maintenance rather than major migration projects. Core middleware should remain behind stable interfaces so it can be upgraded or replaced as requirements change and better options emerge.
The point is not to adopt new technology for its own sake. It is to avoid turning today’s choices into a permanent tax on future work. Slow builds, brittle dependencies, manual release steps, and tightly coupled components all reduce the rate at which we can improve the fleet.
This is why I consider developer velocity a product property in physical AI. Customers never see our build times or how we manage software dependencies. They see the results in faster fixes, quicker support for new hardware, and a shorter path from a better model to better behavior in the field.
Designed as One System
The components described above may be built by different teams, but they come together in one machine. Customers experience the behavior of that machine, not the organizational boundaries behind it.
An operation may begin with a request from a web application, an on-vehicle dashboard, or a teleoperation interface. Autonomy combines that intent with sensor data and vehicle feedback to decide how the machine and its implement should behave. The platform translates those decisions into commands the specific vehicle can execute. As the machine operates, vehicle state, system health, and job progress flow back to autonomy, operators, engineers, and cloud services.
Clean APIs are necessary, but they are not enough. Timestamps can drift out of alignment. A calibration error can shift where the machine believes an obstacle is. Firmware can report a state that the autonomy software interprets incorrectly. A cloud service can send configuration that an older machine cannot safely apply.
Timing is a good example. A camera can timestamp every frame correctly, but that timestamp may lose its meaning as the frame moves through the system. If it is dropped, rewritten, or cannot be related to the vehicle’s shared clock, perception may combine the image with vehicle state from a different moment. The camera driver and perception software can both appear healthy while the machine acts on misaligned information. The faster the machine moves, the more significant that error becomes.
Avoiding this requires a time contract across the system. The timestamp must be captured at the sensor, preserved through transport, and correlated to a clock the whole vehicle can use. Similar contracts are needed for message schemas, units, coordinate frames, version compatibility, failure behavior, and observability. They must remain consistent across sensors, controllers, firmware, platform and autonomy software, cloud services, and user interfaces. The resulting behavior must be tested on the complete machine, not only within individual components.
In physical AI, interface mismatches become physical behavior. They can cause an unnecessary stop, a missed task, equipment damage, or unexpected motion. Correct components are not enough when their combined behavior is wrong.
Each layer should have a clear owner, and so should the behavior that crosses layers. A safe stop, for example, depends on autonomy deciding to stop, the platform issuing the correct command, the controller enforcing the right limits, the firmware responding predictably, and the machine reporting what actually happened.
This is where platform ownership matters most. It does not mean centralizing every component or owning every line of code. It means taking responsibility for the system behavior that emerges across interfaces, and making sure the complete path from user intent to physical action and feedback can be observed, tested, and debugged.
The Machine That Improves the Machines
When these systems work together, each machine can become a learning machine. Field operations reveal where the models and the broader system still fall short. The platform turns those lessons into engineering changes and new tests, then returns verified improvements to the fleet. Because the same foundation spans machines and evolves over time, each improvement can reach more of the fleet and make the next improvement easier.
The deeper goal is not only to build better machines, but to increase the speed and confidence with which we improve them. Each hour in the field should add useful experience. Each failure should become something we understand and know how to test. Each new vehicle should broaden the common foundation rather than divide it. The platform is not the software around the robot. It is the system that turns every hour in the field into the next generation of intelligence.
Models, hardware, and engineering tools will continue to advance. The durable advantage in physical AI is the ability to absorb those advances and repeatedly turn them into reliable capability across a working fleet. That is the machine that improves the machines, and it is what we are building at Bonsai.
Lingjian Kong is the Head of Robotics AI Platforms at Bonsai Robotics, where he leads the autonomy platform and AI infrastructure powering physical AI for off-road autonomy at scale. His experience spans the full stack of autonomous systems development, from high-performance embedded software to cloud-native distributed platforms. Previously at Apple, he built large-scale computer vision and data infrastructure to accelerate AI development on Apple hardware. Before that, he was a founding software engineer on John Deere’s first fully autonomous tractor at Blue River Technology, unveiled at CES 2022. Lingjian holds a B.S. in Mechanical Engineering with a minor in Mathematics from the University of Illinois Urbana-Champaign, an M.S. in Mechanical Engineering from Columbia University, and an M.S. in Computer Science from Georgia Tech.