We started with an arm. Then we changed the first experiment.

A low parts price tells us very little about how hard a robot will be to use. Someone still has to assemble the software path, teach or configure a task, recover when it fails, and figure out whether a change helped.

That was the problem behind Roboty's September 17 specification. This opening account comes from the September 17–18 specifications, before a physical result or measured reduction in setup effort. The initial focus was one inexpensive SO-101 arm, with a practical goal: help someone understand, set up and get repeatable results from one supported configuration. The scope was deliberately smaller than a catalogue of everything a robot might someday do.

The first proposed complete workflow was substantial. It included setup, demonstrations, training, supervised evaluation and a next-day restart. A phone-first guidance path was part of the direction, but phone-only computation was not a promise. We would reuse suitable tools and improve the gaps between them.

By September 18, the starting sequence had changed. Before joining up the physical workflow, we would build one bounded simulated experiment on an Apple Silicon Mac.

What became smaller

The first task was reaching a target. A cube-to-tray task would follow. That cut the immediate question down from “Can a new owner complete a learned manipulation workflow?” to “Can we run, score and inspect one controlled attempt?”

Those questions require different work:

First simulated reach	Later physical workflow
One scene and a defined target	The actual installation and workspace
A declared action interface	Hardware configuration and calibration
A computed success condition	Measurements appropriate to the physical task
A retained attempt we can inspect	Setup, teaching, reset and recovery a person can follow

The smaller task let us investigate the software connections sooner. It postponed physical setup and transfer questions. It did not answer them.

There was another useful separation inside the simulation plan: a controller without a language model first, and an agent runner as a distinct path. If the reference controller could not move the simulated arm correctly, model reasoning was not the first thing to debug. Once that path worked, an agent attempt would introduce a different question about the observations and tools it received.

Reuse the engine, own the experiment

The revised plan called for existing physics, robot models, agent harnesses and inference servers. Roboty's contribution would be the supported task, its evaluation, the integration boundaries and the interface for understanding an attempt.

That is a practical limit on what to build. We did not need a new physics engine to discover that an actuator mapping was wrong. We did need enough control over the experiment to distinguish a mapping problem from a controller problem.

The initial work was also local. A person should be able to begin without hardware or a website account. The website and its research history could remain separate from moving a simulated arm.

The first checkpoint was a simulated reach with a reference controller. Could that path move the arm, score the result and leave an attempt we could inspect? The first reach implementation would put that separation into code.