From Requirements to Working Devices: AI Agents in End-to-End Hardware Design

1. Case Review: One Text Requirement, Three Devices That Boot

In software development, “requirements in, code out” is no longer unusual. From code completion to repository-level refactoring, AI-assisted development has become part of everyday engineering practice for many teams. But when the deliverable shifts from “deployable software” to “a powered circuit board,” the nature of the problem changes. A software defect can often be rolled back or hot-fixed. A hardware defect, once fabricated, may mean scrapped materials, weeks of waiting, and another board spin.

A recent technical report from an AI research institution presented a notable case. Researchers gave a next-generation large-model agent a simple text requirement and asked it to design three electronic devices:

• A home voice assistant;
• A USB conference phone;
• A handheld electronic pet.

The agent then completed the full design chain from requirement to physical object: selecting electronic components, designing the circuit board and enclosure, and writing control software. Manufacturing was handled by a partner organization. According to the report, all three devices ran successfully without any circuit modifications.

The significance of this case is not that each device is highly complex. Its significance is that it connects work normally spread across multiple specialized roles and toolchains into a closed loop:

• Electronic engineers handle component selection and schematics;
• PCB engineers handle layout and routing;
• Mechanical engineers handle enclosures and assembly;
• Embedded software engineers handle firmware and drivers;
• Test and manufacturing engineers handle validation and production introduction.

Compressing this chain into “one requirement in, a working device out” is the real breakthrough. Much of what is discussed as “AI-generated hardware” still stops at generating code snippets or simulation models. This case pushes the endpoint all the way to a physical object.

Note: Prototypes shown in technical reports usually operate under controlled conditions. Their success still requires independent reproduction and larger-scale validation. This article does not cite unverified metrics. Instead, it focuses on the technical logic and engineering methods behind the case.

2. Capability Breakdown: What an Agent Must Get Right from Requirement to Device

For an agent to reliably complete hardware design, several capabilities need to reach a usable level at the same time.

1. Requirement understanding: turning vague descriptions into verifiable technical specifications.

“Build a handheld electronic pet” is not an engineering requirement. It is a product vision. The agent must decompose it into measurable and testable specifications, including power source, battery-life targets, display size and resolution, interaction methods, enclosure dimensions, and cost ceilings.

2. Knowledge and reasoning: turning datasheets into design decisions.

Component interfaces, package options, electrical parameters, and recommended application circuits are often buried in datasheets that can be hundreds of pages long. The agent must extract the relevant information and weigh multiple candidates using factors such as power consumption, cost, lead time, package size, and ecosystem support.

3. Tool use: turning design actions into engineering artifacts.

Component selection requires querying component libraries. Circuit design requires generating netlists and schematics. PCB design requires completing layout and routing under constraints. Mechanical design requires generating 3D models. These tasks require the agent to call script interfaces exposed by EDA tools, simulators, and 3D modeling tools in a stable way, and to interpret returned error messages.

4. Long-horizon planning: staying aligned across dozens of steps.

A hardware project usually involves dozens of work items from requirement freeze to prototype delivery. The agent needs to maintain a global plan and replan when a local step fails, instead of continuing blindly along one path.

5. Self-validation: finding errors before delivery.

This is one of the biggest differences between hardware and pure software. Before submitting a design, the agent should proactively run electrical rule checks, design rule checks, design-for-manufacturing checks, and simulate key circuits. In the reported case, “running without circuit modification” is essentially the result of thorough self-checking and simulation before delivery.

3. Implementation Framework: A Five-Layer Architecture for Agent-Driven Hardware Development

To reproduce similar capabilities in a team, it helps to use a layered architecture. This turns “the agent” from a general-purpose chat entry point into a controlled engineering system.

+---------------------------------------------+
| L5 Delivery and Metrics: prototypes,        |
| production packages, quality dashboards     |
+---------------------------------------------+
| L4 Human-AI Collaboration: review gates,    |
| expert takeover, responsibility assignment  |
+---------------------------------------------+
| L3 Validation and Simulation: rule checks,  |
| simulation, virtual prototypes, HIL         |
+---------------------------------------------+
| L2 Orchestration Agent: planning, scheduling|
| memory, retries, rollback                   |
+---------------------------------------------+
| L1 Tools and Data: EDA scripts, simulators, |
| component libraries, datasheets             |
+---------------------------------------------+

L1: Tools and data layer.

The goal is to turn tools that humans operate into interfaces that agents can call. Many mainstream EDA tools provide scripting capabilities, such as querying components in bulk, generating netlists, and exporting manufacturing files. Component data can come from an internal approved component library or from a unified component data service. Datasheets, design specifications, and enterprise design rules should be stored in a searchable knowledge base.

L2: Orchestration layer.

This layer breaks complex tasks into subtasks, decides which tools to call and in what order, and writes intermediate results into the design task memory. It can draw on multi-agent division-of-labor patterns from software engineering:

• Architecture agent handles the overall system plan;
• Electronics agent handles the circuit;
• Mechanical agent handles the enclosure;
• Software agent handles firmware;
• Verification agent acts as the critic and checks the outputs of other agents.

L3: Validation layer.

This is the hardware world’s equivalent of CI/CD. When code is submitted, it goes through compilation, unit tests, and static scanning. Before a hardware design is delivered, it should also pass the following checks:

• Electrical rule checks and design rule checks;
• Simulation of key circuits;
• 3D interference checks;
• Firmware regression tests on virtual platforms;
• Hardware-in-the-loop simulation where conditions allow.

L4: Human-AI collaboration layer.

The agent is responsible for speed, while humans are responsible for precision. Review gates should be placed at key milestones, including requirement freeze, schematic finalization, PCB finalization, and board fabrication release.

L5: Delivery and metrics layer.

All design artifacts should be placed under version control, linked bidirectionally to requirement items, and connected to quality dashboards.

4. End-to-End Workflow: A USB Conference Phone Example

To show what the agent does at each stage, this section uses a hypothetical product similar to the device in the report. The parameters are illustrative and do not represent any real product.

Target: A plug-and-play USB conference phone that supports full-duplex calling, echo cancellation, button operation, and a simple status display.

4.1 Requirement Structuring: Make Requirements Verifiable First

When faced with a natural-language requirement, the first thing the agent should produce is a structured requirement specification. A good specification should include at least three parts: a unique ID, acceptance criteria, and a verification method. For example:

{
  "product": "usb-conf-phone",
  "requirements": [
    {"id": "R-01", "desc": "Powered by standard USB Type-C; no external power supply required", "verify": "Rule check plus power-on test"},
    {"id": "R-02", "desc": "Full-duplex calling; the far-end voice must not produce echo during a call", "verify": "Acoustic simulation plus reverberant-environment test"},
    {"id": "R-03", "desc": "At least three physical buttons, supporting hands-free mute and volume adjustment", "verify": "Functional test"},
    {"id": "R-04", "desc": "Total component cost must not exceed CNY 60 at 1,000-unit pricing", "verify": "BOM cost calculation"},
    {"id": "R-05", "desc": "PCB dimensions must not exceed 100 mm x 60 mm", "verify": "Mechanical interference check"}
  ],
  "non_functional": {
    "power": "Powered from the USB bus; average whole-device power consumption must be 2.5 W or less",
    "compliance": "Meet applicable electromagnetic compatibility and electrical safety requirements",
    "audio": "Pickup radius of at least 1 m; speaker sound pressure level suitable for small conference rooms"
  }
}

This step may look tedious, but it determines whether later stages can be automatically verified. Without verifiable requirement items, the agent cannot determine whether it “got it right” or merely “made it look right.”

4.2 Conceptual Design: Making Trade-Offs in the Solution Space

After the requirements are structured, the agent begins to design the overall architecture. The central question is: which part of the system handles audio?

• Option A: An MCU with dedicated audio instructions plus an external audio codec.

  • Advantage: controllable cost and rich peripherals.
  • Disadvantage: algorithms such as echo cancellation must be implemented by developers, which creates a large workload.

• Option B: An SoC with a dedicated audio processing module.

  • Advantage: integrates voice-processing blocks such as echo cancellation, automatic gain control, and noise suppression.
  • Disadvantage: limited part selection, requiring supply availability evaluation.

For a conference phone, echo cancellation is decisive for user experience. Implementing it from scratch is difficult and time-consuming. Therefore, the agent would usually choose Option B, an SoC with a dedicated audio processing module.

After choosing the architecture, the agent can generate a system block diagram: USB interface, power, main controller, microphone array, speaker amplifier, buttons, display, indicator LEDs, and status LEDs.

Module	Design focus	Typical risk
USB interface and protection	Type-C power input, series matching resistors on data lines, ESD protection	Incorrect interface definition preventing enumeration
Power	Deriving multiple voltage rails from USB voltage, decoupling, and filtering	Switching power supply noise coupling into the audio path
Main controller	Audio processing, USB audio device protocol, button and display drivers	Improper buffer design causing audio dropouts
Microphone	Digital microphone array, clock synchronization, matching pickup radius	Layout symmetry and enclosure openings affecting directivity
Speaker	Amplifier, enclosure volume, isolation of the audio path	Amplifier self-oscillation, pickup crosstalk
Human-machine interaction	Button debounce, long-press recognition, status indication	Mismatch between mechanical structure and PCB button positions

4.3 Component Selection: Use a Scoring Matrix Instead of Guessing

Component selection is the stage most prone to “hallucination.” The model may invent part numbers that do not exist or misread critical parameters such as package type or temperature range. A reliable approach has two steps:

1. Let tools, not memory, provide answers. The agent calls the component library interface and filters candidates by package type, operating voltage, operating temperature, audio-processing module, and supply status.

2. Score candidates and preserve traceability. Each candidate should retain its original source in the datasheet so that humans can review it.

def score_candidates(candidates, weights, rules):
    ranked = []
    for part in rules.filter_availability(candidates):  # First filter out obsolete or long-lead-time parts
        score = sum(weights[k] * part.metrics[k] for k in weights)
        ranked.append({"partno": part.partno, "score": score, "source": part.datasheet_ref})
    # Keep only the highest-scoring options that do not trigger critical red lines, such as oversized packages or excessive power
    return [c for c in sorted(ranked, key=lambda x: -x["score"])
            if not rules.violates_redline(c)][:3]

For cost-sensitive products, the agent may also need to design an alternate-part strategy, using pin-compatible or package-compatible components as backups to reduce supply volatility.

4.4 Schematic and PCB: Turning Rule Checks into the First Gate

After schematic design is complete, the agent should first run electrical rule checks. Common issues include:

• Missing decoupling capacitors on power networks;
• Incorrect configuration when digital microphones share a clock;
• Missing pull-up resistors on buttons;
• Connector pin definitions conflicting with the design.

The agent can also run targeted simulations for audio circuits:

• The effect of power-supply ripple on the audio noise floor;
• Stability of the amplifier output stage;
• Analog and digital ground partitioning and single-point connection.

During PCB design, the agent needs to complete the following tasks:

• Follow a “partition first, route later” principle, dividing the board into regions for USB and power, digital audio, analog audio, and mechanical parts;
• Place microphones as far as possible from speakers and buttons to reduce acoustic pickup crosstalk and mechanical vibration interference;
• Apply length matching to USB differential pairs and perform impedance design for high-speed signals;
• Place decoupling capacitors close to the relevant pins.

After that, design rule checks and design-for-manufacturing checks become the final automated gate before board fabrication. These checks include trace width and spacing, via diameter, silkscreen and solder mask, panelization process edges, test points, and assembly datum references.

4.5 Structural Design: Parametric Modeling and Interference Checks

Enclosure design usually has two parts:

• Parametric 3D modeling: Parameters such as enclosure length, wall thickness, corner radius, button opening size, and microphone sound-hole location are tied to PCB dimensions and interface positions;
• Tolerance chain analysis: This determines whether interfaces remain aligned after assembly.

A typical workflow is to first use 3D printing to produce a prototype, verify assembly relationships and button feel, and then decide on the tooling approach. For products with displays, such as a handheld electronic pet, the agent must also handle screen-to-enclosure fitting, light-guide structures, and the effect of the enclosure on antenna performance if wireless functionality exists.

4.6 Firmware Development: Hardware and Software Must Align in Both Directions

Firmware is where hardware and software meet. In this stage, the agent needs to:

• Configure USB audio device descriptors so that the device is recognized correctly when connected to a computer;
• Implement button scanning, debouncing, and long-press logic;
• Manage audio buffers to avoid obvious dropouts and latency during full-duplex calls;
• Design a state machine to manage transitions among idle, call, and mute states.

/* Example: mapping key events to the audio state machine */
typedef enum {
    EVT_KEY_MUTE,     /* Short press mute key */
    EVT_KEY_VOL_UP,   /* Short press volume up */
    EVT_KEY_VOL_DOWN, /* Short press volume down */
    EVT_KEY_LONG,     /* Long press any key: toggle speakerphone/handset */
    EVT_USB_READY     /* USB enumeration completed */
} key_event_t;
void on_key_event(key_event_t evt) {
    switch (state) {
    case ST_IDLE:
        if (evt == EVT_KEY_MUTE) audio_set_mute(true);
        break;
    case ST_CALL:
        if (evt == EVT_KEY_MUTE)          audio_set_mute(!audio_is_muted());
        else if (evt == EVT_KEY_VOL_UP)   audio_volume_up();
        else if (evt == EVT_KEY_VOL_DOWN) audio_volume_down();
        else if (evt == EVT_KEY_LONG)     audio_toggle_speakerphone();
        break;
    default:
        break;
    }
}

One important point is that embedded firmware can rarely be developed in true parallel with hardware. The actual behavior of the USB audio path often cannot be fully validated until a prototype is available. A more realistic approach is for the firmware agent to develop drivers and application-layer logic on a development board, and then use hardware-in-the-loop testing to quickly locate issues after the prototype is produced.

4.7 Verification and Regression: From One Successful Boot to Repeatable Success

Powering on a prototype only shows that the design “can work.” Production requires that “every unit works stably.” The agent team should establish a verification system:

• Requirement traceability matrix: Every requirement should be linked to a corresponding test item. Requirement coverage must reach 100% before the project can enter the board-fabrication stage;
• Automated test scripts: Use instrument-control interfaces to execute power-on checks, USB enumeration checks, audio loopback tests, and button-function tests in batch;
• Fault knowledge base: Record the symptoms, diagnosis process, and fixes from each failure, so that future designs can use them as a checklist.

Illustrative pseudocode:

def run_test_plan(plan, bench):
    results = []
    for case in plan:
        try:
            bench.power_on(limit_ma=500)          # Power on while monitoring current; cut power immediately if a short circuit is detected
            bench.wait_usb_enumeration(timeout_s=10)
            measured = bench.audio_loopback_rms()  # Audio loopback; measure output level and noise floor
            passed = case.check(measured)
        except BenchError as e:
            passed, measured = False, str(e)
        results.append({"case": case.id, "passed": passed, "detail": measured})
    return results

5. Engineering Deployment: Making Agent-Driven Hardware Development Stable

For the above workflow to run reliably, several engineering safeguards are essential.

1. Versioning and traceability.

Schematics, PCB files, mechanical models, firmware source code, and simulation scripts should be linked one-to-one with requirement items. Any change should be able to answer: which requirement was changed, and which designs were affected?

2. Engineering management of prompts and knowledge.

Design rules, enterprise standards, and common failure cases should be structured into a knowledge base and provided to the agent through retrieval augmentation. They should not all be written into a one-off prompt.

3. Task orchestration and failure recovery.

Every step of a hardware task can fail. The orchestration layer needs retry limits, rollback mechanisms, and conditions for human takeover. This prevents the agent from repeatedly consuming resources on an incorrect path.

4. Observability and cost control.

Agents can generate a large number of tool calls. It is necessary to record the input, output, duration, and result of each call. Monitoring and alerting can notify humans when anomalies occur, while cost analysis helps teams identify inefficient steps.

5. Elastic infrastructure.

Simulation, build, and test tasks have obvious peaks and valleys. Containerizing simulators, firmware build environments, and test executors and running them on demand on a cloud container platform can minimize idle resources. Design data can be stored in object storage with versioning enabled, tasks can be distributed asynchronously through message queues, and runtime logs can be sent to a logging service with monitoring alerts. Together, this forms an observable and scalable agent-based hardware R&D infrastructure.

6. Realistic Constraints: One Successful Prototype Is Not Enough

A successful prototype is encouraging, but moving from prototype to a manufacturable and trustworthy product still requires clearing several barriers.

1. The gap between simulation and the physical world.

Audio performance depends heavily on the acoustic structure between the microphone and enclosure, tooling precision, and unit-to-unit variation. These factors are difficult to model completely in simulation. RF antennas, high-speed interfaces, and power integrity also require real measurements. Expert judgment cannot be fully replaced in these areas.

2. Reliability and lifecycle.

Consumer electronics must pass reliability tests such as high- and low-temperature cycling, damp heat, drop, and vibration. Component temperature grades, service life, and supply lead times must also be confirmed early in the design. Otherwise, a product may be “buildable once but not for years.”

3. Compliance and certification.

Product launch is constrained by electromagnetic compatibility, electrical safety, radio spectrum management, and material environmental regulations in each country or region. The agent can convert standards into design constraints, but certification tests can only be performed by qualified laboratories.

4. Intellectual property and data compliance.

The model may generate structures or circuits highly similar to existing designs, and open-source libraries and reference designs may have their own license terms. Enterprises need to isolate sensitive drawings on the input side and perform similarity checks on the output side. Voice-assistant products involve voice collection and transmission, so they must follow privacy regulations, minimize data collection, provide transparent notice, and ensure secure storage.

5. Security and supply chain.

Third-party components introduced by the agent may contain vulnerabilities. If firmware update channels lack signature verification, they may become an attack surface. Component selection must also assess end-of-life risk and establish alternate-part plans.

6. Roles and responsibility.

When designs are generated by agents, the role of engineers shifts from “executor” to “specification definer, reviewer, and validator.” The core question is: who is responsible for the final product? The answer remains human: the design owner who signs off on release.

7. Conclusion: Expanding Boundaries and Redefining Roles

The biggest change demonstrated by this case is not that the agent “can write code.” It is that the agent begins to take on end-to-end complex engineering tasks: understanding intent, making decisions, using tools, validating results, and adjusting after failure. When this capability extends from code to circuit boards and mechanical parts, many methods developed in software engineering can be transferred to hardware:

• Use requirement traceability to ensure the team is building the right thing;
• Use continuous integration practices to ensure the team builds it correctly;
• Use review gates to ensure humans remain accountable for the result.

A successful prototype does not mean the system is mature. Moving from “one working prototype” to “a stable delivery line” still requires solving multiple engineering problems, including simulation accuracy, reliability, certification, supply chain management, and responsibility boundaries.

However, the way hardware R&D is organized is likely to change:

• Design cycles may shorten significantly;
• Multidisciplinary collaboration will be coordinated more often by agents;
• Engineers will spend more time on requirement definition, architecture decisions, validation systems, and quality control.

The real competitive advantage will no longer depend only on who has the most “generation capability.” It will depend on who can combine agent-generated output with rigorous engineering validation. Teams that can reliably, controllably, and repeatably turn ideas into deliverable products will be the main beneficiaries of this shift.