Modular hardware-in-the-loop · Phase 1 running end to end

Close the loop between agents and silicon.

A slot-based test bench that lets AI agents, CI pipelines and engineers drive real microcontroller hardware, with timing kept on the module to well under a microsecond, fault injection on every module and a full audit trail. Priced like a good oscilloscope, not a car.

Built for agentic firmware loops CI farms production line tests precision rigs the desk next to you agentic firmware loops
0.83 µstrigger → action, on the module
8hardware trigger lines, wired-OR
$3–8ktarget bench price
Scroll

The missing link

Agents can write, build and flash firmware.
Now they can watch it run.

Agentic development stops where the hardware starts. The bench gives an agent real stimulus, hardware timestamps and fault injection through MCP, behind the same safety rails a person would have.

iteration #0001 PASS
  1. WriteThe agent edits firmware and a test from the requirement.
  2. BuildSame build as CI. Firmware version goes into the run manifest.
  3. FlashThe image lands on the device under test.
  4. StimulateThe bench drives I/O and injects faults on a schedule kept by the module clocks.
  5. ObserveEvery edge, byte and frame is timestamped in hardware on one shared clock.
  6. JudgeStructured events go back to the agent. The bench records; the client judges.
◎Read-only by default

An agent token can observe. Driving anything needs more.

✋Person-approved grants

Scoped signals, risk classes, an action budget and an expiry, approved by whoever holds the bench.

⛨Limits in firmware

MCP is the protocol, not the security boundary. Voltage and timing limits are enforced on the module.

≣Every action audited

Who did what, under whose lease and grant, written to the audit log.

One clock

Every signal on one timeline.

Each module stamps its edges, bytes and faults against the shared 10 MHz clock. A run reads like a logic analyser trace, and a reaction on the module shows up as a measured gap.

run 4f2a · plan "brownout" · 25 ms t = 0.0 ms
dut.btnGPIO ch3 · stimulus TRIG0backplane · wired-OR dut.ledGPIO ch2 · response dut.vccPSU out 1 · 3.3 V Δt 0.83 µs rule on the module: btn ↑ → TRIG0 LED on, no host involved fault: vcc dropout, 2 ms DUT rebooted

Illustrative run, not to scale. The 0.83 µs reaction is measured on the dev board; the rest follows the plan's timing.

What it solves

Six reasons firmware teams
still test by hand.

01

Real HIL costs as much as a car

Industrial modular HIL is quote-only, commonly tens to hundreds of thousands of dollars, and tied to one vendor's toolchain.

→A modular bench targeted at $3–8k, under a manager's approval limit. Tests are plain pytest.

02

DIY rigs rot

Flaky USB hubs, ports that rename, relay boards and scripts that only one person understands.

→One daemon, cards found from their ID EEPROM, hot-plug, a lease per bench and a safe state on any loss.

03

Linux can't keep time

PREEMPT_RT's worst case is tens of microseconds and not guaranteed. A round trip through USB is milliseconds.

→Timing lives on the module MCUs. The host defines the plan and is never in the timing path.

04

Nobody injects faults

Power loss during a flash write, brown-out, a dropped radio link: rarely tested, and when it is, by hand.

→Fault injection on every module, fired by a rule on the module the moment a condition occurs.

05

Agents can't touch hardware safely

Giving a coding agent a relay and a power supply is either useless or dangerous.

→MCP tools generated from the capability registry, with grants, budgets, approvals and firmware limits.

06

Results nobody can compare

A test passed on some bench, with some firmware, with some calibration. Which one?

→Plan hash, firmware version, bench ID and calibration go with every run. Runs that differ are marked not comparable.

Go deeper

Pick a door.

01

The bench in 3D

Scroll through the chassis, one module, the backplane and the device under test, full screen.

Open the tour →
02

Technology

Three tiers, the timing modes, what's new, and the module lineup.

Read the architecture →
03

Use cases

From agentic loops to production lines, with real test code and a comparison.

See where it fits →
04

Roadmap

What's built, what's measured, what's next, and the design partner program.

Where we are →

Design partner program

Bring your firmware.
We'll bring the loop.

We're looking for 5–10 firmware teams who ship at least monthly and test on hardware by hand or with a DIY rig today. Paid pilots, early hardware and a direct line to the people building it.

Talk to us →