A language model can give a persuasive answer about a physical invention in seconds. It can suggest a sensor, sketch a circuit, name a controller, and produce code that looks finished. The hard part begins when the conversation ends. Which component variant did it mean? What is already owned? Which claim came from a datasheet? What should happen on the bench, and what has actually been observed?
That gap is why I built AI Robot Workshop, an open-source, local-first environment for turning an agent conversation into a project that can be inspected and continued. The name expresses the direction of the work, not a claim that robots have already been built. The current hardware routes are researched and documented but unbuilt; their software traces are tested separately.
The project’s central argument is simple: AI-assisted physical invention needs persistent artifacts and explicit evidence, not just a plausible answer.
An invention is a directory
In the workshop, an invention is an ordinary directory. It contains AGENTS.md, which tells a coding agent how to work in the project; ENGINEERING.md, which carries requirements, interfaces, assembly steps, validation plans, and unknowns; a versioned JSON manifest; and the original Markdown, firmware, images, and models. The repository README shows the complete local workflow: initialize, validate, register, edit, export, and import.
This structure matters because the directory outlives any one chat session. A person can open the files in an editor. An agent can inspect the same engineering plan. Firmware remains firmware rather than becoming prose trapped in a transcript. When an agent proposes changes, the workshop places them in a candidate result directory so the original project remains available. That candidate directory is a review boundary, not an operating-system sandbox; the agent’s execution permissions still determine what it can reach.
The same evidence discipline appears in the parts catalog. A project distinguishes required quantity, recorded-owned quantity, and what remains. Supplier-backed claims retain their source; manually edited claims are marked as manual. PDF and text specifications can be extracted locally, but the extracted fields must be reviewed beside the source before saving. Scanned PDFs require manual text entry because the prototype does not provide OCR. It also does not purchase parts, check live availability, or imply that a supplier link is an order recommendation.
From a sensor plan to a controlled observation
The clearest route through the workshop starts with a Raspberry Pi Pico and BME280 environmental sensor. The hosted sensor build guide identifies the intended variants, headers, cable choices, four connections, staged checks, and the files that belong in the source bundle. The sensor-wiring lab then asks the reader to diagnose swapped signals, missing ground, and an incorrect supply endpoint. It teaches the connection model; it does not simulate electricity or certify a real breadboard.
The next project adds an external LED and series resistor. Its build guide separates the commanded LED state from observed light, because software intent and physical behavior are not the same evidence. The control rule uses hysteresis: a sample at or above 28 °C commands the LED on, a sample at or below 26 °C commands it off, and values between those boundaries retain the previous command. Faults and resets clear the command.
Readers can step through that state in the hosted hysteresis lab, including threshold chatter, faults, and restart. The implementation is inspectable in sensor-hysteresis.ts. More importantly, sensor-hysteresis.test.ts differentially checks the TypeScript lesson model against the exported Python firmware function across preset scenarios, exact boundaries, nearby values, and a longer deterministic sequence.
That establishes agreement between two software representations. It does not establish sensor calibration, correct wiring, LED brightness, thermal response, or a successful physical build. Those belong in bench observations. The workshop’s browser-local sensor and LED worksheets keep predictions, imported readings, calculations, and observations distinct so a clean software trace cannot quietly become a hardware claim.
Learning that stays attached to the work
The learning library contains 48 applied lessons across measurement, electronics, mechanics, embedded programming, control, and robotics. Instead of pretending that every topic can be simulated, the workshop selects bounded labs where a model can say something precise: an RC response, a motor estimate, a power budget, a GPIO state machine, a wiring diagnosis, or a firmware command trace. Each model exposes its assumptions and limits.
Progress also preserves an important distinction. Reading a lesson is not the same as completing its practice, and neither is the same as recording a bench demonstration. Those states can be exported and restored, but the interface does not turn curriculum completion into evidence that hardware worked.
The hosted site is the immediate entrance: lessons, labs, guides, object studies, and browser-local worksheets work without an account. The full workshop is deliberately local. Download the MIT-licensed source, run it with Node and pnpm, and the application can create project directories, persist the parts catalog on the filesystem, ingest local documents, and connect to an agent.
Local agent integration uses ACP over stdio. The transport and permission flow have been tested with a stdio test peer, but a live authenticated model session still needs an end-to-end smoke test. You bring your own locally authenticated agent provider; there is no hosted inference, included token pool, or workshop billing. Local API access is limited to the configured loopback host, a matching origin, and a process token in security.ts.
Underneath, this is a TypeScript, Next.js, and React application. Zod contracts validate the portable formats, filesystem storage keeps local projects inspectable, and Three.js supports selected mechanism and native-model previews. The dependency and script manifest is public. It is not a universal mechanical, electrical, thermal, or microcontroller simulator, and a moving preview does not prove buildability.
What remains open
This release is experimental portfolio work, published under MIT so the artifacts and boundaries can be inspected together. The obvious next steps are physical builds with recorded measurements, a real authenticated ACP smoke test, broader import and preview coverage, and refinement driven by people using the guides at a bench. Hosted accounts, public project pages, automated purchasing, and a general simulator are not hidden completed features; they are outside this prototype.
Try the hosted sensor wiring exercise and hysteresis trace. Then run the repository locally and inspect the project files yourself. Feedback, issues, and focused contributions are welcome. For more work like this, browse all writing or return to Nick Bryant’s portfolio.
