An AI agent that can write firmware is not the same as an agent that finishes firmware. Most current discussion of agents centers on the first capability. For firmware engineers, the second one matters more.
What an agent can produce today
Modern coding agents can read a datasheet excerpt, draft a driver, and propose a fix for a compiler error. These are real capabilities, and they reduce the time spent on drafting. But the output of an agent session is usually a set of changed files. Whether those files produce correct behavior on a board is a separate question, and the session does not answer it.
Where firmware work actually ends
A firmware change is finished when it runs on target hardware and the expected behavior is observed. Getting there requires steps that happen outside the editor: building with the correct toolchain and SDK version, flashing the right image to the right board, reading the serial log, checking peripheral behavior, and repeating the loop when something fails. Each step produces a result that informs the next decision. When these steps are handled by separate tools, or by an engineer copying output between windows, context breaks at every handoff.
Two different goals
FWAuto treats the agent as a participant in a workflow, not only as an author of code. The distinction shapes what gets built. An agent that only generates code is judged by the quality of its output. A workflow agent is judged by whether the loop closes: the build passes, the image boots, the peripheral responds, and the evidence is recorded.
This does not change the role of engineering judgment. Engineers still decide the architecture, interpret ambiguous specification language, and accept or reject a design. The agent’s job is to carry the mechanical coordination so that engineers spend their attention on decisions rather than on moving results between tools.
What this means in practice
Three principles follow from this view:
- Verification is part of the task, not a follow-up step. A change that has not run on hardware is an unverified change, and the workflow should say so.
- Each step should leave an inspectable record: build output, flash result, log excerpt, and test outcome.
- Human review stays in the loop at the points where engineering judgment matters, such as design decisions and the interpretation of ambiguous specifications.
Our position
FWAuto is an Agent OS for firmware workflow. Its purpose is to orchestrate the steps between engineering intent and verified firmware running on real hardware. We do not position it as a smarter model, and we do not claim that it replaces firmware engineers. The claim is narrower: the gap between “code was generated” and “the firmware works on the board” is a workflow problem, and that gap is where FWAuto focuses.