Autona Machines · Demo & Progress · July 2026
The Loop, Working.
Not a roadmap. This is what exists today: each stage of our pipeline running end to end, producing a real fine-tuned policy from a handful of synthetic demonstrations.
Our Fine-Tuned Model, Running Inside the Robot Brain
Our own vision-language-action model, fine-tuned on our own synthetic data, running closed-loop at 25 Hz inside our robot brain harness alongside frontier LLMs. The VLA handles contact-rich motion. The LLM handles planning, verification, and recovery. Plain English instruction in, joint targets out.
◊ ◊ ◊
The VLA Is a Hand, Not a Brain
The rest of the industry is betting everything on one giant model. We are betting on the architecture around it. That is the difference, and it is why we can ship with a small, fast, cheap policy while others need a foundation-model-scale VLA to do the same job.
What most teams are building
The dominant approach treats the VLA as the entire robot. One end-to-end model receives pixels and language, and it must plan, reason about failure, decide when to stop, handle novel objects, recover from mistakes, and produce smooth joint targets. All of that in a single forward pass. The result is a model that needs to be enormous, needs billions of tokens of training data, needs months of compute, and still fails silently when it encounters something outside the distribution.
When that model fails, there is nothing else. The company waits for the next checkpoint.
What we are building instead
Our VLA does exactly one thing: fast, smooth, contact-rich motion on chores it has been trained on. It runs at 25 Hz and it is very good at that one job. But it does not plan. It does not reason. It does not decide when to give up. Those are the harness's job.
A frontier LLM that plans the mission, predicts what should change, verifies what actually changed, recovers from mismatches, and reports failures honestly. It has five tools at its disposal:
The VLA is one tool out of five. When it has been trained on a chore, the harness calls it because it is the fastest, smoothest option. When it has not been trained yet, the harness reaches for analytic primitives, perception, and code it writes on the spot. The chore still gets done. And those runs generate the trajectories that train the policy for next time.
Why this matters
| The giant-VLA approach | The harness approach (ours) |
|---|---|
| Model must plan, reason, recover, and control | Model only controls. Planning and recovery are the LLM's job |
| Needs billions of tokens and months of compute | Fine-tune on our own sim data in hours, on one GPU |
| Silent failures: model does not know it failed | Predict-observe-compare catches every failure at runtime |
| New chore requires a new training run | New chore often requires only a new tool or a few lines of code |
| Every frontier LLM release is irrelevant to the robot | Every frontier LLM release upgrades the robot for free |
| No path to a chore the model was never trained on | The harness can compose primitives and code for any chore from day one |
| Reliability requires a better model | Reliability is produced by the architecture, not waited for from the model |
Claude Code did not make the underlying model better. It wrapped a single API call in a loop that could read files, run commands, look at what happened and try again. That wrapper is what turned a chat model into something that ships software. We are doing that for robots.The harness insight
What this buys us concretely
- We do not need a nine-figure pretraining budget. Our model is small, fast, and cheap to train because it only handles contact-rich motion. The hard reasoning work is done by a frontier LLM we did not build and do not maintain.
- We ship chores before we train policies for them. The harness can compose primitives and write code for a chore nobody has trained a model on. That means we are deploying from week one, not waiting for the data flywheel to spin up.
- Every frontier model release is a free upgrade. When Claude or GPT improves, our robot gets better at planning, reasoning, and recovery without us touching a single weight. Teams that bet everything on their own model get none of that.
- Failures are caught, not hidden. The predict-observe-compare loop means the robot knows when something went wrong. It does not need to be right every time. It needs to detect when it is wrong, and that is an architectural property, not a model property.
◊ ◊ ◊
What We Have Built
Every item below is shipped, running, and producing output. This is not a feature list of intentions. It is a changelog of things that work, with evidence attached.
Simulation environment on real robot geometry
Full MuJoCo simulation of our dual-arm system with production URDF, meshes, inertials, and controller gains. Gravity compensation runs per physics step. State and action spaces are byte-compatible with real hardware, so nothing trained here requires a rewrite to deploy.
14-DOF state/action · Real meshes · Real gains · Camera rendering at 640x360
Automated dataset generation pipeline
From a small seed of IK-synthesised trajectories, the pipeline explodes a task into thousands of randomised episodes: varied object layouts, camera angles, lighting, colours, friction, bin positions, and instruction phrasings. A quarter of all episodes are deliberate failure-recovery pairs.
Domain randomisation · Held-out prompt phrasings · Recovery episodes at 25% · Non-target preservation scoring
VLA fine-tuning on our own data
An open vision-language-action backbone, adapted to our embodiment and our chore library. Trained on rented GPU from our own synthetic datasets, with immutable checkpoints at fixed intervals and a training gate that refuses to begin unless the dataset audit passes.
Open VLA backbone · Per-embodiment fine-tune · Fail-closed data audit · Hashed checkpoint retention
Sealed evaluation protocol
Every checkpoint runs against locked, held-out test splits: unseen scene seeds, unseen instruction phrasings, a stability hold after success, and an out-of-distribution set that stays sealed until validation chooses a winner. Clean runs, recovery runs, and non-target preservation are scored independently.
Deterministic seeds · Post-success stability hold · Separate clean/recovery/preservation scores · OOD split sealed
Agent harness with frontier LLM
The operator agent takes a mission in plain language, plans the approach, calls tools (including the VLA), watches the cameras, verifies results against predictions, and replans on mismatch. The LLM reasons; the robot moves. The agent is never on the 25 Hz control path.
Frontier LLM navigation · Predict-act-observe-compare loop · Tool-based architecture · Action guard on every command
Agentic CAD pipeline (Modbot)
A whole robot generated as code from a written specification. Changes are diffs, variants are parameters, and no sketch plane is touched by a human. The same agents that run the software loop run the mechanical loop.
Full humanoid from spec · Gripper, joint drive, variant generation · Agent-driven · Zero manual CAD
Sim-to-real transfer on physical hardware
The final step: the same checkpoint that passes evaluation in simulation, loaded onto the physical arm with no modifications. Because the simulation uses real geometry, real gains, and byte-compatible data conventions, the transfer requires no rewrite. Currently commissioning hardware for first deployment trials.
Same conventions, no rewrite · No remote operators · Real failure data feeds back to stage 01
Expanding the chore library
Once the first task family transfers cleanly, the loop turns again. Each new chore goes from a small sample set to a deployed, evaluated policy in days. The pipeline is the product; the chore list is what it outputs.
◊ ◊ ◊
The Flow in Detail
Each stage of the loop, with the specific decisions and tools that make it fast.
Sample
What happens
We generate the smallest credible seed for a new task. For the demos above, we used inverse kinematics: build the scene in simulation, define waypoints, and let the solver produce smooth joint trajectories. No hardware, no teleop rig, no motion capture stage.
Why this is fast
A handful of IK solutions take minutes to generate. They do not need to be perfect. They need to be good enough to be worth multiplying, because stage 03 is what makes them large.
Output
Tens of joint-space trajectories in the exact format real hardware produces. Byte-compatible from day one.
Seed
What happens
Those trajectories are loaded into MuJoCo on the production URDF: real meshes, real inertials, real controller gains, gravity compensation per physics step. The result is a small, clean, controllable dataset that behaves like real hardware data.
Why this is fast
The sim environment is pre-built for our arm geometry. Loading a new task is parameterising an existing scaffold, not building from scratch.
Output
A validated seed dataset: state, action, image, and language, all at 14-DOF and 640x360 camera resolution.
Multiply
What happens
The seed becomes thousands of variations. Object positions, camera poses, lighting, colours, friction, bin locations, and instruction phrasings are all randomised. A quarter of episodes are deliberately injected failures with recovery trajectories attached, so the policy learns what to do after a dropped grasp.
Why this is fast
Randomisation is automated and parallelised. Once the seed validates, the expansion runs unattended overnight. No human labels anything.
Output
A large training corpus with in-distribution and OOD splits, held-out prompt phrasings, and explicit recovery data. Ready for fine-tuning.
Train
What happens
An open VLA backbone is fine-tuned on the expanded dataset. Rented compute, one run, immutable checkpoints at fixed intervals. A fail-closed gate audits the dataset before step zero: if provenance or format checks fail, training never begins.
Why this is fast
We are fine-tuning, not pretraining. The backbone already understands vision and language; we are teaching it our embodiment and our chores. A single GPU run, hours not weeks.
Output
A series of hashed, immutable checkpoints ready for evaluation.
Prove
What happens
Every checkpoint is scored on locked evaluation protocols: deterministic seeds the training never saw, held-out phrasings of the instruction, a post-success stability hold, and a sealed OOD split. Clean completion, recovery, and non-target preservation are scored separately.
Why this is fast
Evaluation is automated and deterministic. Nobody watches a video and calls it good. The protocol runs, the numbers come back, the best checkpoint is selected on validation alone.
Output
A single winning checkpoint with quantified performance across every metric, and a sealed test score that was never used to select it.
Harness
What happens
The winning checkpoint is loaded into the agent harness as one tool among five. The frontier LLM takes a mission, plans the attack, calls the VLA for contact-rich motion, uses analytic primitives where no training data exists, verifies every action against a prediction, and replans on mismatch.
Why this is fast
The harness is already built. Adding a new policy is registering a new tool. The reasoning, planning, and verification infrastructure does not change per chore.
Output
A deployable skill: a policy wrapped in verification, recovery, and plain-language reporting, ready for hardware.
Deploy
What happens
Because simulation used real geometry and real data conventions, the command that trained on simulated episodes runs unchanged on hardware. What breaks in the real world is the most valuable data we own, and it feeds directly back to stage 01.
Why this is fast
No sim-to-real rewrite. No domain adaptation stage. No gap to bridge. The data format is the bridge, and it was built that way from the start.
Output
A robot performing the chore in the real world, with every failure becoming tomorrow's training variation.
◊ ◊ ◊
Concrete Metrics
Not aspirations. Measurements from the system as it runs today.
| Metric | Value | Why it matters |
|---|---|---|
| Loop time: seed to evaluated policy | Days | Not weeks, not quarters. A new chore can be trained and proven in the time it takes most teams to collect demonstrations |
| Human teleop data required | Zero | IK-synthesised seeds, simulation-expanded datasets. No teleoperation rig, no motion capture, no labelling team |
| Control frequency | 25 Hz | Smooth, contact-rich manipulation. Fast enough for dynamic grasping, slow enough for safe guard intervention |
| State/action dimensionality | 14-DOF | Six joints per arm plus grippers. Byte-compatible between sim and real |
| Recovery episodes in training | 25% | The policy does not only know how to succeed. It knows what to do after a failure, because we trained it that way |
| Evaluation protocol | Sealed, deterministic | Unseen seeds, unseen phrasings, stability hold, OOD split. No cherry-picking, no eyeballing |
| Remote human operators | Zero | The machine detects its own failures and reports them. No one in another country is quietly driving it |
◊ ◊ ◊
See It Yourself
We will walk you through the full evaluation protocol, play back any checkpoint, show the dataset provenance, and demonstrate the harness reasoning in real time. Nothing is behind a curtain.