The problem
AI can write a contract, debug a program and read a chest x-ray. Put it in a room and it cannot tell you how far away the door is. Everything it knows arrived as text and pictures. Distance, depth, motion, what is behind the shelf: none of that is in the training data, and the model is not in the room anyway.
Robots have the opposite problem. A drone knows its altitude to the centimetre and can see the floor under it. It has no idea why it is there. It flies the waypoints it was given, and if the waypoints were wrong it flies them anyway.
So the smartest software we have ever built cannot see the world, and the machines that can see the world cannot think. The two do not talk.
What exists today, and why it is not enough
Right now, connecting an AI model to a robot means writing custom glue for that one robot, that one sensor, that one job. Every vendor ships its own control software with its own commands. A drone from one company, a robot dog from another and a robotic arm from a third have nothing in common except that each needs its own integration. The demos you have seen, a chatbot flying a quadcopter or chatting with a robot dog, are one-offs. They work on stage, on that hardware, for that afternoon.
Drone control software is built around waypoints. A waypoint carries the instruction, not the intent. When a flight goes wrong nobody can say who meant what, and nothing along the way checked whether the instruction made sense.
What we do differently
In late 2024 a standard called the Model Context Protocol, MCP, gave AI models one way to plug into software tools: a database, a calendar, a codebase. We are building the same thing for the physical world. One interface for what a robot senses, the space it occupies and the actions it can take. A model reads the room through it and acts through it, and the robot on the other end can be anything.
We are starting with drones, because a drone is a sensor that can go where the question is. Ask what is on the roof and something has to go look. A drone is the cheapest thing that can.
The first tool is "follow".
The footage on this page is the first thing we taught the aircraft to do. It keeps a moving car in frame around a circuit, then does the same with a four-legged robot on a cluttered floor. Nobody is flying it and nobody wrote the path. The flight is a learned policy. It was told what to watch.
Follow is small. It is also what every real job starts with: find the thing, keep it in view, report where it is.
The model never gets the stick.
Every command a model produces is a proposal. Airspace, battery, geofence and separation are checked before a rotor turns, and a plan that fails comes back in plain words with the check that failed. A hand on the controller overrides the sentence, every time. The sentence, the plan, the checks and the flight are kept as one log, so a question asked later has an answer.
This is what we build.
The footage on this page is simulation. The aircraft in it is a model of our compact drone. The car and the quadruped stand in for whatever you need watched. The platform is in development and we are talking to early collaborators.