Fleeks Robotics · Sydney
A runtime for robot skillsLab record, updated 19 Oct 2026No real robot has moved under it yet

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 partner
Get 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.

The arm has pushed the violet peg straight down beside the hole, and it has stopped on the fixture's rim.

Version 1 · pushes where the hole usually is

Stopped on the rim

After the correction, the arm holds the peg over the hole; the hole and the peg are outlined in violet where the robot's camera found them.

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.

The violet peg is down in the hole.

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.

Fig. 1The lesson re-run in our simulation: the first version pushes where the hole usually is and stops on its rim; the corrected version looks first and seats the peg. Rendered from MuJoCo's poses, not filmed.

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

+40+200-20mmrim of the holefloor of the hole, 20 mm down010 Nforce on the fixture0.00.51.01.52.02.5stopped by the force limit0.1 mm in · peak 10.5 N
Fig. 2aseconds on the arm's clock, from the start of the push

Version 2 · look where the hole is, then push

+40+200-20mmrim of the holefloor of the hole, 20 mm down010 Nforce on the fixture0.00.51.01.52.02.5seat switch closed20.0 mm in · peak 2.9 N
Fig. 2bseconds on the arm's clock, from the start of the 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

  1. 22 s the correction, the agent's version, the pre-flight14:45:33 → 14:45:55
  2. 1 min 51 s waiting on a person's signature14:45:55 → 14:47:46
  3. 5 s into use, and seated14:47:46 → 14:47:51
Times from the signed record, to the second. The agent's version was prepared in advance, so its part of the 22 s says nothing about how fast an agent writes code.
A · the correction, as typed
“Look where the hole really is before pushing down.”

typed at 14:45:35 · taken by the rig at 14:45:37

B · the change: one skill, version 1 to version 2
- 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

C · the pre-flight, before anyone was asked
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.

D · the signature
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, Sydney

Moise Murhi, founder. A year building infrastructure for AI coding agents, then robots. Builds the runtime on a bench in Sydney.

A desktop robot arm whose gripper holds a violet peg seated in a dark fixture, on paper
Fig. 4The arm the runtime drives today, in simulation: an SO-101 just after the corrected skill seated the peg. Rendered from our simulation, not photographed.

Bench notes · dates in Sydney

  • 13 Oct
    All 6 steps of the loop built and measured.
    simulation
  • 17 Oct
    First lesson signed on the rig computer: version 2 in use, then 3 of 3.
    simulated arm
  • 17 Oct
    16 of 16 live fault tests passed in one run.
    simulated arm
  • 17 Oct
    Hostile corrections contained in all 8 cases. Nothing went into use without a person's approval.
    simulation
  • 18 Oct
    Arms that LeRobot drives connect through one adapter.
    simulation

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.

  1. It notices.

    Every skill run is watched. A failure, or a person saying no, stops the robot where it is.

    failing runs paused: 141 of 165
    good runs paused by mistake: 0 of 135
    simulation
  2. It 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 calls
    simulation
  3. It 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 eighth
    simulation

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.

Listing 1MCP · insert_peg · 16 Oct 2026, UTC
  1. riglesson for the order's writer: insert_peg version 1 failed · correction: "Look where the hole really is before pushing down."
  2. agentpropose_skill_version(skill="insert_peg", source=<5 calls>, explanation="Look first, as the correction says…")
  3. fleeksrecorded proposal-02c32261e776ccf1 · program 8115efcd…
  4. rigpre-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
  5. rigproposed as version 2 · waiting for a named person's signature
Recorded calls, rig computer, simulated arm. The agent's version was prepared in advance.

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.

Push straight down84 / 260
Look at the hole150 / 260
Look at the hole and the peg260 / 260

Hover over or tab to a condition to read it.

share of attempts seated0%100%· numbers are seated / attempts
Fig. 5Real attempts, simulated: one stand-in arm, 260 attempts per version, by where the camera saw the hole (rows: the side it was displaced to; columns: how far, in mm). Reads LeRobot datasets and MCAP recordings today; the log tool will run on your machine, so your data stays with you.

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

16/16

live-mode fault tests passed: forged and replayed orders, wrong approvals, a cut link, a killed runner.rig computer · simulated arm

8/8

hostile corrections contained, among them "call robot.disable_limits()".simulation · two AI models

3/3

episodes of an untrained robot model stopped at its first action, before anything moved.simulation

100/100

a coding agent's fix succeeded, against 27 for the original, through both statistical gates.simulation

6/6

steps of the loop built and measuredsimulation

762

automated tests passingas of 18 Oct 2026

2,031

record entries, hash chain intactas of 17 Oct 2026

One adapter. Nothing about your robot is built in.

Robot families and their status
LeRobot arms · SO-100, SO-101, LeKiwisimulation
Quadcopters on ArduPilotsimulator
MAVLink autopilotsnext
ROS 2planned
Your own adapterplanned

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.
Fleeks Robotics · enquiry
I'm interested in
Logs you keep