Autona Machines
Humanoids in homes.
Humanoids in Homes
A useful home robot does not need superintelligence. It needs basic reasoning, which frontier models already provide, and reliable manipulation of a bounded set of chores, which current models can deliver. The missing piece is not research. It is a company that puts those parts together into a machine a household can live with.
The market is enormous: hundreds of millions of households already pay for this work, either in their own evenings or in help they struggle to find. A machine that keeps the house clean, moves the laundry, and lets an ageing parent stay home longer is worth real money to every one of them. That market goes to whoever ships a machine people trust, not whoever publishes the best demo.
Everything below follows from that. We measure ourselves on one thing: how fast a chore no robot has been taught becomes a chore that works in a stranger's kitchen.
◊ ◊ ◊
Technical Thesis
Most of the field is scaling one end-to-end model until it generalises. We build the architecture around the model instead: the runtime layer that makes a machine trustworthy on its four-hundredth attempt, in a room we have never seen.
Claude Code did not make the underlying model better. It wrapped an API call in a loop that could read files, run commands, check the result and try again, and that turned a chat model into something that ships software. We are building that wrapper for robots. The harness holds the mission, decides what to try, calls a tool, reads the result, and decides what to do next. The policy is a hand, not the brain.
Most of the industry bets everything on one end-to-end model: if the VLA cannot do a chore, the company cannot do the chore. We give the harness a toolkit instead: a learned policy for motion it has been trained on, and primitives, perception, verification, or a short program written on the spot for everything else. Steering a VLA is hard. Steering a frontier model that can call tools and write code works today.
The driver of the harness is the frontier LLM itself, and out of the box it already performs on par with frontier VLAs. Berkeley's Maestro matched or beat state-of-the-art VLAs zero-shot with a coding agent composing robotics modules, no robot-specific training, calling a VLA as one of its own tools and cutting long-horizon task time 2.3×. Every frontier release raises that floor before we train anything.
The field is converging on this shape. Robotics Harness Optimization, Harness VLA and demonstration-free agent frameworks report the same finding: orchestration, not tool availability, is the bottleneck.
◊ ◊ ◊
The Harness, Implemented
The thesis above, as built: a runtime cycle that predicts before it acts, six components around one trained model, and every tool behind a single guard.
Six components, one model we train
A frontier LLM as the navigation engine
A frontier model we did not train and do not intend to. It decides what to attempt, in what order, with which tool, and what to do when an attempt fails. We are not competing with the labs on reasoning; we are pointing it at a kitchen.
NOT FINE-TUNED · NOT OURS TO TRAIN · SWAPPABLE BEHIND ONE INTERFACE · EVERY FRONTIER RELEASE UPGRADES THE ROBOT WITHOUT US SHIPPING A MODEL
An internal monologue, written down
Before and during every action, the operator writes down what it believes about the room, what it intends to do, and why. That transcript makes failures debuggable, gives customers an answer when they ask what happened, and tells us what the loop should train next.
BELIEF, INTENT AND JUSTIFICATION AS TEXT · REPLAYABLE PER MISSION · AN AUDIT TRAIL, NOT A CHAIN-OF-THOUGHT PARLOUR TRICK
An internal action and prediction loop
Before it moves, the machine commits to a prediction: this object ends up here, nothing else changes. Then it checks the world against it. A mismatch is caught in the moment, not discovered by a person later. This is what makes failing gracefully possible: an uncertain grasp abandoned before the lift, a partial chore restored, a failure announced out loud.
PREDICT → ACT → OBSERVE → COMPARE · SCENE DIFF AS EVIDENCE · NON-TARGET OBJECTS SCORED TOO · THE ROBOT FINDS ITS OWN FAILURES
Localised contextual mapping
A persistent model of your home: where things live, what this household calls them, which surfaces are fragile, which door sticks. Asked once, remembered permanently. The machine gets measurably better in your house specifically, and a competitor arriving later starts from nothing.
PER-HOME, PERSISTENT, ALWAYS ACCUMULATING · NAMED OBJECTS STAY NAMED · THE LONGER IT LIVES THERE, THE BETTER IT IS THERE
Our own VLA policies, as the muscle
The one model we do train, and the only learned component on the control path. It does one job well: smooth, fast, contact-rich motion on chores it has seen. Planning, unfamiliar language, and deciding when to give up belong to the harness.
FINE-TUNED PER EMBODIMENT AND PER CHORE · CLOSED LOOP AT 25 HZ · THE FASTEST TOOL, NOT THE DECISION MAKER
One toolkit, one guard
Everything above is exposed to the engine as a tool, and every tool resolves through one guarded interface. Learned or written, a command is range-checked, rate-limited and preemptible before it reaches a joint. We can add a capability without adding a risk.
UNIFORM TOOL INTERFACE · LIMITS AND RATES ENFORCED BELOW THE MODEL · PREEMPTION AT SAFE BOUNDARIES · NO MODEL OWNS A SAFETY FUNCTION
The toolkit
| Tool | What it is | When the engine reaches for it |
|---|---|---|
| VLA policy | The learned visuomotor policy trained in the deployment loop, closed-loop at 25 Hz | Contact-rich motion it was trained on, where smoothness and speed matter |
| Grasp and motion primitives | Analytic IK, planned reach, transport, place, retreat | Known geometry, tight tolerance, no demonstrations yet |
| Perception queries | Detect, locate and describe what is on the surface | Binding a noun in a sentence to an object in the room |
| Verification | Scene diff and camera read-back after every action | Checking whether the last action worked, every time |
| Code the engine writes | A short program composing the four above | A chore with no trained policy and no script |
◊ ◊ ◊
New Skill Deployment Loop
The pipeline at the core of the company, running end to end today on real robot geometry and real data conventions.
Generate a small sample set
A small seed of demonstrations, not a large dataset. It only has to be good enough to be worth multiplying; stage 03 makes it big. Three ways to get one, whichever is cheapest for the chore:
- Imagine it. A model generates the demonstration as video; joint trajectories are recovered from the frames.
- Record it. A handful of real demonstrations on ordinary video. No mocap, no teleop rig.
- Solve it. Build the scene in simulation and synthesise trajectories with inverse kinematics (IK).
THREE ROUTES, ONE OUTPUT: JOINT TRAJECTORIES · GENERATED VIDEO · REAL VIDEO · SIM AND IK · TENS OF EXAMPLES, NOT THOUSANDS
Seed a small dataset in simulation
Rebuild the task in sim on the real arm's geometry, inertials and gains, and replay the trajectories as a task-parameterised expert. Output: a small, clean dataset in the exact format real hardware produces.
REAL ROBOT MODEL, MESHES AND CONTROLLER GAINS · GRAVITY COMPENSATION PER PHYSICS STEP · 14-DIM STATE/ACTION · BYTE-COMPATIBLE WITH REAL ROBOT DATASETS
Explode it into thousands of variations
One seeded task becomes a large corpus: randomised layouts, cameras, lighting, colours, friction and bin positions, plus many phrasings of the same instruction. Deliberate failures are injected with the expert's recovery attached, so the policy learns what to do after a missed grasp.
DOMAIN RANDOMISATION · HELD-OUT PROMPT PHRASINGS · IN-DISTRIBUTION AND OUT-OF-DISTRIBUTION PROFILES · A QUARTER OF EPISODES ARE RECOVERY EPISODES · SUCCESS REQUIRES EVERY NON-TARGET OBJECT UNTOUCHED
Fine-tune the vision-language-action model
Adapt an open VLA backbone to this embodiment and chore library. Rented compute, one run, immutable checkpoints, and a training gate that refuses to start unless the dataset audit passes.
OPEN VLA BACKBONE · PER-EMBODIMENT FINE-TUNE · RENTED GPU, DESTROYED AFTER · SNAPSHOTS HASHED AND RETAINED · FAIL-CLOSED DATA AUDIT BEFORE STEP ZERO
Prove it in sim before anyone touches hardware
Every checkpoint runs locked, held-out protocols: unseen scene seeds, unseen phrasings, a stability hold after success so a lucky nudge does not count, and an out-of-distribution split that stays sealed until a winner is chosen on validation alone.
DETERMINISTIC SEEDS · HELD-OUT PROMPTS · POST-SUCCESS STABILITY HOLD · SEALED TEST SPLITS · CLEAN, RECOVERY AND NON-TARGET PRESERVATION SCORED SEPARATELY
Wrap it in an agent harness
An operator agent, driven by a frontier large language model (LLM), takes a mission in plain language, plans, watches the cameras, verifies what changed, and replans when something did not work. The LLM reasons; the robot moves. The agent is never on the control path.
The fine-tuned policy from stage 04 is one tool in that harness, not the whole robot. The harness also holds grasp and motion primitives, perception queries, scene verification, and the ability to write a short program composing them. See section 03.
LLM PLANS AND VERIFIES · ROBOT OWNS THE 25 HZ LOOP · PREEMPTION AT SAFE BOUNDARIES · ACTION GUARD BEFORE EVERY COMMAND · THE VLA IS A TOOL, NOT THE ARCHITECTURE
Deploy and test on the real robot
Because the sim used real geometry and real conventions, the policy runs unchanged on hardware. Whatever breaks in a real house goes back to stage 01 as the next dataset.
SAME CONVENTIONS, NO REWRITE · NO REMOTE OPERATORS · NOTHING SCRIPTED FOR THE DEMO · REAL FAILURES BECOME TOMORROW'S TRAINING VARIATIONS
◊ ◊ ◊
What It Does Today
Two arms, six degrees of freedom each, three cameras, one policy, and an instruction typed in plain English. Everything here was made in days, entirely in software, with no robot hardware and no teleoperation:
- Demonstrations synthesised with inverse kinematics. No motion capture, no teleop rig.
- Dataset multiplied out from those seeds in simulation, on real arm geometry.
- Policy fine-tuned from a vision-language-action backbone on one rented GPU, then evaluated on a sealed protocol.
- Checkpoint loaded into the robot brain, the harness from section 03.
The clips show that pipeline working. Nothing is scripted at runtime: the policy sees pixels and a sentence, and outputs joint targets at 25 Hz. What matters is not the clips themselves but how fast the loop that produced them turns around, and that it turns around again next week.
Simulation on production arm geometry, inertials and controller gains. Camera views, state and action spaces match the physical robot so that policies and tooling transfer without modification. Clips are compressed for the web; they are otherwise unedited single rollouts.
◊ ◊ ◊
How We Operate Quickly
The operating principle: we should be able to change the machine, and teach it a new skill, faster than anybody else. So the whole stack, mechanical, electrical and evaluation, is built to be driven by agents. A design change is a diff. A new chore is a run of the loop. Neither waits behind an overloaded engineer.
| What agents drive | In-house software | What that buys us |
|---|---|---|
| Mechanical design | Autona Forge | A whole robot generated as code from a written specification, so a change is a diff and a variant is a parameter rather than a week in a modeller |
| Design exploration | Autona Scout | The design space is searchable. Propose reach, link-length and payload variants, evaluate them against the chore list, keep what survives |
| Current and power analysis | Autona Watt | Torque and duty-cycle budgets fall out of the design and are rechecked on every change, instead of being commissioned once and trusted forever |
| Product circuitry | Autona Trace | Schematic and board in the same loop as the mechanics, so moving a joint does not stall three weeks behind a handoff |
| Simulation and evaluation | Autona Gauntlet | Dataset collection, audits, per-checkpoint evaluation and release gating all run unattended. Nobody eyeballs a video and calls it progress |
| Robot brain | Autona Harness | The runtime brain from section 03, and the deployment loop from section 04, end to end. A new chore goes from a small sample set to a policy running on the robot in days, without a person babysitting it |
Generated by our agentic CAD pipeline from written specifications. No sketch plane was touched by a human.
◊ ◊ ◊
Why Speed Wins
Nokia sold half the phones on earth and lost the category inside a decade. The car companies that survived the 1920s won on process and consistency, not the best car. In this category, hardware is collapsing to the EV supply chain and manipulation models are becoming licensable, so neither is a moat. What remains is loop time, trust, service, and an installed base, all of which take years to build and cannot be bought.
Why us
If the category is decided on deployment, the question about a team is whether it has put machines in front of people who did not have to be polite about them. We are assembling operators: people who have designed, built, shipped and supported robots for a living, across different industries, and who have fixed a machine failing at a customer site by Friday. Getting a robot to work once is a research problem. Keeping a fleet working in places you do not control is an operational one, and far fewer people have done it.
This category will not be won by whoever is most capable in 2030. It will be won by whoever is already in the kitchen in 2027 and never leaves.Autona Machines
◊ ◊ ◊