Can an AI Agent Run a Robot Unsupervised? Not Yet, and Here's Why

No: an AI agent can choose a robot's next action, but the layer that stops the arm before it hits the table must stay hand-written. An agent reasons in bursts, while the machine commits to physics continuously, so something underneath, ROS 2 or a shared-memory middleware such as HORUS, has to hold the limits the model cannot. The verdict flips only where nothing the robot can do causes harm. The rest of this post is for people who build with language models and are now being asked to point one at hardware.

You already know how this feels, because you have built the software half of it. The agent works. It reads the task, decomposes it, calls tools in a sensible order, notices when a step fails and tries something else. In a terminal it looks close to finished.

Then it is attached to an arm, and the surprise is not that it fails. It is how it fails. It calls the grasp tool with a target that would put the gripper through the table, confidently and with a reasonable explanation. It decides the object it wanted is missing and picks a different one, which happens to be a cable. It retries a motion that already failed, unchanged, because retrying has always been free.

Then come the other symptoms. The loop stalls while the model thinks, and the machine keeps moving during the pause. Something gets knocked over and the transcript reads as though everything went fine. You start adding checks around each tool, and the checks slowly become the real program.

Underneath it all is the question that makes the demo unshippable: what exactly would have to be true before nobody has to sit next to this thing?

Can an AI agent be trusted to run a robot with nobody watching?

Not for any machine capable of damage, and that is a statement about arrangement rather than about model quality. The problem is not that models are unintelligent. It is that a model is one component in a system where being right most of the time is not the standard, because the failures are physical and do not roll back.

Software agents live in a world with undo. A bad command produces an error, a wasted call, a message you can delete. A robot's bad command produces a bent finger, a cracked panel, a person startled at close range. There is no retry semantics for a collision, and no amount of reasoning quality converts an occasional confident mistake into an acceptable one when the mistake has mass behind it.

So the useful question is not whether an agent could run a robot alone. It is what has to sit underneath so that the agent's worst plausible output is survivable. Build that layer honestly and the machine can run for long stretches unattended, and you will notice the autonomy came from the layer rather than the model.

What does it actually mean to put an agent in charge of a machine?

There are three distinct jobs inside any robot, and putting an agent in charge means handing it exactly one of them. The first job is deciding what to do next: pick up the mug, go to the door, ask for help. The second is working out how, as a sequence of positions or velocities. The third is executing that continuously, adjusting on every cycle as the world pushes back.

Language models are strong at the first job, workable with help at the second, and unsuited to the third by construction. The third job needs a new command on a fixed rhythm, forever, whether or not anything interesting happened. A model produces output when asked, in bursts, sometimes slowly, sometimes with something unexpected in it.

Almost every argument about agent autonomy is a disagreement about which of the three jobs is being discussed. An agent choosing the goal while hand-written code reaches it is standard practice and works today. An agent producing motion commands directly, with nothing checking them, has yet to survive contact with an unstaged room.

What are the real options for connecting a model to a robot?

There are about eight, and they differ mostly in how much stands between the model's output and the motor. At the cautious end: a person carrying out what the model suggests, then a fixed set of vetted skills the model can call, then a model that plans while hand-written code executes and enforces limits. At the ambitious end: a learned policy driving the joints directly, which is a live research area rather than a product pattern.

The plumbing underneath is a separate choice. ROS 2 is the ecosystem option, bringing drivers, navigation, recording and a way to run the model as one node among many. A focused middleware such as HORUS is the other shape: Rust, Python and C++ processes on one machine sharing the same memory, so the process holding your model and the process holding your controller exchange data without serialising between them. It is not an inference engine, does not train or run models, and does not replace the ecosystem pieces.

Then two options people forget: simulation only, and teleoperation with model assistance. One of those is how most commercial robots earn money today.

How do the ways of wiring a model to hardware compare?

They differ in how much of the machine's behaviour the model is allowed to determine, and how much of that a person had to write first. Read the last column before the others.

Does this change if you are one developer rather than a funded team?

Yes, and it changes what you should aim at rather than how careful you should be. A solo developer with a small arm on a desk has one enormous advantage: the worst outcome is a knocked-over cup, so you can genuinely let an agent run and learn from what it does. Take that advantage. Give the arm a bounded workspace, low forces, a physical stop within reach, and let the model be wrong repeatedly where being wrong is free.

A funded team on a machine that can hurt somebody has the opposite constraint. The interesting failures are the ones you must never see even once, which means the limits get written first, in code, tested deliberately, before the agent is connected to anything.

The mistake both make is the same, in opposite directions. Solo builders over-engineer supervision on a machine that cannot hurt anything, spending months on infrastructure instead of learning what the model does. Funded teams demo on the real machine with limits that exist only in the prompt. Match the ceremony to what the machine can physically do at its worst.

Does the answer depend on whether the robot is an arm, a rover or a humanoid?

Completely, because the three fail in different directions and require different things underneath. A fixed arm fails within a known volume. If nothing valuable is inside the reach envelope, an agent can experiment there with genuinely low stakes, which is why arms on benches are where most agent robotics learning happens.

A wheeled rover fails by going somewhere. The envelope is not a volume any more, it is the building, and the failure that matters is not a bad grasp but continuing to drive while the model is deciding. Rovers need a reflex below the agent that stops on an obstacle without asking anyone, and they need it before the first unsupervised run.

A humanoid or any legged machine fails by falling, the hardest case, because staying upright is a continuous job the agent cannot be part of. Balance runs constantly underneath everything, and the agent is a guest on a machine that is already busy. There, the agent picks tasks and never touches the loop keeping the machine standing.

How much does your timeline change what you should attempt?

A date this quarter means teleoperation with model assistance, or an agent restricted to a short list of skills a person already wrote and tested. This is not a compromise position. It is what shipping robot companies are doing right now, and a large part of why their demos look calm.

The reason timelines bite so hard here is that the work is back-loaded. Getting the agent to plan the task is the quick part, often a weekend. Getting it to behave the same way on a Tuesday with different lighting, a moved table and a slightly different object takes many times longer, and there is no version of that work that can be skipped by choosing better tooling.

With a year, the right investment is unglamorous: build the skill layer properly, make every skill refuse impossible requests instead of attempting them, record everything so a failure can be replayed at a desk, and only then widen what the agent may decide. Teams working in that order end up with more autonomy than teams that started by giving the model everything.

What if you know language models but have never touched hardware?

Then your instincts about failure will be inverted, and knowing that in advance is worth more than any framework choice. Coming from software agents, you expect failures to be discrete: a call errors, you catch it, you retry. Hardware failures are continuous and partial. A grasp half works. A sensor reads plausibly and is wrong. A motion completes and leaves the object rotated ten degrees from where the next step assumes it is.

The habit to break is retrying. In software, retrying is close to free and often correct. On a machine, an immediate retry of a failed motion is a request to repeat whatever went wrong, sometimes against an obstacle. Every skill you expose to a model needs to answer what to do on failure, and the answer is rarely to try again unchanged.

The second habit to break is trusting the transcript. An agent's account of what happened is generated from what it intended, not from what the machine did. Log what the hardware reported, separately, and compare the two. Why these systems look excellent in demos and stumble in a kitchen is mostly this gap.

What does an unsupervised agent look like when it goes wrong?

It looks calm, which is the part that surprises people. There is rarely a dramatic moment. The machine does something slightly wrong, reports success, and continues from a world that no longer matches what it believes. Everything after is confident and increasingly detached.

The recognisable pattern is a quiet divergence. The agent picks up nothing and records a successful grasp. It places the nothing, updates its plan, moves on, and now the physical scene and the internal story have separated. The machine keeps executing plausible actions in a world that stopped matching. By the time a person notices, the transcript reads as a competent session and the room disagrees.

The second pattern is the stall. The model takes longer than usual on one call, and whatever the machine was doing continues during that pause because nothing told it to stop. On an arm mid-motion this is a scratch. On anything with momentum, it is the incident.

Both patterns have the same root: the agent's picture of the world updates when the agent thinks, and the world updates whether or not anyone is thinking.

What do you give up by keeping a hard limit under the agent?

You give up some of the capability you were excited about, and you should be honest that the loss is real. A limit that refuses anything outside a known envelope also refuses the clever solution nobody anticipated. The agent that would have found a novel way to reach behind the box is now the agent that reports the box unreachable and asks for help.

You also give up development speed, at least at first. Every skill needs its own refusal conditions, every limit needs a test that proves it triggers, and none of that work is visible in a demo video. It is the least rewarding code in the project and the reason the project is allowed to run unattended later.

The third cost is philosophical and worth naming: your system's ceiling is now set by what a person thought to allow. That genuinely caps the machine. It is also the trade every deployed robot has made, and the alternative is not a higher ceiling. The alternative is a machine that nobody is willing to leave alone in a room, which has a ceiling of zero.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the hard part of your robot is the world rather than the wiring. If the machine must map an unfamiliar building, plan around a person, localise, recognise objects and talk to a fleet manager, ROS 2 hands you years of work directly relevant to putting an agent on top of a robot that already knows where it is.

ROS 2 also wins on the practical things. Drivers exist for the hardware you bought. You can record a failed session and replay it at a desk on Monday, which matters when the model's output changes between runs. Every tutorial, contractor and new hire arrives already fluent, and the tooling for watching what is being published is there while you learn what your agent does.

HORUS is not the answer in those cases. A shared-memory middleware carries messages between processes on one machine and brings no mapper, no planner, no fleet interface and no camera driver. Choose that shape only when the model, the limit checks and the controller share one computer and the handoff between them is the fight. Otherwise you are writing the ecosystem yourself.

Will a bigger model eventually remove the need for a supervision layer?

No, and here is why. The supervision layer is not compensating for a model being insufficiently clever. It enforces a property no amount of cleverness provides: the machine's behaviour stays inside a boundary on every cycle, including the cycle where the model is still thinking, the one where inference failed, and the one where the answer came back garbled.

There is also a structural point that scale does not fix. To trust a machine near people, you must state what it will never do and show why. A claim about a learned system's typical behaviour is not the same kind of claim as a checked limit, and safety cases, insurers and customers want the second kind. That is why capable systems elsewhere keep a simple checker underneath a sophisticated decider.

Better models do change something real: they widen the envelope worth allowing, because a planner that fails less often earns more freedom. The layer stays, and what it permits grows on recorded evidence rather than on exciting release notes. An honest account of what a chat model can drive today is worth reading before promising a customer anything.

Does supervision just mean a person watching a screen?

Partly, but not the way you think. A person is one form of supervision and by far the weakest, because human attention on an uneventful task degrades quickly and the events that matter happen faster than a person reacts. A watcher who has seen the robot do the right thing for two hours is not watching in any useful sense by the third.

Real supervision is mostly code, and it is layered. A limit check that rejects any command outside the envelope. A watchdog that stops the machine if the deciding process goes quiet. Sensor agreement checks that catch a reading drifting from the others. A confirmation step for the small number of actions that are hard to undo. A physical stop that works regardless of what any software believes. Only the last of those needs a human, and only for the seconds after something has already gone wrong.

The useful reframing is that a person is a fallback, not a control system. If your plan depends on somebody reacting in time, you have not built supervision. You have built an audience.

How do you decide how much autonomy to give your agent?

Start from what the machine can do at its worst, not from what the model can do at its best. Write one sentence describing the most damaging outcome physically possible with the hardware in front of you, then grant exactly the autonomy that survives that sentence. A desk arm with limited force and a bounded workspace survives a great deal. A machine that can move a person does not.

Then run the test that settles arguments. Let the agent work for an hour with a person present but not intervening, and count only two things: how often it believed something that was not true, and how often something outside the model caught it. If the second number is not comfortably larger, the supervision layer is thinner than the plan assumes, and no prompt change will fix that. The layer that sits between the model and the motor is where the fix lives.

Then widen slowly, one skill at a time, on evidence you recorded rather than on a session that felt convincing.

• If you are learning with a small arm on a desk -> let the agent run now, because the worst outcome is a knocked-over cup.
• If the machine can injure someone -> a person present and a hard stop, until the limits are written, tested and proven to trigger.
• If you have a delivery date this quarter -> a fixed list of vetted skills, because writing safe skills is faster than making a model trustworthy.
• If the hard part is mapping, navigation or drivers -> the ecosystem first, because an agent on a robot that cannot localise is an agent that guesses.
• If the model, the limit checks and the controller share one machine -> a shared-memory middleware, because that handoff is the thing you are fighting.
• If you cannot state the worst physical outcome -> stop and find out, because everything else on this list depends on that answer.

The HORUS Fit Framework reduces the plumbing half of this to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score each candidate on all five, and pick the one that is not weak where your project cannot afford weakness.

If the axis that keeps deciding it is a model and a controller sharing one machine, put HORUS on your reading list rather than this week's build: star it so it is in your list when you start building.