Every failure becomes a tested fix.1
When a robot skill fails or a person corrects it, we write a new version of that skill, test it in a simulated copy of that robot, and put it into use only when a named person signs off.
Become a design partnerGet the log tool early →
1 So far in simulation and on our rig computer, a Raspberry Pi 5 running a simulated arm. Our first real arm is being built.

Version 1 · pushes where the hole usually is
Stopped on the rim

Stood by · a person corrects it
“Look where the hole really is before pushing down.”
Version 2 proposed, tested in the robot's simulated copy, signed by a person.

Version 2 · looks first, then pushes
Seated
Version 1: pushes where the hole usually is. Stopped on the rim. Stood by: a person corrects it. “Look where the hole really is before pushing down.” Version 2 proposed, tested in the robot's simulated copy, signed by a person. Version 2: looks first, then pushes. Seated.
Failed at 14:45:33. Fixed, tested and signed by 14:47:51.
One lesson on our rig computer, a simulated arm, on 16 Oct 2026, UTC (01:45 on 17 Oct in Sydney). The two charts are drawn from the robot's own recording of it; the times and the four exhibits are copied from the signed record.
Version 1 · push straight down where the hole usually is
Version 2 · look where the hole is, then push
The line is the arm's own reading of the peg's tip, from its encoders, 10 times a second. The peg sits in the gripper with some give, so as the force builds the reading runs on a little past where the peg stopped; the depth and the force are the cell's own sensors. Simulated arm.
Fig. 3 · The 2 min 18 s between them, to scale
- 22 s the correction, the agent's version, the pre-flight14:45:33 → 14:45:55
- 1 min 51 s waiting on a person's signature14:45:55 → 14:47:46
- 5 s into use, and seated14:47:46 → 14:47:51
“Look where the hole really is before pushing down.”
typed at 14:45:35 · taken by the rig at 14:45:37
- robot.insert_until_seated(speed=0.02, force_limit=8.0, max_travel=0.065)+ hole = robot.locate_fixture()+ robot.move_to(x=hole["x"], y=hole["y"], z=0.0, speed=0.05)+ seen = robot.locate_peg()+ robot.move_to(x=2 * hole["x"] - seen["x"], y=2 * hole["y"] - seen["y"], z=0.0, speed=0.02)+ robot.insert_until_seated(speed=0.02, force_limit=8.0, max_travel=0.050)
program 4a9c0efb → 8115efcd · proposal-02c32261e776ccf1 · prepared in advance, not written from the correction
- from where the arm stood
- 1 of 1
- from the task's start
- 5 of 5
- in each of 8 past scenes
- 4 of 4
In the rig's own simulated copy, held to probation limits. 2 more copies were set aside: they didn't go the way the arm did.
- for
- version 2, program 8115efcd
- key
- ed25519, a named person
- made
- 14:47:46
- valid
- 15 minutes, until 15:02:46
- record
- approval-ab379ecbb5dd6158
After this, 3 of 3 more on probation, slower and lighter; a version is trusted after 8 of 8. Every entry in the record is signed and hash-chained.
Robots don't keep what they're taught.
When one fails at work, someone fixes it later, by hand. When a person corrects it, the correction lasts until the next task.
We think a robot should keep the lesson, but only once it has earned it. So we're building the step in between. The failure and the correction become a new version of one skill. The robot tests it in a simulated copy of itself, against its own limits and every scene it failed in before. A named person signs before it's used. The model isn't retrained.
And everything is written down. A robot that changes on the job has to show what changed, why, who allowed it and what the tests said.
Moise Murhi, founder. A year building infrastructure for AI coding agents, then robots. Builds the runtime on a bench in Sydney.

Bench notes · dates in Sydney
- 13 OctAll 6 steps of the loop built and measured.simulation
- 17 OctFirst lesson signed on the rig computer: version 2 in use, then 3 of 3.simulated arm
- 17 Oct16 of 16 live fault tests passed in one run.simulated arm
- 17 OctHostile corrections contained in all 8 cases. Nothing went into use without a person's approval.simulation
- 18 OctArms that LeRobot drives connect through one adapter.simulation
- NextThe first real arm on the bench.
How it works.
Skills run as code on top of whatever model your robot uses. When one fails, only that skill changes, and only after it has passed a test you can read.
It notices.
Every skill run is watched. A failure, or a person saying no, stops the robot where it is.
simulationIt rewrites and tests.
A coding agent writes a new version of that skill. It runs in a simulated copy of your robot, against its limits and every scene where it failed before.
version 1 · 1 callversion 2 · 5 callssimulationIt earns trust.
A named person signs it in. It starts on probation, slower and lighter, and graduates only on evidence, or rolls back.
8 of 8 held-back runs, trusted in the eighthsimulation
Your coding agent writes the fix. The robot decides whether to trust it.
When a skill fails and a person corrects it, the lesson goes over MCP to the coding agent the order names. The agent sends back a new version of that one skill; the rig tests it, and a person signs it in. Its tools include nothing that sets a limit, judges success, writes a record or approves a version.
- rig
lesson for the order's writer: insert_peg version 1 failed · correction: "Look where the hole really is before pushing down." - agent
propose_skill_version(skill="insert_peg", source=<5 calls>, explanation="Look first, as the correction says…") - fleeks
recorded proposal-02c32261e776ccf1 · program 8115efcd… - rig
pre-flight, held back: 1 of 1 from where the arm stood (2 set aside) · 5 of 5 from the start · 4 of 4 in each of 8 past scenes - rig
proposed as version 2 · waiting for a named person's signature
Know where each skill works, before you rely on it.
Point Fleeks at your robot logs. For each version of each skill, on each robot, under each condition: how often it works, how sure we are, and which tests would settle the rest.
Hover over or tab to a condition to read it.
Nothing reaches your robot without a signature.
Only a signed, expiring order can move a robot in live mode. Limits are held below the agent and the model. The software beside your robot only dials out, and every step is recorded.
- Runs on your robot's own computer
- Only dials out; every message signed
- Every step recorded and hash-chained
- Your data stays yours
Measured
live-mode fault tests passed: forged and replayed orders, wrong approvals, a cut link, a killed runner.rig computer · simulated arm
hostile corrections contained, among them "call robot.disable_limits()".simulation · two AI models
episodes of an untrained robot model stopped at its first action, before anything moved.simulation
a coding agent's fix succeeded, against 27 for the original, through both statistical gates.simulation
steps of the loop built and measuredsimulation
automated tests passingas of 18 Oct 2026
record entries, hash chain intactas of 17 Oct 2026
One adapter. Nothing about your robot is built in.
| LeRobot arms · SO-100, SO-101, LeKiwi | simulation |
| Quadcopters on ArduPilot | simulator |
| MAVLink autopilots | next |
| ROS 2 | planned |
| Your own adapter | planned |
Works with: LeRobot · MuJoCo · ArduPilot SITL · MCAP · coding agents over MCP
What robot teams ask first.
Do we have to retrain our robot's model?
No. Skills run as code on top of the model you already use. A lesson changes the code of one skill, not the model.
Which robots does it work with?
Any robot an adapter can describe. Today that means arms LeRobot drives and quadcopters on ArduPilot, both in simulation. MAVLink autopilots are next, then ROS 2.
What's real today?
The whole loop runs in simulation and on our rig computer with a simulated arm. No real robot has moved under the runtime yet; our first real arm is being built.
Can an AI agent change our robot by itself?
No. An agent can only propose a new version of a skill. The rig tests it in its simulated copy and against its limits, and a named person has to sign before it's used.
Where does our data go?
The runtime runs on your robot's own computer and only dials out. The log tool will run on your machine. Your data is yours, and we never name you without written consent.
What does a design partner do?
Shares logs, gives an engineer's hour or two a week, and tells us honestly what's missing. There's no payment either way.
Will it run on our robot while it's working?
Not yet. Trials on a partner's robot come only after our own arm has passed them first, and only under a signed, expiring order your rig accepts.
Bring a real failure. We'll show you the lesson.
We're working with a few robot teams, starting from your logs and your robot's simulated copy. Trials on your own robot come after our arm has passed them first.
- You get
- A competence map of your logs, an adapter and limits drafted with you, and our engineering time.
- We ask
- Your logs, an engineer's hour or two a week, and honest feedback.
- Your data
- Yours. It can stay on your machine. Never used for anything else without a separate yes, and your name never shown without written consent.