Autona Machines · July 2026
Humanoids in homes.
We are building the agentic software that teaches robots new skills in days, and the mechanical factory that designs the robots themselves.
Homes, Not Demos
The technology for making robots genuinely useful is here now. It does not need superintelligence. It needs simple reasoning, which frontier models already supply, and the ability to manipulate the world reliably, which is exactly what current manipulation models deliver when they are pointed at a bounded set of chores. Nothing fundamental is missing anymore. What is missing is the company that assembles those pieces into a machine a household can actually live with. We are building that.
The prize is one of the largest markets that has ever existed: hundreds of millions of households, every one of them already paying for this work in hours of their own evenings or in labour they cannot reliably staff. A machine that keeps the house clean, moves the laundry, clears the counters, and lets an ageing parent stay in their own home for years longer is worth a meaningful fraction of a household's income, in every household, forever. That is a market measured in trillions, and it goes to whoever ships a machine people trust, not to whoever publishes the most capable demo.
Every decision below follows from that. The measure of the company is not what our best clip looks like. It is how fast we can turn a chore nobody has taught a robot into a chore that works in a stranger's kitchen.
◊ ◊ ◊
The Loop
This is the whole company. Not a diagram of an aspiration: the pipeline we run, end to end, on real robot geometry with real robot conventions.
Generate a small sample set
Everyone else optimises for data volume. We optimise for the smallest credible seed, and there are three ways to get one. We use whichever is cheapest for the chore in front of us.
- Imagine it. Have a model generate the demonstration as video, then recover joint trajectories from the frames.
- Record it. A handful of real demonstrations on ordinary video. No motion-capture stage, no teleoperation rig.
- Solve it. Build the scene in simulation and use inverse kinematics (IK) to synthesise the trajectories directly.
None of the three has to be big, because stage 03 is what makes it big. The seed only has to be good enough to be worth multiplying.
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, then reproduce those trajectories as a task-parameterised expert. The result is a small, clean, controllable 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
This is where the leverage is. One seeded task becomes a large corpus: randomised object layouts, cameras, lighting, colours, friction and bin positions; many phrasings of the same instruction; and deliberately injected failures with the expert's recovery attached, so the policy learns what to do after a missed grasp instead of only how to succeed cleanly.
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 this chore library. Rented compute, one run, immutable checkpoints at fixed intervals, 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 is evaluated on locked, held-out protocols: unseen scene seeds, unseen phrasings of the instruction, 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
A policy is not a product. An operator agent, driven by a frontier large language model (LLM), takes a mission in plain language, decides how to attack it, watches the cameras, verifies what actually changed in the scene, and replans when it did not work. The LLM reasons; the robot moves. The agent is never on the control path.
And critically: the fine-tuned policy from stage 04 is one tool in that harness, not the whole robot. The harness also holds analytic grasp and motion primitives, perception queries, scene verification, and the ability to write a short program that composes them. See below.
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 data conventions, the command that trained on simulated episodes runs unchanged on hardware. What breaks in the house is the most valuable data we own, and it goes straight back to stage 01.
SAME CONVENTIONS, NO REWRITE · NO REMOTE OPERATORS · NOTHING SCRIPTED FOR THE DEMO · REAL FAILURES BECOME TOMORROW'S TRAINING VARIATIONS
◊ ◊ ◊
A Different Operational Algorithm
The dominant approach is to scale one end-to-end model until it generalises, and to treat everything else as scaffolding. We think the model is the easy part to buy and the hard part to depend on. So we spend our effort on the operational architecture around it: the part that decides whether a machine is trustworthy on the four-hundredth attempt, in a room nobody on our team has ever seen.
Six components, and only one of them is a model we train
A frontier LLM as the navigation engine
The reasoning core is 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 that fails. We are not in the business of catching up to a lab on general reasoning. We are in the business of aiming 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 states what it believes about the room, what it intends to do, and why. That transcript is not decoration. It is the reason a failure in someone's house is debuggable at all, the thing a customer can be shown when they ask what happened, and the richest signal we mine to decide 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
The machine commits to a prediction before it moves: this object should end up here, nothing else should change. Then it checks the world against that prediction. A mismatch is caught by the robot, in the moment, rather than discovered by a person later. This is the mechanism behind every promise in the doctrine: 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 rather than a generic one of all homes. Where things live here. What this household calls them. Which surfaces are fragile, which door sticks, which chore has never worked in this room. Asked once, remembered permanently. This is the compounding asset: the machine gets measurably better in your house specifically, and a competitor arriving two years later starts from nothing in that room.
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 thing we do train, and the only learned component on the control path. It is very good at exactly one job: smooth, fast, contact-rich motion on chores it has seen. It is not asked to plan, to reason about language it has never been shown, or to decide when to give up. Those are somebody else's job in this architecture.
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 navigation engine as a tool, and every tool resolves through a single guarded interface. Learned or written, a command is range-checked, rate-limited and preemptible before it reaches a joint. That boundary is what lets us 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
What the harness actually is
Claude Code did not make the underlying model any 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 is the robot's cognitive brain. It holds the mission, decides what to try, calls a tool, reads the result, and decides what to do next. Intent, memory, judgement and recovery all live there. The policy is not the brain in this architecture. The policy is a hand.
Most of this industry has made the policy the product. Everything is bet on one end-to-end model: if the VLA cannot do a chore, the company cannot do the chore. That is a brittle way to build, and it is why so much of the field is stuck waiting on the next checkpoint.
We build the other way around. The harness is the product, and it is given a toolkit. A learned policy is the fastest, smoothest option for contact-rich motion it has actually been trained on. For everything else the harness reaches for analytic grasp and motion primitives, perception queries, verification, or a short program it writes on the spot. Steering a VLA is hard. Steering a frontier model that can call tools and write code is easy, and it works today.
| Tool | What it is | When the engine reaches for it |
|---|---|---|
| VLA policy | The learned visuomotor loop from stage 04, running closed-loop at 25 Hz | Contact-rich motion it was actually trained on, where smoothness and speed matter |
| Grasp and motion primitives | Analytic IK, planned reach, transport, place, retreat | The geometry is known, the tolerance is tight, and no demonstrations exist yet |
| Perception queries | Detect, locate and describe what is on the surface | Binding a noun in a sentence to an actual object in the room |
| Verification | Scene diff and camera read-back after every action | Deciding whether the last thing it did worked, every time, rather than optimistically |
| Code the engine writes | A short program composing the four above | A chore nobody has trained a policy for and nobody has scripted |
This is not a contrarian bet; it is the direction the field is converging on. Berkeley's Maestro shows a coding agent composing curated robotics modules matching or beating state-of-the-art VLAs zero-shot with no new teleoperation data, and calling a VLA as one of its own tools for the contact-rich parts, cutting long-horizon task time 2.3×. RHO, Harness VLA and demonstration-free agent frameworks report the same shape of result, as do recently launched teams giving frontier models tool primitives for direct robot control. Their consistent finding is that orchestration, not raw tool availability, is the bottleneck, which is precisely why we treat the operational architecture as the product.
What we are deliberately not doing
| The default approach | Ours |
|---|---|
| Scale one end-to-end model until it generalises to every home | Compose lean components around a frontier reasoner we do not have to train |
| Reliability arrives with a better checkpoint | Reliability is produced at runtime by prediction, verification and recovery |
| A data moat built from a teleoperation fleet | Data from our own loop, plus trajectories the engine generates itself |
| Remote human operators cover the last stubborn fraction | The machine detects its own failure and tells you about it |
| Every new capability requires a training run | Most new capabilities require a tool |
| Generic competence across all environments | Deep, persistent competence in one specific home |
◊ ◊ ◊
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 on computers, in days rather than quarters, with no robot hardware involved and nobody teleoperating anything:
- 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 are that pipeline working. Nothing is scripted at runtime: the policy sees pixels and a sentence, and outputs joint targets at 25 Hz. The point is not that the clips are remarkable. It is that the loop that produced them turns around this fast, and 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.
◊ ◊ ◊
The Agentic Stack
One principle runs this company: we should be able to change the machine, and teach it a new skill, faster than anybody else can. So the whole stack, mechanical and electrical and evaluation, is written to be driven by agents rather than by hand. A design change is a diff. A new chore is a run of the loop. Neither waits in a queue behind one overloaded engineer.
| What agents drive | In-house software | What that buys us |
|---|---|---|
| Mechanical design | Modbot | 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 | Modbot Studio | 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 | Modbot · in development | 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 | Modbot · in development | 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 Lab | Dataset collection, audits, per-checkpoint evaluation and release gating all run unattended. Nobody eyeballs a video and calls it progress |
| Skill transfer | Autona Harness | The loop in section 02, end to end, without a person babysitting it. A new chore goes from a small sample set to a policy running on the robot in days |
Generated by our agentic CAD pipeline from written specifications. No sketch plane was touched by a human.
We do not scale this company by adding people to a queue. We scale it by making the queue something an agent runs overnight.The agentic stack
◊ ◊ ◊
The Doctrine
A house is not a production line
Manipulation systems today complete most attempts, not nearly all of them. The industry reads that as not yet. We read it as wrong building. In a factory, one failure costs a stopped line. In a house, a failed chore leaves the house exactly as it would have been if the machine did not exist, and the buyer is not comparing us to a perfect robot but to themselves, tired, at nine in the evening.
Nobody demanded the dishwasher clean the roasting tin. Nobody asked the robot vacuum to do the stairs. Both are loved anyway. So the target is not perfection, it is failing gracefully, every time:
- Never break what you were asked to move. An uncertain grasp is abandoned before the lift, not during it.
- Stop and say so. No silent failures, and no remote operator quietly finishing the job off-camera.
- Never leave the house worse. A partial chore is restored to its starting state.
- Do exactly what was asked. Extra work is a failure to follow language, and we score it that way in training.
- Keep the list honest. A chore that is not reliable in your home comes off your card rather than staying on it to look impressive.
That is also the whole trust strategy. A household hands a machine the run of the kitchen not because of a policy document, but because it has been quietly useful for a month and never once made the evening worse. Trust in this category is not argued, it is accumulated, and it accumulates fastest for whoever is delivering the experience first.
◊ ◊ ◊
Why Speed Wins
Nokia sold half the phones on earth and lost the category inside a decade. The car companies that survived the 1920s did not have the best car; they won on process and consistency. Hardware is collapsing to the EV supply chain and manipulation models are becoming licensable infrastructure, so neither is anybody's moat. What is left is loop time, trust, service and an installed base that compounds. That moat is built in years and cannot be bought.
Why us
If the category is decided on deployment, the only question that matters about a team is whether it has actually put machines in front of people who did not have to be polite about them. So we are assembling operators, not authors: people with proven track records who have designed, built, shipped and supported robots for a living, in different industries and for different purposes, and who have fixed a machine failing at a customer site by Friday. Getting a robot to work once is a research problem and plenty of people can do it. Keeping a fleet working in places you do not control is an operational problem, and far fewer ever have.
Nobody wins this category by being the most capable in 2031. Somebody wins it by being the one already in the kitchen in 2028, and then never leaving.Autona Machines
◊ ◊ ◊