Why your AI agent needs virtual, auditable hardware
Category: Whitepaper
Agents write firmware. They still cannot prove it runs. They need hardware they can flash, watch, and trust — without a closed black box. LabWired is open-source (MIT) virtual boards under MCP, same oracle in the Playground and in CI.
Caption: Real boards are scarce and slow to share. Virtual ones run in parallel and return the same result twice.
Ask an agent for a UART driver, a clock tree, a FreeRTOS task, or an I²C sensor bring-up. You will usually get something that compiles. The next step is harder: the agent cannot flash your board, watch the pins, or tell you whether the OLED painted or the peripheral clock started.
On the web, agents run tests and read the failure. On embedded, they stop at a clean build.
The feedback loop
Agents get better when they write code, run it, read the output, and fix the failure. Without the run step, you have autocomplete with confidence.
Backend work closes that loop locally. The agent runs npm test or pytest, reads the stack trace, patches the bug, and runs again.
Embedded does not have an equivalent for “USART2 is at 115200 with this RCC path and pinmux.” Firmware runs on a chip. Until recently that chip sat on a desk with a human holding a probe. The agent has no hands.
Caption: The loop stops at the bench. A clean build is still unproven firmware.
Most teams end the agent session after compile. Language models invent register names and HAL calls with the same confidence as real ones. The compiler does not catch that. You only see the failure when the binary runs on a target and you watch UART, buses, displays, or faults. Agents have been locked out of that step.
What a virtual board has to do
Teams hit this problem with human engineers long before agents showed up. Boards are scarce, flaky, and hard to put under CI (see why embedded tests flake). Simulation can stand in: run the same production code you would flash, get a pass or fail you can trust, do it in parallel.
For an agent the bar is higher. The loop has to look like pytest: load firmware, run it, read structured results, iterate — every few seconds, without a human in the middle. That means a short, machine-readable contract (MCP tools, result.json, UART logs, traces), not a Monitor shell and a pile of scripts.
LabWired is that substrate: full boards and multi-device systems, deterministic runs, MIT source you can audit, Playground for humans, MCP for agents, CI for the team — one oracle.
Other approaches
Hosted chip MCP services (e.g. Veecle Chiplab) close hello-world: build an ELF, run on a virtual chip, read UART. Useful — and often chip-scoped, hosted-first, UART-heavy. LabWired is open core, full boards (displays, sensors, buses), and a Playground URL on the same run.
Agents that flash real silicon (e.g. BootLoop, Embedder) keep hardware on the critical path: serial, flaky timing, and a bad PWM that can still fry a stage. LabWired keeps hardware off that path. Prove the binary on a deterministic virtual board first — including in CI without a HIL bench. Silicon can come later.
How agents connect: MCP
LabWired speaks MCP so Claude Code, Codex, Cursor, and other hosts can load boards, run firmware, and read results without a custom plugin. One install line, then the agent calls tools the same way it already reads files and runs shell commands.
Connecting MCP is the easy part. The value is what answers: a register-accurate virtual board that runs the code and returns UART, displays, traces, and result.json — measured signal, not a prose guess.
LabWired rule
A claim that firmware works never rests on an LLM self-report. The agent proposes. The simulator decides. See also the closed loop.
What a virtual board includes
Products are MCUs plus sensors, displays, power, and buses. Often several MCUs share CAN, SPI, or a fieldbus. The long bugs sit in that wiring.
Caption: Each lap returns structured evidence in seconds.
LabWired models boards and multi-board systems:
- MCUs. ARM Cortex-M, RISC-V, and Xtensa (ESP) — running the same code you would flash to silicon.
- Parts. UART, SPI, I²C, CAN, GPIO, timers, displays (SSD1306, Nokia 5110, e-paper), sensors (BME280, MPU6050), industrial stacks (IO-Link, UDS).
- Determinism. Same binary and system description, same result.
- Evidence.
result.json, UART logs, VCD, PC history, display frames. - Three surfaces. Playground, MCP, and CI.
Examples
1. ESP32 e-reader (Arduino + FreeRTOS + GxEPD2)
An ESP32-WROOM-32 driving a Waveshare 2.9″ e-paper display over SPI. The agent builds with PlatformIO, hands firmware.elf to the simulator, and checks the rendered frame. See the Arduino e-paper tutorial.
2. Full UDS ECU diagnostic check (27 services)
Two STM32H5 nodes on a simulated FDCAN bus. The tester sends ISO-14229 requests; the ECU runs unmodified udslib firmware. See 27-service ECU check.
3. IO-Link master station (Master + 2 Sensors over C/Q)
An STM32L476 IO-Link master driving two sensor nodes across modeled C/Q links. See full IO-Link master.
Build, run, inspect
The core contract is three operations:
- Build. Use PlatformIO,
make, orwest. The simulator accepts standard ELFs. - Run. Execute in the simulator via CLI or MCP (
labwired test). - Inspect. Assert against UART logs,
g_service_resultsmemory addresses, or VCD trace files.
# Example: run a test script against an ELF
labwired test --script test.yaml --firmware build/firmware.elf
What changes in practice
- No hardware bottlenecks. CI pipelines run 50 virtual boards concurrently without waiting for a USB bench slot.
- Zero HIL flakiness. Clock drift and execution jitter are eliminated by fixed lockstep instruction stepping.
- Auditable proof. Every test run outputs machine-readable evidence (
result.json, VCD traces) pinned to git commit SHAs.
Why open source
Hardware tools have traditionally been proprietary, expensive, and locked behind vendor dongles. LabWired’s core engine is MIT licensed on GitHub.
Anyone can audit the CPU models, extend peripheral models, or run the engine locally without cloud dependencies or license servers.
Why LabWired
- Complete systems: MCUs, buses, displays, and sensors on one modeled canvas.
- Zero-setup CI: Runs on free GitHub Actions runners in under 2 minutes.
- Agent native: Native Model Context Protocol (MCP) integration out of the box.
