the bridge

CLI — The Bridge Between Agents and Robots

Agent-authored behavior. Robot-owned execution.

The agent authors behavior; the robot owns how that behavior actually runs. This talk walks the bridge between those two worlds — a CLI that lets intelligence reach a robot without ever touching the motors directly.

An agent hands an intent across a stable interface into a robotLeft to right, three zones tell one story. On the left, an intelligence — drawn as a small constellation of three linked, gently breathing nodes, the AgentCulture mesh mark — stands for any agent or model. In the centre, a tall lit pillar is the stable CLI interface: the boundary the hand-off must cross. On the right, a friendly robot with two antennas and a softly glowing head stands for any body. A trail of pulses flows from the intelligence, through the pillar, to the robot, and a single rounded intent token rests on the pillar's seam — the moment of hand-off. The intelligence and the robot are interchangeable; the interface between them is what stays fixed.
three paths, one gap

Intelligence reaches robots in different ways

  1. Coded behavior
  2. Learned policy
  3. Agent tools

What matters is a stable boundary.

Some robots run fixed, hand-coded behavior; others run a learned policy trained end to end; a growing set let an agent call tools directly against the hardware. These approaches can coexist. The architectural question is whether the robot exposes a stable boundary between what intelligence decides and what robot software executes.

the architecture

Keep execution below the model

The agent never owns the motors.

The stack has five layers: an optional agent, a stable CLI, a deterministic behavior runtime — on Reachy Mini, a fixed-rate loop at a 50 Hz design rate — a device daemon, and the hardware itself. Reasoning stays above the CLI line; execution stays below it, in the runtime and daemon, so the model can be interchangeable without ever owning the motors.

A CLI for intelligence, a runtime for embodiment: the five-layer robot architecture Five layers, drawn top to bottom. At the top, two replaceable entry points feed the same control plane: an optional agent harness — Claude Code, Codex, Colleague, a custom agent, or none, drawn with a dashed border — and a human, shell script, or CI system. Both connect straight down into the robot interface, the control plane, whose surfaces are the CLI, the JSON feed, and the intent spool; the CLI inspects, configures, intervenes, and reports through JSON contracts. The interface and the layer below it, the behavior runtime, carry the strongest visual weight in this diagram. The CLI sends lifecycle, configuration, and direct operations down into the behavior runtime — ROS-backed or native, persistent execution that runs nodes, controllers, rules, intents, and arbitration. The CLI also has a direct, required path straight down to the device layer, for one-shot device operations that bypass the runtime entirely. The behavior runtime sends validated, arbitrated actions down to the device daemon or hardware adapter, which exchanges state and actuation with the physical robot at the bottom — Reachy Mini, SO-ARM101, or a future body, drawn replaceable like the agent above it. Two dotted paths connect the agent and the runtime directly — the interface's non-CLI surfaces: the runtime emits its event feed up to the agent, and the agent submits named intents back down to the runtime through attach and spool. CLI ; HUMAN --> CLI -->|"lifecycle · configuration · direct operations"| RUNTIME -->lifecycle · configuration · direct operations|"one-shot device operations"| DEVICE — required direct-intervention path -->one-shot device operations|"validated and arbitrated actions"| DEVICE -->validated, arbitrated actions|"state and actuation"| ROBOT -->state and actuationruntime event feednamed intents via attach/spool
Solid lines show operational command and state paths; the CLI's direct line to the device layer is a required one-shot path that bypasses the runtime. Dotted lines are the optional runtime event feed and named-intent path an attached agent can use instead.
opening the runtime

Open the runtime to coder agents

Reachy Mini in close-up mid-gesture, its head tilted up and back on a jointed metal neck and its two antennas angled out, the pair of dark camera lenses reflecting the room, against a warm interior softly out of focus.
Configure behavior
Command ad hoc
Observe and repair

The agent maintains the automation. The runtime executes it.

A coder agent doesn't just call the robot once — it can configure the behavior runtime's rules, issue ad hoc commands outside those rules, and observe the runtime's own feed to repair or extend automation over time. Reachy Mini's CLI opens all three surfaces the same way a human operator would use them.

beyond the agent

The robot continues without the agent

  • Stuck: the robot is blocked at an obstacle, and the agent link is active — the mind inspecting and adaptingOn the left, a lit agent chip is fully attached — the connection to it is drawn as a bright, solid line with a pulse of attention travelling down it toward the robot. On the right, the robot has come up against a solid barrier and stopped, while probing scan arcs sweep across the obstacle: this is where the agent earns its keep — the mind inspects the blocked state and adapts the plan.

    Stuckinspect and adapt

  • Disconnected: the link to the agent is severed, and the robot's behavior continuesOn the left, a dimmed agent chip is cut off — the connection to it is drawn as a broken, dashed line with a clear gap and a small spark at the break. On the right, the robot is fully lit and active, wrapped in a glowing runtime loop that keeps turning: its behavior continues without any agent attached.

    Disconnectedbehavior continues

  • Routine: the robot runs steady, cyclic operation with no model attachedAn empty, dashed agent slot marks that no model is attached. The robot runs a steady cycle, wrapped in a slowly turning loop arrow, above a regular, even heartbeat line — steady, routine operation that needs no model.

    Routine operationno model required

Spend intelligence on change—not repetition.

When the robot gets stuck, an agent can inspect the state and adapt the plan — that's exactly where intelligence earns its keep. When the agent disconnects, the behavior runtime keeps running unattended; during routine operation, no model is in the loop at all.

the direction

Two robots, one direction

Reachy Mini, a small white desk robot with a rounded movable head and a pair of dark camera lenses, facing the viewer on a wooden table, its two thin antennas rising out of the top of the frame and a marble fireplace blurred behind it.

Reachy Mini

working system

Rules · behavior runtime · device daemon

The complete native-runtime pattern.

reachy-mini-cli behavior engine run
The SO-ARM101 robot arm in side profile on a white surface, its black 3D-printed segments raised and reaching forward, its two-finger gripper open with one white jaw and one black jaw, against a plain pale backdrop.

SO-ARM101

in progress

JSON · preview/apply · bounded motion

Building the operational contract first; persistent behavior comes next.

arm101 arm flex --apply

A CLI for intelligence. A runtime for embodiment.

the trajectory

What's next: See. Remember. Act.

  • See
  • Remember
  • Act

Reachy Mini

Give presence understanding and history.

Semantic vision · embodied memory · behavior informed by experience

SO-ARM101

Apply the same autonomy pattern to manipulation.

Persistent runtime · reachability memory · load-aware rules · supervised recovery

agent authors and supervisesruntime persists and arbitratesbody retains control

The same architecture, expressed through a different body.

Reachy already has an autonomous presence. Next, it should understand more of what it sees and retain useful memory of people, objects, events, and its environment. ARM101 already has the beginning of a safe operational language: observable state, guarded motion, overload sensing, and reachability exploration. Next, it gets the same persistent sense–rule–intent runtime—adapted for manipulation rather than expression. First, we gave an expressive robot an agent-maintainable presence. Next, we give that presence memory—and give a robotic arm the same autonomy.