How Allspice built a frontier hardware design agent
The proliferation of coding agents has brought with it limitless possibilities for accelerating software development cycles and broken barriers in terms of the productivity of an individual software engineer. More recently, agents have assisted in answering longstanding unsolved mathematical and theoretical computer science problems. However, the use of AI assistance in hardware design is still in its infancy and many problems remain unsolved. At Allspice, one of our fundamental priorities is to bring the benefits of agentic collaboration to hardware teams. In this vein, we recently released a new version of DRCY, an agent that can not only inspect and review, but also (and more excitingly) modify and create hardware schematics.
Building DRCY taught us that standard approaches and intuition from coding and research agents do not directly carry over to hardware schematics. In the world of software engineering and mathematics, agents largely work directly with source code in text files. For programming, this is immediately clear. In the case of mathematics, this is usually Lean or even just proofs in natural language in a LaTeX file, for example. Tools around working with source files and executing them are scriptable and quick to iterate on. On the other hand, a hardware schematic does not necessarily have any of these properties. In this blog post, we cover the architecture we arrived at for DRCY along with the reasoning and learnings that came from our unique experience.
Brief history
DRCY started in early 2026 as a reviewer of hardware schematics. Based on model performance and maturity at that time, we designed it as a human-in-the-loop, agentic workflow, i.e., a system “where LLMs and tools are orchestrated through predefined code paths”. In the first iteration of DRCY, when a hardware engineer requested a design review, a fixed sequence of specialized models selected components, retrieved their datasheets, analyzed each pin, and posted review findings as comments. The architecture of DRCY's first release, as described in an earlier paper, was well-suited for the task of reviewing schematics, but as frontier models advanced we started looking for ways to unlock more advanced capabilities, such as letting hardware teams interactively ask questions about a design, make modifications to a schematic, or generate specialized reports tailored to an org-specific process. The new DRCY uses a modern agent harness that was designed specifically for the unique needs of hardware design instead of a fixed agentic workflow.
Why build our own agent?
There is a stark difference, in terms of compliance and complexity, between “vibe designing” hardware for a personal project and designing hardware at a major enterprise. In fact, for many engineering organizations, hardware designs are a core part of their IP and as such among the most sensitive parts of the organization’s internal data. For companies in regulated or critical industries, especially those working in aerospace, defense, semiconductors, and AI infrastructure, hardware designs and data can even be considered a national security concern. Furthermore, the cost and time of hardware development life cycles are typically several orders of magnitude larger than software development life cycles. Both of these fundamental requirements made the majority of off-the-shelf coding agents unsuitable candidates for a hardware agent like DRCY.
DRCY’s agent harness is written in Rust and runs server-side in sandboxed containers in Allspice’s platform. Early on in our design, we aligned on two requirements intended to decouple the logic of the agent’s functionality from two orthogonal challenges:
- Ensuring the agent can reason about a schematic independently from the specific ECAD format used to encode the schematic.
- Ensuring that the agent interacts with Allspice in a single logically central module.
For insight into the second requirement, we’ve been developing DRCY at a time when Allspice is expanding to the desktop and adding support for API and MCP interactions. Another, more immediate, reason for our second requirement was the desire to decouple evaluations of Allspice’s platform from evaluations of our agent. Our architecture in the figure below is designed to meet these two requirements.
.png)
Allspice's hardware design agent DRCY architecture overview
The Hardware Mutations Interface provides the agent harness with a set of tools to make well-scoped changes to a hardware schematic without having to parse or understand the syntax of its underlying ECAD format. This allows the agent to focus purely on the intent behind a hardware schematic change, which lets it create correct hardware designs at a higher success rate than off-the-shelf harnesses such as Codex and Claude Code using the same underlying LLM (see comparison below). The Datasheet Distribution Network (DDN) is an internal implementation of a Content Distribution Network (CDN) built specifically to cache and serve datasheets. Finally, the Platform Interface is a module that, similar to the Hardware Mutations Interface, is designed to let the agent harness communicate the intent of an action on Allspice’s platform, such as adding a comment or reading a repository, without having to worry about what the underlying platform exactly is and how it handles that action.
Evaluating hardware design
Our internal evals for hardware design consist of a set of human-verified circuit repair, extend, create, and review tasks across a diverse array of circuit designs in multiple ECAD formats. In this section, we show the results of a run on a randomly sampled subset of our internal evals. The results of the sampled subset are largely representative of the results of our complete eval. To compare with off-the-shelf harnesses, we also perform the exact same evaluation with an identical initial prompt in the same sandbox container (but without our harness-specific hardware mutation tools and platform interface tools) on Claude Code 2.1.322 running Claude Opus 5.5 and Codex CLI 0.167.0 running GPT 6.1 Sol. Note that the “Unusable in ECAD tool” category means the output failed to meet the requirements of the file format and we were unable to correctly open it in the ECAD tool. This comparison was done on a strictly held-out sample that we did not use to train or post-train DRCY’s underlying LLM, tune its prompts, or use for any other form of training.
The figure below shows an example circuit creation task. The task was to draw a voltage divider from two 10 kΩ resistors on an empty sheet, using parts from the project's library, and label its input, output and ground. We show the voltage divider for all harnesses as rendered by the ECAD tool’s viewer. Claude Code rendered it past the sheet’s right border and Codex rendered it without resistors.
What’s next?
AI-driven hardware design is one of the most economically impactful unsolved problems of our time. We view DRCY’s hardware design capabilities as an initial step that we plan to rapidly iterate on. Our team is working on expanding DRCY evaluations, the ECAD formats supported for schematic generation, and the desktop user experiences. We are also introducing support for component libraries and an integrated project scope. There is an exciting future ahead and we are equally excited to ship great stuff to make the future happen.
