Embodied AI vs Agentic AI: Why the Distinction Matters

Agentic AI plans in software where a failed step can be retried; embodied AI acts through a body where a failed step breaks something. That difference decides the architecture: an agent belongs on top of a robot stack such as ROS 2 or HORUS, not in place of one. The verdict flips when the machine is slow, supervised, and unable to damage anything. The rest of this post is for people who build software agents and are now deciding what to put underneath one that has arms.

You have an agent that works. It reads a request, picks a tool, looks at what came back, tries something else when the answer is wrong, and it has been good enough for long enough that somebody asked what would happen if you wired it to an arm.

So you wire it to an arm. The first surprise is that nothing throws. The camera stops sending frames and the loop carries on happily with the last picture it saw. The gripper reports closed while holding air. The arm reaches for a spot the cup left a moment ago, and no part of your stack considers this an error, because there is no error to catch.

The second surprise is the rhythm. Your loop takes as long as it takes, which was fine when a person was waiting and is not fine when a motor is. The arm moves in lurches. You add a pause, and now it is slow and still lurching.

Then somebody asks what happens if a person walks into the workspace while the model is thinking, and you find that you do not have an answer, only a plan to write one.

Does the distinction between embodied AI and agentic AI change what you should build?

Yes, and it changes the very first decision you make: an agentic system is allowed to think for as long as it needs, and an embodied one is not. The two labels sound like taxonomy until you try to reuse an agent framework on a machine. An agent's contract with the world is: call a tool, read the result, decide again, retry when the result disappoints. Every part of that contract assumes the world holds still while you deliberate and forgives you when you get it wrong. A machine offers neither. The room keeps moving during the pause, so a decision that was correct when the picture was taken can be wrong by the time it reaches a motor, and the retry is a second collision. The practical consequence is that the agent layer is not the robot. Underneath it something has to read sensors on a rhythm and stop the machine, and that layer is the one nobody budgets for.

What is the actual difference between an agent and an embodied system?

An agent chooses actions in a world that waits for it, and an embodied system chooses actions in a world that carries on regardless. Strip the marketing off agentic AI and you have a model, a set of tools the model may call, and a loop that plans, acts and inspects what happened. The environment is digital: files, interfaces, other programs. Actions are usually reversible, failures announce themselves as errors, and time is elastic. Strip the marketing off embodied AI and you have a model whose output becomes motion. The environment is physical, sensing is continuous rather than request and answer, and the machine holds a state that keeps evolving whether or not anybody asked it a question. Failures there are quiet: a stalled sensor looks exactly like a still scene, and a missing reading looks like nothing at all. That quietness is the real difference. Agent debugging starts from a stack trace. Machine debugging starts from somebody saying that it looked strange.

What are your actual options for putting an agent in charge of a machine?

You have seven realistic options, and they differ mostly in where the quick reactions live and how much of the machine you write yourself. You can run everything as one Python program, which is where nearly every first attempt lands. You can take a vendor robot with a supported interface and drive it from your agent. You can keep the agent off the machine entirely and send goals over a network. You can buy a platform sold as a finished AI robot and accept the behaviour it exposes. You can stay in simulation. Or you can treat the machine as several programs that must agree, which is where middleware arrives: ROS 2 brings the largest body of existing robotics code anywhere, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ in which the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised. Neither of them reasons about anything or runs your model. Read the table as descriptions of teams rather than a ranking.

What should you pick if you build software agents for a living?

Buy a machine you did not build, drive it from the agent you already have, and add structure only when the machine forces you to. Somebody who writes agents arrives with one genuine advantage and one predictable trap. The advantage is real: loop design, tool boundaries and evaluation are exactly the skills a machine will demand of you. The trap is assuming that everything below the decision is glue. It is not glue, it is most of the calendar. The specific shape of the failure is that the machine works while you are watching it, because you restart the script, you nudge the arm, you rerun after a dropped frame. What you are not building is a machine that behaves the same when nobody is in the room. So keep your agent loop as loose as it is today and be deliberate about exactly one thing: the boundary between the process that deliberates and the process that moves. Get that right early and you can change models a hundred times without touching the machine.

What hardware does an agent-driven robot actually need?

An agent-driven robot needs a machine that fails safely and a computer that can hold both the thinking and the moving without one starving the other. Start with the machine itself. What you want is something that goes limp or halts when told to, has a physical way to cut power that no software can veto, and does not have the reach or the force to hurt somebody during the months when your agent will be wrong. That single constraint rules out a lot of impressive hardware. Then the computer. A model usually wants an accelerator; a control loop usually wants to be left alone. Putting both on one small board is normal, and it is also where projects discover that thinking and timing are competing for the same machine. The tell is a robot that moves smoothly until the model is asked a question, then hesitates mid-reach. A camera that adjusts its own exposure will teach your system something about lighting that has nothing to do with the task.

What if you have to show something moving in a month?

Buy a machine that already works, drive it from your agent, and write no middleware at all. A month is enough to demonstrate a behaviour and nowhere near enough to build a robot, and the gap between those two is where demonstration deadlines die. The version that works: a vendor arm or a small mobile base with a supported interface, one program that reads the camera, asks the model and sends commands, and a hard-wired stop within reach of whoever is standing there. The version that fails: choosing a framework in week one, learning its build system in week two, discovering in week three that the driver for your camera is a community fork, and arriving at the demonstration with a system that starts up cleanly and has never picked anything up. If the date matters, spend the first week on hardware you can physically get hold of and the second on making the machine move without the model involved at all.

What if you have never written code that has to keep a rhythm?

Write a small loop that runs on a rhythm before your agent needs one, because the idea takes an afternoon to learn and discovering it the hard way takes months. A control loop is code that repeats on a beat: read where things are, work out the difference from where they should be, send a correction, wait, repeat. The loop must hold its beat even when the rest of the machine is busy, which means it cannot wait on a log line being flushed, a file being written, or a model finishing a thought. The pattern that works is a division of labour: the agent emits a goal now and then, and a loop underneath drives smoothly towards whatever the latest goal is. A machine built that way moves like a machine. A machine whose motors receive commands whenever inference happens to finish lurches and stutters. The timing side of a control loop is worth reading before you need it.

What do people try first, and why does it stop working?

Almost everybody starts with a single program that asks the model what to do and then does it, and that arrangement stops working the first time the machine has to do two things at once. Starting there is correct: one file, one loop, no infrastructure. It breaks in a predictable order. Camera capture, inference, motion commands and safety checks all sit in the same sequence, so the slowest of them sets the pace for all the others, and the pace is not steady. People reach for threads next, which converts a slow machine into an unpredictable one. Then queues appear, then shared state, then somebody discovers the loop has been acting on a picture from several moves ago. The arrangement that survives splits the work by rhythm instead of by feature: fast things that must never wait, slow things allowed to think. Once you have split them, the only remaining question is how the two halves share data on one computer.

What changes as the machine gets more capable?

As a machine gets more capable, the share of your work spent on deliberation falls and the share spent on everything between decisions rises. A supervised arm on a bench needs one camera, one loop and a person nearby, and a single script covers it. Add mobility and you inherit localisation, obstacles and often a second computer. Add unattended running and you inherit recovery, watchdogs and logs somebody can read the morning after. Through all of this the agent barely changes: the same prompt, the same tools, the same evaluation. The machine underneath multiplies. There is a second effect that catches teams out. A supervised machine has a person as its safety layer, and an unattended one does not, so the cost of a single missed reading rises exactly when the human is removed. This is why a team can run on one script for six months and then hit a wall in a week. The machine did not get worse; the standard got higher.

What do you give up by letting a model decide what the machine does?

You give up the ability to explain one specific misbehaviour on one specific afternoon, and that is the genuine cost. When a hand-written planner drives into a wall, somebody reads the code and finds the wrong sign. When a model drives into a wall, the fix is more data, a different prompt or another run, and the loop between noticing and fixing stretches from minutes into days. You give up repeatability in the small, because the same machine in the same room with a slightly different starting pose can make a different attempt. You give up cheap safety arguments: pointing at a rule convinces a reviewer, and saying that you tested a great deal does not. You take on evaluation as real infrastructure, because somebody has to answer whether the machine is better this week than last. None of this is a case against learned behaviour. It is a case for keeping the parts that must never surprise anybody outside the learned part.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the machine has to move around a building, and whenever most of the robot's value is code somebody else already wrote. Mapping and navigation are the clearest case: a mobile base that must build a map and drive to a goal is a ROS 2 project, because those packages represent years of work you will not reproduce next to your model work. ROS 2 also wins when your sensor ships a ROS 2 driver and nothing else, when the system spans more than one computer, and when the lab around you already speaks the vocabulary. HORUS is not the answer for those projects, and picking it there means rebuilding plumbing you could have inherited for free. There is a second case worth naming: if the model is one step inside an otherwise conventional pipeline, ROS 2 already has somewhere to put that step. Whether you need ROS 2 at all is a fair question, and the honest answer is often yes.

Is agentic AI just embodied AI without a body?

No, and here is why: the body is not an accessory bolted onto the same system, it changes what the loop is required to guarantee. An agent may pause to think and lose nothing but time. An embodied loop may not, because the machine keeps executing its last command until told otherwise, and that phrase is the whole of the safety problem in eight words. An agent's environment reports its own failures, and a body reports almost none. An agent's actions are described in text, and a body's actions are described by physics. The comparison also fails in the other direction, which people notice less often. A great deal of embodied AI has no planning loop at all: a policy maps camera frames straight to joint commands with nothing that resembles deliberation, and works beautifully. Two research traditions are meeting in the same machines right now, and pretending either one is a special case of the other loses the thing that makes each of them useful.

Will better models make the physical layer go away?

Partly, but not the way you think. Better models genuinely do remove work, and they remove a specific kind: the hand-written behaviour in the middle of the stack. Perception pipelines that took a team a year now come out of a checkpoint. Task sequencing that filled a state machine collapses into a prompt and a handful of tools. That trend will continue. What does not shrink is everything beneath the decision. A better model does not read an encoder, does not decide what happens when frames stop arriving, does not stop the arm when somebody opens the cell door, and does not make a message arrive before the next cycle needs it. If anything, a stronger model raises the demands on that layer, because a machine trusted to act on its own gets deployed where a supervised machine never went, and the price of a missed reading rises with it. The middle of the stack is being eaten. The bottom of it is not. Staff accordingly.

How do you decide which problem you are actually solving?

Ask what your machine would still need if the model were perfect, and whatever remains on the list is your robotics problem. The exercise takes five minutes and settles most arguments. Imagine an oracle that always emits exactly the right next action. Does the machine still need to read a sensor on a rhythm? Yes. Does it still need to stop when something unexpected enters the workspace? Yes. Does it still need two programs on one board to share a camera frame without one waiting on the other? Almost certainly. Nothing on that list improves when your model does. Now run the exercise backwards and list the behaviours you cannot write down as rules. If that second list is short, you have an automation problem wearing a model as a hat, and rules will serve you better. If it is long, you have an embodied AI problem, and your bottleneck is data and hardware rather than prompting. The same test settles whether one language can carry the whole robot.

Decide by situation rather than by ambition:

• If you write agents and have never owned hardware -> a vendor machine with a supported interface, because a robot you did not build teaches you fastest what you do not know.
• If the model and the control loop are separate programs on one board -> a shared-memory middleware, because moving camera frames between them is what costs you the motion.
• If the machine must map a building and drive to a goal -> ROS 2, because navigation is borrowed code and reproducing it is not your project.
• If the deliverable is a demonstration next month -> a finished platform and one script, because a month buys a behaviour and not a robot.
• If nobody on the team has made a machine hold a rhythm -> find that person now, because it is the failure nobody sees coming.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Take the one that loses on the fewest: five honest questions about your situation rather than about the software, with no scores attached. If your project keeps landing on one machine with a model in Python and a loop that must not wait for it, star HORUS on GitHub so it is in your list when you start building.