The embedded industry is converging on Physical Intelligence through AI systems that perceive, reason, and act in the real world, within the hard constraints of edge hardware. Over the last few months this same column has been introducing stepping stones towards the realization of a full ecosystem centred around CodeFusion Studio, introducing the AI Debug Assistant as our first Agentic AI workflow, and building on top of an architecture that provides state-of-the-art tooling to profile and deploy models to run optimized inference in ADI hardware.
We have often talked about how tooling in the Embedded Space has not kept pace with the hardware it targets, i.e. unable to manage complexity or provide insights. We are seeing the same thing with Physical Intelligence systems where HW Stacks are emerging ahead of any relevant progress on the Embedded space.
That is where Agentic AI becomes central to this narrative, primarily from a development methodology. Agentic AI is how we build Physical Intelligence systems: autonomous, reasoning software pipelines that carry hardware context, negotiate constraints, and generate firmware that is correct for a specific physical device. Silicon awareness and silicon grounding become strategic imperatives for Embedded Developer Tools. I see all these concepts as operators at different layers of the same stack. If Physical Intelligence is what runs on the silicon, Agentic AI is how we get it there.
The question I want to address here is concrete: what does it actually take to build a multi-agent system that generates production-quality firmware for a Zephyr-based ADI platform?
What The Literature is telling us…
The EmbedAgent benchmark, published at ICSE 2026, provides the most honest measurement of where current LLMs stand on embedded development tasks. The results deserve careful reading.
Across 126 test cases covering 9 electronic components and 3 hardware platforms, the best-performing model in the study was DeepSeek-R1, achieving a 55.6% pass rate when provided with schematic information. Without schematic context, that drops to 50.0%. For cross-platform migration to ESP-IDF, the best model reaches a 29.4% pass rate.
We don’t see these types of numbers often but they truly matter when you are generating firmware for a production embedded system.
The failure modes reported are not random. They cluster around tasks that require hardware-specific knowledge: peripheral configuration, platform API usage, circuit constraint resolution. The models are failing because they lack the hardware context awareness required to write C for a specific physical device.
Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Analog Devices, Inc (ADI) or its subsidiaries. The content is provided for informational purposes only and is not meant to be an endorsement or representation by ADI or any other party. This site may also provide links or references to non-ADI sites and resources. ADI makes no representations, warranties, or other commitments whatsoever about any non-ADI sites or third-party resources that may be referenced, accessible from, or linked to this site.
correct
The paper's authors found that RAG with structured hardware context, combined with compiler feedback, improves DeepSeek-R1's pass rate to 65.1% without changing the model. The bottleneck is not model capability. It is hardware context. Every architectural decision in an agentic embedded development pipeline should follow from that finding.
Why A Single Agent Is Not The Solution
The instinct when building AI-assisted firmware generation is to start with a single agent: provide the project description, inject some context and generate code. It is fast to prototype and immediately demonstrable.
More often than not it fails in ways that are not obvious until you hit them.
A complete Zephyr project for a platform like the MAX32690, an ARM Cortex-M4 and RISC-V dual-core SoC, requires simultaneously resolving board-level DeviceTree configuration, SoC-level peripheral register maps, Kconfig dependency graphs, RTOS task architecture, DMA channel assignments, application API contracts, and errata for the specific silicon revision. No context window holds all of this coherently without degradation. This implies that the model loses the thread. The Kconfig configuration drifts from the DeviceTree. The peripheral driver uses a DMA channel assigned elsewhere. The errors could be silent and they would express themselves as producing code that compiles, links and fails at runtime.
The deeper issue is that these knowledge domains have hard boundaries between them. In a modern software development team, a BSP or HAL engineer and an RTOS integration engineer are different people with different expertise. Skills are narrow and specialized. Forcing a single agent to span both produces dilution: enough knowledge about everything to generate plausible output, not enough about any single domain to generate correct output.
Agent boundaries should emerge from domain seams, not from task complexity. You create a separate agent not because a task is hard but because it requires a fundamentally different knowledge substrate than the adjacent task.
The Architecture
An effective multi-agent architecture for generating Zephyr projects should be designed as a contract-governed embedded software pipeline rather than as a loose collection of code-generating agents. The central challenge is not merely producing source files; it is preserving hardware intent, respecting board configuration boundaries, generating coherent application structure, and reaching a reproducible Zephyr build without allowing agents to overwrite one another’s responsibilities.
The architecture should begin with a hardware-aware planning stage. This stage consumes the project context, board target, configuration output, existing board overlays, memory layout, enabled peripherals, source tree, and relevant silicon constraints. Its primary output is not code, but an implementation contract. The contract defines expected files, public APIs, peripheral handles, external devices, ownership boundaries, build artifacts, and permitted DeviceTree and Kconfig changes. This contract becomes the governing interface between planning, generation, validation, and build integration.
A unified code generation layer should then implement the contract. Instead of relying on separate historical agents for BSP, HAL and RTOS responsibilities, the system should use a single embedded CodeGen capability operating over carefully scoped slices of the contract. For small cohesive applications, such as a GPIO interrupt triggering an ADC sample followed by an I2C transfer, a single model invocation is preferable. It preserves context, minimizes latency, and reduces cross-slice inconsistency. For larger systems involving external sensors, networking, watchdog supervision, signal processing, and telemetry, the contract should be decomposed into narrow ownership slices. Each slice should correspond to a clear software concern: an ADC module, an accelerometer driver, an Ethernet device manager, a telemetry publisher, a processing module, or a platform integration layer.
This split policy is fundamental. Splitting should not be driven by file count alone. It should consider domain complexity, number of tasks, external devices, cross-module dependencies, and the likelihood that a single model call will omit files or blur ownership. Small-only workflows should remain unified. Complex connected or industrial systems should be decomposed, but each slice must be explicit.
DeviceTree handling requires the strictest boundary. Zephyr DeviceTree is not an area where generative freedom is desirable. Board-level hardware configuration should remain owned by the context inferenced mechanism and the existing board overlay. Generated application code should reference existing labels and declared devices, not invent bus nodes, pinctrl groups, root nodes, /chosen entries, or controller definitions. For external devices, child nodes may be generated only when the contract explicitly declares the device, bus, compatible string, chip select, interrupt GPIO, and binding-required properties. Any overlay outside this declared boundary should be rejected before build.
Kconfig should be treated similarly. Generated configuration must be deterministic, sanitized, and derived from declared requirements rather than guessed. The pipeline should map known aliases to valid Zephyr.
Validation should occur before project mutation. The system should verify that generated files satisfy the contract, that required .c and .h files exist, that public functions are present, and that placeholder implementations have not been emitted. The builder should then reconcile CMake sources, include directories, Kconfig fragments, overlays, and board selection deterministically before running Zephyr build gates.
The ideal architecture is therefore contract-first, hardware-aware, and deterministic at the integration boundary. Generative models are used where they provide leverage by producing module implementations, adapting APIs, and translating requirements into code. Deterministic software governs the areas where hallucination is costly: ownership slicing, DeviceTree policy, Kconfig policy, build integration, completeness validation, and repair routing.
Such a system turns multi-agent generation from a prompt sequence into an embedded software production pipeline. Its value lies not in having many agents, but in making each agent operate within explicit contracts, verifiable boundaries, and Zephyr-aware build constraints. That discipline is what enables reliable generation of nontrivial embedded applications from high-level intent.
The Zephyr-Specific Complications
The academic literature on multi-agent code generation is evaluated almost entirely on general-purpose software tasks with fast feedback loops. Zephyr is a different problem class.
· Kconfig. Zephyr's configuration system is a dependency graph spanning thousands of symbols, with select relationships and depends on chains that interact non-obviously. An agent generating a prj.conf without access to the Kconfig dependency graph for the target board is guessing.
· DeviceTree. A Zephyr peripheral driver is correct only when the DeviceTree configuration is consistent with the physical hardware. The I2C instance must match the pins routed on the target board. The SPI chip-select GPIO must match the schematic. None of this lives in the application source. You can find them in board DTS files, SoC DTS files, and application overlays that must be in the agent's context at generation time.
· Peripheral coherence. A driver requesting a baud rate the clock tree cannot produce compiles and fails silently at runtime. A DMA transfer exceeding the peripheral's FIFO depth causes data corruption that manifests only under throughput. They are the normal failure mode when an agent generates peripheral code without silicon-level constraint awareness from CMSIS-SVD.
· Errata. Silicon errata are hardware bugs with software workarounds. They are silicon-revision-specific and absent from any LLM training corpus. An agent generating a DMA driver without awareness of a relevant errata entry for a given device produces code that compiles cleanly and fails under load in integration. There is no path from general-purpose model training to correct errata handling. The errata database must be a first-class knowledge source, indexed by peripheral and revision, and surfaced at generation time.
Every one of these failure modes is invisible to any benchmark that does not test against real silicon with real hardware constraints.
What This Changes for Developer Tools
Zephyr introduced DeviceTree as the hardware description mechanism for embedded software. This is a fundamental shift in how hardware and software are separated, described and composed. A gap exists today in tooling that can produce a machine-readable representation of hardware intent that could, in principle, serve as the foundation for automated reasoning about the hardware-software interface.
Agentic AI for embedded development is the same kind of inflection point. It is not autocomplete at scale. It is a different model for who does what in the development process. The agent carries the hardware context. The agent negotiates the interface contract. The agent generates the peripheral driver. The engineer defines the system boundary, reviews the contracts, validates the output, and owns every line that goes into the build.
The embedded engineer who understands register maps, Kconfig dependency graphs, and silicon errata does not become less valuable in this emerging world of agentic workflows, they become the person whose expertise makes the agent correct rather than merely capable. That knowledge becomes the context layer that makes the pipeline trustworthy.
Physical Intelligence systems will be built with tools that carry this kind of hardware context, or they will be built slower and with more failures than the market will tolerate. The tooling has to know the silicon. It has to respect the errata. It has to understand that a DeviceTree overlay is a hardware constraint, not a suggestion.
The pipeline architecture described here is the starting point. Tools such as the AI Debug Assistant already reason directly with live silicon state. The next step is closing the loop: from hardware configuration, through hardware-context-aware firmware generation, to hardware-grounded debug. That is the full agentic embedded development lifecycle and it starts with developer tools built for the physical world.
