How every run becomes feedback.

Robot learning in the real world still runs through people. When a run fails, a person works out why, and engineers retrain and redeploy by hand.

Each pass waits on a person, so deployment is slow and expensive. It also scales badly, because every new or changed environment brings new failures that need the same manual diagnosis.

AI agents could take on much of that diagnosis, but they do not have enough physical context to understand what happened in the real world. That is the context Zonta is building.

Our drones are designed to observe the environment continuously while the robot works. A robot's own sensors point at its task. The drone looks from outside, so it can keep the robot, the object it is handling and the room around them in one view, and move when the robot moves.

The drone on our home page is a compact design, shown part by part from its CAD model. Its sensors are chosen to measure the space around it and hold it in position. All of them run from one small flight controller.

• Front and rear depth sensors to measure the space around it.
• Downward ranging and optical flow sensors for height and motion over the floor.
• A UWB radio on its own daughterboard for positioning.
• A XIAO ESP32-S3 flight controller with an inertial sensor, a barometer and a magnetometer.
• A single 1S 480 mAh cell with current and voltage sensing.

Interpretation starts with a reconstruction. The plan is to combine the drones' observations into a 3D model of the scene, updated as the run goes on. What happened can then be examined from any angle, not only from where a fixed camera happened to be.

The simulator on our home page shows the idea at small scale. The map of the track fills in as the drones see more of it. A lab recording on the simulator page shows a workspace rebuilt in 3D from recorded observations.

Frontier AI agents are getting better at reasoning through a failure when they can see it. What they lack today is physical context: where the robot was, what was around it, what moved, and what each of the robot's actions did to the scene.

We are building the step that turns the reconstruction into that context. The aim is that an agent can ask what the robot did, what came of each action and where the run went wrong, and get answers grounded in the 3D scene.

We plan to serve this context over MCP, the Model Context Protocol, so agents that already use it can connect without custom integration work.

Understanding a failure only helps if something changes because of it. Once the agent knows what went wrong, the feedback goes back into training in three places.

• Policies, adapted for the cases where the robot failed.
• Simulations, updated to match the conditions the robot actually met.
• Training scenarios, generated around the failure so the next policy practices it before the next deployment.

The robot redeploys with what changed, and the drones watch the next run. That run produces new feedback, and the loop starts again.

The long-term goal is to make robot training and deployment one continuous loop, and to cut the number of times an engineer has to step in by hand after a failure.

Recursive Self-Improvement Reinforcement Learning, RSI RL for short, is the direction we are working toward. It describes a system in which every real-world deployment generates feedback that improves the next one.

The loop improves the policy, and it also improves the simulations and scenarios the next policy trains on.

RSI RL is a goal, not a shipped system. The roadmap below keeps the two apart.

Robotics teams that train policies, often with reinforcement learning, and deploy them in places that keep changing. The problem is sharpest where every failed run needs a person to explain it.

Zonta is being built as a product those teams run with their own robots: drones plus software. We are not a service that deploys robots for hire.

Teams start by booking a demo. The first call is about your robots, where they run and what happens today when a run fails.