Agentic Electrical Engineering For PCB Design

You can ask a language model for a PCB and get something that looks convincing.

That is the problem.

Electrical engineering has too many quiet failure modes for "looks right" to be enough. A board can have the right-looking microcontroller symbol and still miss the boot pins. It can show a regulator and still have no current margin. It can include a PCB antenna module and still route copper through the keepout. It can pass a casual visual inspection and fail the first time someone tries to program it.

Software agents improved first because software already had a working environment for agents. Code sits in repositories. Dependencies are declared. Tests run. Logs explain failure. Patches can be reviewed. CI gives the agent a wall to bounce against.

PCB design has partial versions of those pieces. They are scattered across PDFs, reference schematics, forum posts, EDA libraries, distributor pages, CAD files, and engineer memory. The missing layer is the bridge between source documents and EDA tools.

The short version:

Agentic electrical engineering needs a shared repository of source-traced component contracts, reusable circuit blocks, and validator rules. The agent should use that repository to produce a review package before it tries to produce a board.

Abstract

This paper proposes a practical harness for AI-assisted PCB design. The harness starts with a curated component repository, not a chat interface. It turns datasheet facts into component contracts, turns common circuit patterns into reusable application blocks, and runs deterministic checks before a human engineer reviews the result.

The immediate goal is narrow: help an agent produce a reviewable first pass for common embedded circuits. A useful first target is an ESP32-WROOM-32E subsystem with 3.3 V power, reset handling, boot/programming pins, UART programming, antenna keepout, footprint review, and a bill of materials with open assumptions clearly marked.^{1Espressif Systems, ESP32-WROOM-32E & ESP32-WROOM-32UE Datasheet v2.0, accessed 2026-06-01. https://documentation.espressif.com/esp32-wroom-32eesp32-wroom-32uedatasheeten.pdf}

The main claim is simple. AI agents will become useful in electronics when they can work through five linked objects:

1. Requirements: what the user wants the circuit to do.
2. Component contracts: sourced facts about parts, pins, power, packages, and constraints.
3. Application blocks: known circuit patterns such as USB-C power, 3.3 V regulation, USB-UART programming, or an ESP32 minimal subsystem.
4. Validators: checks that catch missing fields, unsupported assumptions, bad pin use, incomplete BOM roles, and EDA rule failures.
5. Review packages: the artifact an engineer inspects before fabrication.

The aim is a toolchain that makes the agent's electrical reasoning inspectable before anyone treats the output as a board.

Keywords

Agentic electrical engineering; AI PCB design; component schema; electronics design automation; EDA; KiCad; CircuitJSON; atopile; ESP32; datasheet parsing; AI hardware design; LLM agents; schematic generation; design-rule checking; embedded systems.

The Useful Mental Model

Think of the harness as a translation layer.

A component contract is a datasheet fact turned into something an agent can check.

The contract only needs the facts that decide whether the part can be used safely in a circuit: voltage range, pin roles, boot behavior, thermal notes, layout keepouts, package mapping, sourcing status, and the source behind each claim.

The rest of the paper explains why this layer is missing, what other projects have already found, and how Lyon Industries should build the first useful version.

What Other Projects Have Found

The work already happening in AI electronics falls into four groups.

Commercial EDA tools

Cadence Allegro X AI treats PCB layout as a search and optimization problem. It explores design variations, evaluates them with routing and analysis tools, and uses cloud compute to speed the loop.^{2Cadence, Allegro X AI for Generative System Design, accessed 2026-06-01. https://www.cadence.com/enUS/home/resources/white-papers/allegro-x-ai-for-generative-system-design-wp.html} That is useful once a design already has a schematic, constraints, footprints, and board intent.

Synopsys is moving toward agent-style EDA workflows with step-level actions, multi-agent flows, adaptive optimization, and higher autonomy in semiconductor design.^{3Synopsys, Synopsys Announces Expanding AI Capabilities for its Leading EDA Solutions, 2025-09-03, accessed 2026-06-01. https://investor.synopsys.com/news/news-details/2025/Synopsys-Announces-Expanding-AI-Capabilities-for-its-Leading-EDA-Solutions/default.aspx} That shows where enterprise EDA is going. This paper focuses on the open embedded-board workflow.

Flux Copilot adds AI assistance inside a PCB design environment and claims access to schematics, components, electrical connections, and BOM context.^{4Flux, Flux: AI-Powered PCB Design Assistant, accessed 2026-06-01. https://www.flux.ai/Copilot} Quilter focuses on automated placement and routing after the designer supplies a schematic and starter board file.^{5Quilter, Introduction, accessed 2026-06-01. https://docs.quilter.ai/using-quilter/introduction}

The lesson: commercial tools are working on assistants, layout, and proprietary design flows. The open gap sits earlier in the chain: trusted component and block data that any agent can use.

Research prototypes

PCBSchemaGen is directly relevant. It frames schematic generation as a constraint problem across analog, digital, and power signals, with real packages and pin limits. It uses an LLM agent, datasheet-derived knowledge graph, and constraint-guided synthesis.^{6Huanghaohe Zou, Peng Han, Emad Nazerian, and Alex Q. Huang, PCBSchemaGen: Constraint-Guided Schematic Design via LLM for Printed Circuit Boards (PCB), arXiv:2602.00510, 2026. https://arxiv.org/abs/2602.00510}

CircuitLM reports the failure modes clearly: models hallucinate components, violate physical constraints, and produce outputs that tools cannot read. Its answer is a multi-agent pipeline grounded in a curated component database, with deterministic electrical rule checking and an LLM review layer.^{7Khandakar Shakib Al Hasan, Syed Rifat Raiyan, Hasin Mahtab Alvee, and Wahid Sadik, CircuitLM: A Multi-Agent LLM-Aided Design Framework for Generating Circuit Schematics from Natural Language Prompts, arXiv:2601.04505, 2026. https://arxiv.org/abs/2601.04505}

SchGen focuses on representation. Native schematic files can be verbose and geometry-heavy, so SchGen uses a semantic code representation with pin-name-based wiring and relative placement.^{8SchGen: PCB Schematic Generation with Semantic-Grounded Code Representations, arXiv:2605.30345, 2026. https://arxiv.org/abs/2605.30345}

OmniSch looks at schematic understanding. Its benchmark shows that multimodal models still struggle with fine-grained grounding, layout-to-graph conversion, global connectivity, and tool-augmented visual search.^{9Microsoft Research, OmniSch: A Multimodal PCB Schematic Benchmark For Structured Diagram Visual Reasoning, accessed 2026-06-01. https://www.microsoft.com/en-us/research/publication/omnisch-a-multimodal-pcb-schematic-benchmark-for-structured-diagram-visual-reasoning/}

The research direction is consistent: better prompts are useful, but reliable electronics agents need structured parts, constraints, and tool-readable outputs.

Open hardware data

CommonCircuits is building a normalized open circuit dataset from public PCB designs. Its quality flags are the right ones: parses cleanly, schematic and layout netlists match, libraries resolve, DRC status is known, fabrication files exist, and license status is usable.^{10CommonCircuits, The open dataset layer for AI-native electronics design, accessed 2026-06-01. https://www.commoncircuits.org/}

Open Schematics provides raw schematic files, images, component lists, JSON, YAML, project names, descriptions, and formats, mostly from KiCad projects. Its limitations are exactly what a harness has to handle: mixed quality, incomplete metadata, and inconsistent naming.^{11Open Schematics Dataset, Hugging Face dataset card, accessed 2026-06-01. https://huggingface.co/datasets/Ju-C/open-schematics}

The lesson: broad datasets are valuable, but the first production-grade harness should start smaller. Fifty well-modeled components are more useful than five thousand weak records.

Code-native electronics

KiCad already supports command-line ERC, DRC, BOM export, netlist export, Gerbers, and other operations that can run in CI-style workflows.^{12KiCad, Command-Line Interface documentation, accessed 2026-06-01. https://docs.kicad.org/master/en/cli/cli.html}

CircuitJSON, tscircuit, and atopile point toward a more software-like electronics workflow. CircuitJSON gives circuits a JSON representation that can support schematics, PCBs, BOMs, Gerbers, SPICE, and warnings.^{13tscircuit, Circuit JSON Specification, accessed 2026-06-01. https://github.com/tscircuit/circuit-json} tscircuit brings electronics into a TypeScript/React-style workflow.^{14tscircuit repository, accessed 2026-06-01. https://github.com/tscircuit/tscircuit} atopile treats electronics as declarative modules with interfaces, units, tolerances, assertions, validation, and KiCad integration.^{15atopile repository, accessed 2026-06-01. https://github.com/atopile/atopile}

The harness should keep a neutral component and block layer, then map into KiCad, CircuitJSON, tscircuit, or atopile as needed.

What Is Missing

The missing layer is a trusted design substrate for agents.

Plainly:

The agent needs a way to answer simple questions before it draws anything:

• Which pins are power, strap, programming, analog, RF, or internal-use?
• What support parts are required for the common operating mode?
• Which footprint is official, reviewed, guessed, or inherited from a library?
• Which layout rules can destroy the design if ignored?
• Which claims came from the datasheet?
• Which claims came from a reference design?
• Which claims still need human review?

The harness only needs to model the common blocks well enough to avoid obvious board-killing mistakes.

That is the practical wedge. Build a small, trustworthy substrate for common embedded electronics. Then let agents use it.

The Proposed Harness

The proposed harness has four first-class pieces:

1. A component repository.
2. A block repository.
3. A validator CLI.
4. An agent skill that interviews the user, composes a design, and returns a review package.

The core loop is simple:

interview_user()
write_requirements()
retrieve_components_and_blocks()
compose_design_plan()
emit_tool_readable_artifacts()
run_validators()
return_review_package()

The first output should be a review package before any manufacturing package.

The review package should include:

• interpreted requirements,
• selected components,
• selected blocks,
• generated nets or circuit representation,
• BOM roles and alternates,
• validator output,
• source citations,
• open assumptions,
• and human-review gates.

Requirements File

The harness starts by making the user's intent explicit.

{
  "intent": "battery powered Wi-Fi temperature logger",
  "interfaces": ["USB programming", "I2C sensor", "3.3 V power"],
  "constraints": {
    "board_stage": "first_pass_review",
    "fabrication_allowed": false,
    "human_review_required": true
  }
}

This file is small on purpose. It gives the agent enough structure to search the repository and enough boundaries to avoid pretending the design is ready for fabrication.

Component Contracts

A component contract is the sourced record for a part.

The contract should include:

A minimal shape might look like this:

{
  "manufacturer": "Espressif Systems",
  "mpn": "ESP32-WROOM-32E",
  "type": "wireless_mcu_module",
  "power": {
    "rail": "3V3",
    "min_v": 3.0,
    "max_v": 3.6
  },
  "constraints": [
    {
      "id": "boot_mode_gpio0_gpio2",
      "type": "strap_pin_rule",
      "check": "custom_schematic_rule",
      "source": "espressif_esp32_wroom_32e_datasheet_2025"
    }
  ],
  "review_status": "agent_extracted_unreviewed"
}

The exact schema can evolve. The principle stays fixed: every load-bearing field needs a source, confidence level, and review status.

Application Blocks

Most electronics work happens at block level.

Engineers reuse known patterns:

• USB-C power input,
• 3.3 V regulator,
• USB-UART programming,
• ESP32 minimal subsystem,
• I2C sensor connector,
• RS-485 transceiver,
• Ethernet PHY with magnetics,
• motor driver,
• level shifter.

An application block records how parts work together. It should name required components, optional variants, nets, assumptions, layout rules, test points, bring-up notes, and review gates.

For the first sprint, the block should be:

ESP32-WROOM-32E minimal USB-UART Wi-Fi MCU subsystem.

A block record can stay readable:

{
  "block_id": "esp32-wroom-32e-minimal-usb-uart",
  "role": "Wi-Fi MCU subsystem with USB-UART programming",
  "requires": [
    "3v3_regulator_with_current_margin",
    "en_reset_delay",
    "boot_mode_control",
    "uart0_programming_path",
    "antenna_keepout"
  ],
  "outputs": ["kicad_schematic", "bom_roles", "validator_report"],
  "human_review": [
    "regulator sizing",
    "antenna geometry",
    "footprint match",
    "auto-download circuit"
  ]
}

This is the object the agent should retrieve when the user asks for a small Wi-Fi sensor board. The support circuit becomes a maintained block, not a fresh reconstruction every time.

Validator Loop

The validator is the discipline layer.

At first, it can run simple checks:

Later, the same CLI can call KiCad ERC/DRC, compare schematic and layout netlists, inspect footprints, validate BOM roles, check keepout annotations, and emit a machine-readable report.

Start with the review package an engineer can inspect. Treat manufacturing output as a later gate.

That sentence should guide the release gate. The agent can speed up the first pass. The engineer still owns fabrication approval.

Worked Example: ESP32-WROOM-32E

The ESP32-WROOM-32E is a good first part because it is common, useful, and easy to misuse.

The agent can already find "an ESP32 module." The useful question is whether it can preserve the board-design facts that matter.

The workspace for this paper includes a first-pass ESP32 component contract and a small structural stress test. The test checks whether the contract has enough fields for selection, block planning, layout constraints, verification planning, and source traceability. It passed those five groups.

That is a small result. It is also the right kind of result. The schema held the facts an agent needs before schematic generation begins.

Repository Blueprint

The first public repository should be small and strict:

components/
  espressif/esp32-wroom-32e/component.json
  wch/ch340c/component.json
  ti/lm1117/component.json
  microchip/mcp1700/component.json
blocks/
  mcu/esp32-wroom-32e-minimal-usb-uart/block.json
  power/3v3-ldo-basic/block.json
  interface/usb-uart-basic/block.json
rules/
  esp32/boot-straps.rule.json
  esp32/antenna-keepout.rule.json
eda/
  kicad/symbol-maps.json
  kicad/footprint-maps.json
evals/
  tasks/wifi-sensor-node.md
  expected/esp32-minimal-review.json
tools/
  validate-contract
  validate-design

The first release should cover a basic embedded board:

• ESP32-WROOM-32E or 32UE,
• one USB-UART bridge,
• one or two 3.3 V regulators,
• USB-C power input,
• reset and boot control,
• simple I2C sensor block,
• common passives,
• and a two-layer KiCad example.

If that set fails to produce a clean ESP32 subsystem, a larger component database will only hide the weakness.

Evaluation Tasks

The benchmark should look like real electronics work.

The agent fails when it invents a part number, drops a support circuit, hides an assumption, maps a footprint without review status, or claims the board is ready for fabrication before checks and human approval.

Progress means fewer missed support circuits, clearer BOMs, better source traceability, and faster engineering review.

Where MCP And The IDE Fit

An MCP server can be useful once the file and CLI contract is stable. It should expose boring operations: search components, retrieve blocks, validate a design, explain a constraint, and list open review gates.

A browser IDE can also be useful. It should show the requirements, selected blocks, schematic draft, constraints, BOM, source citations, validator output, and approval status.

Both are interfaces. The repository and validator are the source of trust.

Limits And Invalidators

The approach can fail in practical ways:

The strongest test is a head-to-head comparison:

1. Give one agent raw datasheet retrieval.
2. Give another agent the component-contract harness.
3. Ask both to produce the same ESP32 subsystem review package.
4. Compare missing support circuits, wrong assumptions, source traceability, and validator output.

If raw retrieval wins, the harness design is wrong. If the harness wins, the project has earned the next build.

The Next Build

The next build should create the first public repository and make the ESP32 example real enough for inspection.

The deliverables are concrete:

• component schema v0.1,
• ESP32-WROOM-32E component contract,
• USB-UART bridge contract,
• 3.3 V regulator contract,
• ESP32 minimal subsystem block,
• validator CLI,
• one KiCad or CircuitJSON draft output,
• one evaluation task,
• and a review report that names every open assumption.

The practical rule is simple:

An agentic electrical-engineering harness is useful when it can show its work well enough that an engineer can trust the first pass, challenge the weak parts, and decide what to build next.

That is the Lyon Industries version of the opportunity: map the evidence, name the constraints, build the first useful version, and publish enough that a serious peer can inspect it.

Footnotes

1. Espressif Systems, ESP32-WROOM-32E & ESP32-WROOM-32UE Datasheet v2.0, accessed 2026-06-01. https://documentation.espressif.com/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf ↩

2. Cadence, Allegro X AI for Generative System Design, accessed 2026-06-01. https://www.cadence.com/en_US/home/resources/white-papers/allegro-x-ai-for-generative-system-design-wp.html ↩

3. Synopsys, Synopsys Announces Expanding AI Capabilities for its Leading EDA Solutions, 2025-09-03, accessed 2026-06-01. https://investor.synopsys.com/news/news-details/2025/Synopsys-Announces-Expanding-AI-Capabilities-for-its-Leading-EDA-Solutions/default.aspx ↩

4. Flux, Flux: AI-Powered PCB Design Assistant, accessed 2026-06-01. https://www.flux.ai/Copilot ↩

5. Quilter, Introduction, accessed 2026-06-01. https://docs.quilter.ai/using-quilter/introduction ↩

6. Huanghaohe Zou, Peng Han, Emad Nazerian, and Alex Q. Huang, PCBSchemaGen: Constraint-Guided Schematic Design via LLM for Printed Circuit Boards (PCB), arXiv:2602.00510, 2026. https://arxiv.org/abs/2602.00510 ↩

7. Khandakar Shakib Al Hasan, Syed Rifat Raiyan, Hasin Mahtab Alvee, and Wahid Sadik, CircuitLM: A Multi-Agent LLM-Aided Design Framework for Generating Circuit Schematics from Natural Language Prompts, arXiv:2601.04505, 2026. https://arxiv.org/abs/2601.04505 ↩

8. SchGen: PCB Schematic Generation with Semantic-Grounded Code Representations, arXiv:2605.30345, 2026. https://arxiv.org/abs/2605.30345 ↩

9. Microsoft Research, OmniSch: A Multimodal PCB Schematic Benchmark For Structured Diagram Visual Reasoning, accessed 2026-06-01. https://www.microsoft.com/en-us/research/publication/omnisch-a-multimodal-pcb-schematic-benchmark-for-structured-diagram-visual-reasoning/ ↩

10. CommonCircuits, The open dataset layer for AI-native electronics design, accessed 2026-06-01. https://www.commoncircuits.org/ ↩

11. Open Schematics Dataset, Hugging Face dataset card, accessed 2026-06-01. https://huggingface.co/datasets/Ju-C/open-schematics ↩

12. KiCad, Command-Line Interface documentation, accessed 2026-06-01. https://docs.kicad.org/master/en/cli/cli.html ↩

13. tscircuit, Circuit JSON Specification, accessed 2026-06-01. https://github.com/tscircuit/circuit-json ↩

14. tscircuit repository, accessed 2026-06-01. https://github.com/tscircuit/tscircuit ↩

15. atopile repository, accessed 2026-06-01. https://github.com/atopile/atopile ↩