Die nächste CAD-Revolution ist keine bessere Texteingabe. Sie beginnt, wenn ein KI-System ein Konstruktionsziel versteht, selbstständig die passenden Werkzeuge auswählt, Änderungen am nativen Modell ausführt, das Ergebnis prüft und aus Fehlern den nächsten Arbeitsschritt ableitet. Genau dieser geschlossene Regelkreis macht aus einem Copiloten einen Konstruktionsagenten.

Die Entwicklung steht noch ganz am Anfang. Trotzdem ist bereits erkennbar, dass sie Computer-Aided Design grundlegend verändern wird: mechanische Konstruktion ebenso wie Stromlauf- und Schaltschrankplanung, Leiterplattenentwicklung und – mit noch höheren Hürden – das Chipdesign. Der entscheidende Wandel liegt nicht darin, dass Ingenieurinnen und Ingenieure künftig weniger wissen müssen. Er liegt darin, dass Wissen, Absicht und Berechnung anders miteinander gekoppelt werden.

Heute übersetzen Menschen eine technische Absicht in eine lange Folge von Menübefehlen, Modellierungsoperationen, Bibliotheksrecherchen, Prüfungen und Korrekturen. Agentisches CAD verschiebt diese Übersetzungsarbeit in eine ausführbare Schleife. Der Mensch formuliert Anforderungen und Grenzen; der Agent plant und bedient Werkzeuge; CAD-Kernel, Regelprüfungen und Simulation liefern belastbare Evidenz; der Mensch behält Verantwortung und Freigabe.

Das klingt nach einem kleinen Unterschied. Tatsächlich ist es ein neues Betriebsmodell für Engineering-Software.

Was „agentisch“ an CAD wirklich bedeutet

Der Begriff wird derzeit großzügig verwendet. Eine nützliche Abgrenzung stammt von Anthropic: Ein Workflow folgt vorgegebenen Codepfaden, während ein Agent den eigenen Prozess und die Verwendung seiner Werkzeuge dynamisch steuert.[1] Übertragen auf CAD ergibt sich eine klare Leiter:

1. Automatisierung führt eine fest programmierte Folge aus: Makro starten, Stückliste erzeugen, Zeichnung exportieren.
2. Assistenz beantwortet Fragen oder schlägt Befehle vor, verändert das Modell aber nicht oder nur nach einem einzelnen, expliziten Auftrag.
3. Generierung erzeugt Geometrie, Code oder einen Entwurf aus Text beziehungsweise Bildern – häufig in einem offenen Durchlauf.
4. Agentisches CAD verfolgt ein Ziel über mehrere Schritte, beobachtet den Modellzustand, ruft CAD- und Prüfwerkzeuge auf, wertet Rückmeldungen aus und revidiert seinen Plan.

Ein generatives Modell kann beispielsweise aus „Baue einen 100 × 60 mm großen Montagewinkel mit vier M5-Bohrungen“ einen Körper erzeugen. Ein Agent fragt zusätzlich nach unklaren Randbedingungen, legt Parameter an, modelliert eine belastbare Feature-Historie, erkennt einen fehlenden Biegeradius, führt eine Kollisions- oder Herstellbarkeitsprüfung aus, korrigiert den Entwurf und legt die finale Zeichnungsableitung zur Freigabe vor.

Der Unterschied ist also nicht primär die Qualität des Sprachmodells. Es ist die Schleife aus Wahrnehmen, Planen, Handeln, Prüfen und Korrigieren. Ein solcher Prozess braucht standardisierte Werkzeugverträge, wie sie MCP mit Tools und Resources unterstützt,[2] sowie mehrschichtige Guardrails statt einer einzelnen Schutzmaßnahme.[3] Ein Harness ist die technische Laufzeit- und Kontrollschicht um das Sprachmodell: Er verwaltet Zustand und Kontext, führt Werkzeugaufrufe kontrolliert aus, setzt Berechtigungen und Grenzen durch, behandelt Fehler und protokolliert den Ablauf.[4] Im Engineering ist diese Schicht mindestens so wichtig wie das Modell selbst.

Formal lässt sich ein CAD-Agent als zustandsbehafteter Prozess ausdrücken. Aus Anforderungen, aktuellem Modellzustand und Beobachtungen wählt seine Policy die nächste Aktion. Das CAD-System überführt diese Aktion in einen neuen Zustand; ein unabhängiger Verifier bewertet anschließend das Ergebnis:

Der Agent beendet die Arbeit nicht dann, wenn die Antwort plausibel klingt, sondern wenn definierte Prüfkriterien erfüllt sind, das Budget ausgeschöpft ist oder eine menschliche Entscheidung nötig wird. Das ist der zentrale Denkfehler vieler Demos: Eine hübsche Geometrie oder ein kompilierendes Verilog-Modul ist noch kein belastbares Engineering-Ergebnis.

Was agentisches CAD nicht ist

Agentisches CAD ist nicht identisch mit Generative Design. Klassisches Generative Design durchsucht einen definierten Lösungsraum unter Last-, Geometrie- und Fertigungsbedingungen und liefert Varianten. Ein Agent kann eine solche Optimierung anstoßen, ihre Ergebnisse vergleichen, Randbedingungen verändern und anschließend Zeichnung, Dokumentation oder Folgeanalysen erstellen. Die Optimierung ist ein Werkzeug im Agentenprozess, nicht der Agent selbst.

Ebenso wenig ist jede Chatleiste ein Agent. Ein Assistent, der die Dokumentation durchsucht, ist nützlich – insbesondere in komplexen CAD-Systemen. Agentisch wird er erst, wenn er autorisierte Aktionen ausführt, deren Resultate liest und daraus weitere Handlungen ableitet. Genau an dieser Grenze bewegen sich viele heutige Produkte.

Von der Absicht zur ausführbaren Spezifikation

Ein CAD-Agent braucht eine maschinenlesbare Definition dessen, was entstehen soll, welche Grenzen gelten und durch welche Evidenz ein Ergebnis als bestanden gilt. Der Schritt von der Demo zum Produktionssystem verlangt strukturierten Intent, Guardrails, Evaluation, Debugging und Human-in-the-loop-Kontrolle.[5]

Eine natürlichsprachliche Aufgabenbeschreibung allein ist zu schwach. Benötigt wird eine versionierte, ausführbare Engineering-Spezifikation aus Anforderungen, Parametern, Geometrie- und Netzregeln, Material- und Fertigungsgrenzen, Normen, zulässigen Aktionen und Prüfkriterien. Im Engineering betrifft das beispielsweise PLM/PDM-Daten, Normen, Lieferantendatenblätter, freigegebene Bibliotheken und Fertigungsregeln. Ein belastbarer Harness braucht deshalb nicht nur Zugriff, sondern klare Eigentümerschaft, Versionen, Snapshots und Tests für diesen Kontext.

Die grafische Arbeitsfläche darf ein erstklassiger Kommunikations- und Beobachtungsraum sein, doch Änderungen sollten über native, typisierte CAD-/EDA-Funktionen erfolgen.[6] Der Canvas erklärt die Absicht; das Objektmodell trägt die technische Wahrheit.

Damit lässt sich der Kernprozess präziser formulieren:

Engineering Intent → ausführbare Spezifikation → Engineering-Kontext und Constraints → Agent Skill → Agent Harness → MCP oder native API → CAD/EDA-System → deterministische Verifikation → Iteration oder Freigabe

Die Zukunft von Agentic CAD ist deshalb keine KI, die zeichnen kann. Es ist ein Engineering-Agent, der einen Entwurf gegen eine ausführbare Spezifikation erzeugt, inspiziert, simuliert, verifiziert und kontrolliert korrigiert.

Die gemeinsame Architektur hinter MCAD, ECAD, PCB und EDA

Die vier Domänen wirken auf den ersten Blick sehr verschieden. MCAD arbeitet mit Skizzen, Geometrie (B-REP), Features und Baugruppen. ECAD arbeitet mit Schaltplansymbolen, Potenzialen, Kabeln, Klemmen und Schaltschränken. PCB-Design verbindet Stromlaufpläne mit Footprints, Kupfer, Lagenaufbauten und Fertigungsregeln. Chipdesign / EDA bewegt sich von Spezifikation und RTL über Verifikation und Synthese bis zu Timing-, Leistungs- und Flächenabschluss.

Die agentische Grundarchitektur ist trotzdem dieselbe:

1. Ein natives, editierbares Artefakt

Ein PNG eines Bauteils, ein trianguliertes Mesh oder ein PDF eines Schaltplans reicht nicht. Professionelles Engineering braucht das native Objektmodell: parametrische Features und Boundary Representation des Objekts im MCAD, logisch verbundene Betriebsmittel im Stromlaufplan, Netze und Footprints auf dem PCB, RTL und Constraints im IC-Flow. Nur dann bleiben Design Intent, Änderbarkeit, Variantenfähigkeit und nachgelagerte Prozesse erhalten.

Das erklärt, warum „Text-to-3D“ nicht automatisch „Text-to-CAD“ ist. Eine visuell passende Oberfläche kann topologisch falsch, nicht wasserdicht, nicht bemaßbar oder nicht regenerierbar sein. Aktuelle Forschung bestätigt die Lücke: Text2CAD-Bench umfasst 600 kuratierte Aufgaben über vier Komplexitätsstufen und berichtet, dass heutige Modelle bei einfachen Geometrien vernünftig arbeiten, bei komplexer Topologie und fortgeschrittenen Features aber deutlich abbauen.[7]

2. Eine schmale, typisierte Werkzeugoberfläche

Ein Agent sollte nicht „irgendwie klicken“. Er braucht Werkzeuge mit eindeutigen Namen, Eingabeschemata, Vorbedingungen und Rückgabewerten: create_sketch, place_component, run_drc, compile_rtl, compare_mass_properties. Der Model Context Protocol (MCP) standardisiert genau diese Art der Verbindung zwischen KI-Anwendung und Werkzeugservern über eine Client-Server-Architektur mit Tools, Resources, Prompts und Benachrichtigungen.[2]

MCP ist dabei kein Qualitätszertifikat. Ein schlecht entworfenes oder zu mächtiges Werkzeug bleibt schlecht oder gefährlich, auch wenn es standardisiert aufgerufen wird. Der Wert liegt in der Entkopplung: CAD-Anbieter oder Integratoren können Fähigkeiten als versionierte Verträge bereitstellen, während Agentenmodelle austauschbar bleiben.

3. Ein Harness, der aus Modellaufrufen einen kontrollierten Prozess macht

Der Harness hält den aktuellen Arbeitsstand, begrenzt Schritte und Kosten, verwaltet Berechtigungen, protokolliert Werkzeugaufrufe und erkennt Schleifen. Er entscheidet außerdem, welche Informationen das Sprachmodell sieht. Bei einem realen Projekt können Stücklisten, Datenblätter, Normenauszüge, Materialtabellen, frühere Varianten und Prüfberichte den Kontext sprengen. Ein robuster Agent lädt daher nicht blind „das ganze Projekt“, sondern stellt pro Schritt eine zielgerichtete Sicht zusammen.

OpenAI empfiehlt für Agentensysteme eine mehrschichtige Absicherung und weist darauf hin, dass einzelne Guardrails nicht genügen.[3] Im CAD-Kontext bedeutet das: Schema-Prüfung der Tool-Argumente, Grenzwerte für Parameter, projektbezogene Zugriffsrechte, transaktionale Änderungen, Undo/Restore-Punkte, deterministische Prüfungen und Freigaben müssen zusammenwirken.

4. Verifikation außerhalb des Sprachmodells

Das Sprachmodell darf Vorschläge machen und Fehlerberichte interpretieren. Es sollte aber nicht allein beurteilen, ob sein eigener Entwurf korrekt ist. Die entscheidende Evidenz kommt aus spezialisierten Systemen:

Die richtige Arbeitsteilung lautet deshalb: Das Sprachmodell plant probabilistisch; der Engineering-Stack prüft deterministisch.

Wie man einen belastbaren CAD-Agenten baut

Zustandsmodell statt Chatverlauf

Der wichtigste technische Schritt ist ein explizites Zustandsmodell. Ein Chatprotokoll ist kein Project State. Ein CAD-Agent braucht mindestens:

• eine unveränderliche Anforderungsbasis mit Quellen und Versionen,
• den aktuellen nativen Dokument- und Revisionsstand,
• ein Ziel- und Constraint-Modell,
• eine Liste geplanter, ausgeführter und zurückgenommener Aktionen,
• Prüfresultate mit Tool-Version, Konfiguration und Zeitstempel,
• offene Annahmen, Risiken und Freigaben.

Eine Aktion sollte als typisierter, auditierbarer Datensatz formuliert sein, beispielsweise:

{
  "tool": "mcad.create_hole_pattern",
  "document_revision": "bracket@r17",
  "arguments": {
    "support_face": "face:mounting_plate/top",
    "count": 4,
    "diameter_mm": 5.5,
    "pitch_circle_mm": 72.0
  },
  "preconditions": ["support_face.planar", "diameter_mm > 0"],
  "approval": "auto_within_sandbox",
  "expected_checks": ["solid_valid", "min_edge_distance >= 2d"]
}

Die semantische Referenz face:mounting_plate/top ist absichtlich wichtiger als eine flüchtige interne Face-ID. In parametrischem CAD ändern sich Topologie und interne Kennungen nach Modelländerungen – das bekannte Topological-Naming-Problem. Ein Agent, der nur rohe IDs speichert, kann beim nächsten Schritt die falsche Fläche bearbeiten. Robuste Integrationen benötigen stabile Semantik, geometrische Signaturen oder eine kontrollierte Neuselektion.

Transaktionen, Diffs und Reversibilität

Jeder Agentenschritt sollte in einer Transaktion laufen:

1. Zustand und Dokumentrevision lesen.
2. Vorbedingungen prüfen.
3. Änderung in Branch, Kopie oder Undo-Scope ausführen.
4. Modell regenerieren und lokale Checks starten.
5. Strukturierten Diff erzeugen: Geometrie, Parameter, Netze, Bauteile oder RTL.
6. Änderung annehmen, reparieren oder vollständig zurückrollen.

„Undo“ ist dabei kein Komfortmerkmal, sondern ein Sicherheitsprimitive. Besonders gefährlich sind teilweise erfolgreiche Aktionen: drei Komponenten wurden korrekt platziert, die vierte schlug fehl, der Agent glaubt aber, der gesamte Schritt sei atomar gewesen. Deshalb müssen Tool-Antworten zwischen success, partial, failed und unknown unterscheiden und betroffene Objekte exakt benennen.

Der Verifier steuert die Schleife

Eine praktische Zielfunktion kombiniert harte Constraints mit Optimierungszielen. Für einen mechanischen Entwurf könnte gelten:

Dabei steht m für die Masse, C für die Kostenabschätzung und T für eine thermische Kennzahl. Verletzungen der Geometrie- und Fertigungsbedingungen werden über große Lambda-Strafgewichte abgebildet. In der Praxis sollten harte Regeln nicht nur als weiche Strafe modelliert werden: Ein Selbstschnitt, ein Kurzschluss oder eine negative Timing-Slack muss den Kandidaten disqualifizieren.

Der Agent erhält anschließend keinen unspezifischen Satz wie „das ist falsch“, sondern strukturierte Evidenz:

check: min_edge_distance
status: failed
objects: hole[2], outer_edge[west]
measured_mm: 7.2
required_mm: 11.0
severity: blocking
suggested_scope: move_pattern_or_reduce_diameter

Je maschinenlesbarer diese Rückmeldung, desto weniger muss das Sprachmodell raten.

Berechtigungen sind domänenspezifisch

Nicht jede Aktion hat dasselbe Risiko. Eine hilfreiche Policy unterscheidet:

• Read: Modell, Eigenschaften, Regeln und Prüfberichte lesen.
• Draft: Vorschläge, Varianten oder Branches erzeugen.
• Modify: ein aktives Dokument innerhalb definierter Grenzen ändern.
• Release: Revision freigeben, PLM-Status ändern oder Fertigungsdaten erzeugen.
• Externalize: Daten an Cloud-Dienste, Lieferanten oder Fertiger übertragen.

Die letzten beiden Klassen sollten standardmäßig menschliche Freigabe verlangen. Dasselbe gilt für Änderungen an sicherheitskritischen Anforderungen, Bauteilsubstitutionen ohne qualifizierte Alternative, Schutzschaltungen, Isolationsabstände oder Sign-off-Constraints. Die Frage lautet nicht „Wie autonom ist unser Agent?“, sondern „Innerhalb welches überprüfbaren Betriebsbereichs darf er autonom sein?“

Beobachtbarkeit: Jeder Schritt muss rekonstruierbar sein

Für einen Produktionsagenten müssen Teams später beantworten können:

• Welches Modell und welche Prompt-/Skill-Version haben entschieden?
• Welche Dokumente und Datenblätter lagen im Kontext?
• Welche Tools wurden mit welchen Argumenten aufgerufen?
• Was änderte sich am nativen Artefakt?
• Welche Prüfungen liefen, mit welcher Version und Konfiguration?
• Warum wurde eine Warnung akzeptiert oder eskaliert?

Ein vollständiger Trace enthält deshalb nicht nur Chattext, sondern Modellrevisionen, Tool-Calls, CAD-Diffs, Check-Artefakte, Laufzeiten, Kosten und Freigabeidentitäten. Das ist die Voraussetzung für Fehleranalyse, Audit und Reproduzierbarkeit.

Testen wie Software – plus Engineering-Evidenz

Ein Agent benötigt Unit-Tests für Tooladapter, Schema-Validatoren und Zustandsübergänge; Komponententests mit simulierten CAD-Antworten; Integrationsläufe gegen echte CAD-Versionen; und wenige, teure End-to-End-Aufgaben mit fachlicher Abnahme. Zusätzlich braucht er ein Domänen-Evalset aus repräsentativen Konstruktionsaufgaben.

Die zentrale Kennzahl darf nicht „gefällt einem Sprachmodell“ sein. Sinnvoller sind:

• Task Success Rate: Anteil vollständig erfüllter Aufgaben nach deterministischen Kriterien.
• First-Pass Yield: Anteil ohne menschliche Reparatur.
• Constraint Violation Rate: Verletzungen pro Aufgabe, nach Schweregrad.
• Human Edit Distance: Umfang der Änderungen bis zur Freigabe.
• Tool Efficiency: erfolgreiche Ergebnisse pro Toolaufruf, Zeit und Rechenbudget.
• Recovery Rate: Anteil korrekt reparierter Fehlerzustände.
• Unsafe Action Rate: unzulässige oder nicht genehmigte Aktionsversuche.

Eine einfache betriebliche Nutzenmetrik kann die Zeitersparnis gegen Nacharbeit und Risiko abwägen:

Ein Agent, der schnell viele Entwürfe produziert, aber erfahrene Prüfer mit Nacharbeit überlastet, hat negativen Wert – selbst wenn seine Demo beeindruckt.

Typische Fehlerbilder

Aktuelle Landschaft: Wo die vier Domänen im August 2026 stehen

MCAD: Von der Hilfe zur nativen Modellaktion

Im mechanischen CAD ist die Entwicklung sichtbar, aber heterogen. Autodesk geht in Fusion bereits in Richtung nativer Modellaktion: Der Autodesk Assistant wird als konversationelle Erfahrung beschrieben, die Informationen findet, Workflows erklärt und Aufgaben per natürlicher Sprache ausführt. Autodesk kennzeichnet Teile wie Text-to-Command und native Geometrieerzeugung allerdings ausdrücklich als Entwicklung beziehungsweise Tech Preview; seit 2026 werden außerdem MCP-gestützte Fusion-Workflows beschrieben.[8] Diese Formulierung ist wichtig: Eine Vorschau ist ein Richtungssignal, keine garantierte Serieneigenschaft.

Siemens führte 2025 den Design Copilot NX als natürlichsprachliche Lern- und Bedienhilfe ein; die damalige Produktbeschreibung betonte vor allem dokumentationsgestützte Anleitung und das Starten genannter Befehle.[9] PTC brachte im Juni 2026 mit Creo 13 einen Creo AI Assistant in die Konstruktionsumgebung.[10]

Im Open-Source-Umfeld wird die Architektur besonders transparent. FreeCAD bietet eine umfangreiche C++- und Python-API,[11] und mehrere Community-Projekte exponieren Teilmengen davon über MCP. Ein aktuelles Beispiel beschreibt 32 Werkzeuge für parametrisches Modellieren, Prüfung, CAM und Export, weist aber zugleich auf Plattformgrenzen und den weitreichenden Zugriff auf FreeCADs Python-Umgebung hin.[12] Solche Projekte sind wertvolle Laboratorien für Tooldesign, Berechtigungen und Evals – aber kein Beleg dafür, dass beliebige Industriebauteile bereits autonom konstruiert werden können.

Der Engpass im MCAD ist nicht das Erzeugen eines Blocks mit Bohrungen. Schwierig sind robuste Feature-Historien, stabile Referenzen nach Änderungen, komplexe Freiformgeometrie, Baugruppenbeziehungen, Toleranzen, Material- und Fertigungswissen sowie die Überführung von „sieht richtig aus“ in „ist freigabefähig“. Genau deshalb ist die Entwicklung erst am Anfang.

CAD WSCAD zeigt, wie schnell Routine agentisch wird

In der elektrischen Planung ist WSCAD ein besonders greifbares Beispiel. Das Unternehmen stellte ELECTRIX AI 2024 mit einem integrierten AI Copilot vor. Laut Hersteller kann dieser unter anderem Designs prüfen, Stücklisten erzeugen sowie Makros und Komponenten platzieren.[13] Die Release Notes für ELECTRIX AI 2026 nennen konkrete Aktionen wie den Import von Teilen aus wscaduniverse.com per Befehl und die automatische, sequenzielle Positionierung eingefügter Pfadmakros.[14]

Das ist mehr als eine Suchhilfe: Natürliche Sprache löst strukturierte Aktionen im Projekt aus. Gleichzeitig sollte man die beworbenen Produktivitätswerte – etwa „bis zu 99 Prozent schneller“ – als Herstellerangaben und nicht als unabhängigen, domänenübergreifenden Benchmark lesen.[13]

Warum ist diese Domäne so geeignet? Viele Aufgaben sind repetitiv und stark strukturiert: Betriebsmittel auswählen, Makros einsetzen, Querverweise pflegen, Listen erzeugen, Texte übersetzen, Klemmen- und Schaltschrankdaten ableiten. Gleichzeitig existieren zahlreiche prüfbare Regeln. Das ergibt einen guten Agentenraum: hoher Routineanteil, klarer Projektzustand, viel vorhandenes Domänenwissen und messbare Resultate.

Die harte Grenze bleibt die fachliche Verantwortung. Leiterquerschnitt, Schutzkonzept, Selektivität, Kurzschlussfestigkeit, Wärmehaushalt und normative Konformität dürfen nicht allein auf einer sprachlich überzeugenden Antwort beruhen. Ein sinnvoller WSCAD- oder ECAD-Agent muss Unternehmensstandards und Projektrichtlinien mit Versionsstand zitierbar laden, Berechnungswerkzeuge aufrufen und Unsicherheit eskalieren.

PCB-Design: Zwischen industriellen EDA-Plattformen und KiCad-Labor

Professionelle PCB-Plattformen wie Altium Designer, Siemens PADS Professional, Cadence OrCAD X und Proteus verbinden Entwurf, Bibliotheken, Unternehmensdaten und Prüfwerkzeuge in unterschiedlicher Tiefe. Für Agentic CAD ist jedoch nicht allein dieser Funktionsumfang entscheidend. Ein Agent benötigt kontrollierbare Aktionen auf einem zugänglichen Objektmodell, einen eindeutig versionierten Projektzustand und maschinenlesbare Rückmeldungen aus ERC, DRC, Simulation, SI/PI und DFM.

Hier besteht noch eine deutliche Lücke: In den mit Stand August 2026 geprüften öffentlichen Produktunterlagen dieser vier kommerziellen Systeme ist weder ein nativer MCP-Server noch ein durchgängiger agentischer PCB-Workflow dokumentiert. Beschrieben werden Skripting, klassische Prozessautomatisierung, KI-Assistenten und einzelne AI-gestützte Funktionen.[15][16][17][18][19] Das ist nicht dasselbe wie ein Agent, der den Entwurfszustand selbstständig inspiziert, Werkzeuge auswählt, Änderungen kontrolliert ausführt, Prüfergebnisse bewertet und innerhalb vorgegebener Grenzen iteriert. MCP könnte dafür eine standardisierte Werkzeugschnittstelle liefern, wäre allein aber noch kein agentischer Workflow.[2]

Altium Designer besitzt eine interne Automatisierungsschicht. Skripte können über X2-Objektmodelle Schaltplan- und PCB-Objekte lesen oder ändern, Prozesse ausführen und beispielsweise Netze oder Fertigungsdaten exportieren.[15] Das ist eine brauchbare Integrationsbasis, aber keine vom Hersteller dokumentierte MCP- oder Agentenschnittstelle. Ein externer Agent bräuchte versionsgeprüfte Adapter, klar begrenzte Transaktionen, Rollback und unabhängige DRC- beziehungsweise Freigabeprüfungen. Ein in einer Desktop-Sitzung laufendes Skript bildet noch keinen stabilen, mehrbenutzerfähigen Agentenbetrieb.

Siemens PADS Professional Premium verbindet Schaltplan und Layout mit Cloud-Arbeitsbereichen, Rollenverwaltung, Versionsmanagement, Bauteilrecherche, ECAD/MCAD-Austausch per IDX und integrierter DFM-Analyse.[16] Parallel beschreibt Siemens sein EDA AI System als portfolioübergreifende Architektur mit kontextbezogener natürlicher Sprache, multimodalem EDA-Datenbestand, RAG, Zugriffskontrollen sowie lokaler oder cloudbasierter Bereitstellung.[17] Das zeigt die Richtung einer künftigen Orchestrierungsschicht. Für PADS ist in den ausgewerteten Unterlagen jedoch noch kein nativer MCP-Zugang und kein geschlossener Agentenlauf von der Anforderung über Entwurfsänderungen bis zur verifizierten Platine beschrieben.

Cadence OrCAD X integriert PSpice-Simulation in den Schaltplan sowie Sigrity-X-Aurora-Prüfungen für Signal- und Power-Integrity, DFM, Live-Fertigungsregeln, Bibliotheken und Designversionen. Die Plattform skaliert in das Allegro-X-Umfeld; Cadence nennt AI-gestütztes Layout und constraint-basierte Automatisierung als Entwicklungsrichtung.[18] Damit sind wichtige Feedback-Engines für spätere Agentenschleifen vorhanden. Die öffentliche Produktbeschreibung dokumentiert aber weder einen OrCAD-X-MCP-Server noch einen autonomen Workflow, der diese Engines selbstständig orchestriert und ein Board freigabefähig schließt.

Proteus setzt einen anderen Schwerpunkt. Die Plattform verbindet Schaltplan, PCB-Layout und VSM-Simulation kompletter Embedded-Systeme. Proteus 9.2 ergänzt KI-gestützte Bauteilerzeugung; die EDAi-Werkzeuge und ProPilot erhalten nach Herstellerangaben direkten Zugriff auf Schaltpläne, Simulationsdaten und Embedded-Code und können mit unterschiedlichen Sprachmodellen verbunden werden.[19] Das unterstützt kontextbezogene Assistenz, Analyse und Fehlersuche. Dokumentiert ist jedoch weder eine native MCP-Schnittstelle noch eine autonome Schleife aus Schaltungsänderung, Firmwareanpassung, Simulation, Korrektur und unabhängigem Sign-off.

Die professionellen Plattformen besitzen somit viele Voraussetzungen für Agentic Engineering, aber noch keine öffentlich dokumentierte, standardisierte Agentenschicht. Ihre proprietären Objektmodelle, Lizenzstufen, Datenbankversionen, Desktop-Sitzungen und optionalen Cloud-Dienste machen zusätzliche Adapter, Berechtigungskonzepte, Audit-Trails und Freigabegates erforderlich. Ein realistischer Einstieg sind eng begrenzte Aufgaben wie Bibliotheksprüfung, BOM-Anreicherung, DRC-Triage, Varianten aus freigegebenen Templates, Fertigungsartefakte oder Review-Berichte mit Objektlinks.

KiCad steht am anderen Ende des Spektrums. Open Source, GNU-GPL-Lizenz, native Projektdateien und Unterstützung für Windows, Linux und macOS senken die Eintrittsschwelle. Dadurch ist KiCad in DIY-, Maker-, Ausbildungs- und Forschungsumfeldern leicht einsetzbar und als Experimentierplattform besonders sichtbar. Es wäre dennoch falsch, es als reines Hobbywerkzeug einzuordnen: Die offizielle Mission priorisiert ausdrücklich die Anforderungen professioneller Elektronikentwickler, während die Bedienung auch für neue Nutzer zugänglich bleiben soll.[20]

Für Experimente bietet KiCad Kommandozeilenwerkzeuge, Regelprüfungen und eine wachsende API. KiCad 10 erschien am 20. März 2026 und brachte unter anderem Varianten, PCB-Designblöcke und einen grafischen Editor für Designregeln.[21] Die offizielle IPC API verbindet externe Prozesse über Protocol Buffers und lokale IPC mit einer laufenden KiCad-Instanz. In KiCad 9 und 10 kommuniziert sie jedoch nur mit der GUI; der Abdeckungsgrad wird schrittweise erweitert, und Clients müssen Timeouts sowie synchrone Verarbeitung berücksichtigen.[22] KiCad dokumentiert damit eine externe API, aber keinen offiziellen MCP-Server. Seine Offenheit erleichtert es der Forschung und Community jedoch, eigene Agentenadapter zu erproben.

Diese Offenheit nutzt die Forschung bereits. pcbGPT erzeugt editierbare KiCad-Schaltpläne aus natürlicher Sprache, verankert Bauteilauswahl in Bibliotheken und Datenblättern und kombiniert strukturelle sowie semantische Validierung. Auf 20 Embedded-Aufgaben fällt die Leistung bei schweren Aufgaben ab; die Autoren halten Expert Review ausdrücklich weiterhin für notwendig.[23] PCBWorld koppelt Agenten über native KiCad-Operationen an den Router und bewertet 679 reale Open-Source-Boards mit acht engine-geprüften Metriken einschließlich DRC-Feedback.[24] Der entscheidende Fortschritt ist nicht der Screenshot, sondern dass der EDA-Kernel Teil der Evaluation wird.

KiCad ist deshalb derzeit vor allem das offenere Agentic-CAD-Labor, nicht bereits die fertige agentische PCB-Plattform. Auch hier muss ein Agent den Anwendungszustand respektieren, Operationen versionsabhängig ausführen und Änderungen gegen native Prüfengines absichern. Erst wenn begrenzte Aufgaben reproduzierbar, reversibel und auditierbar funktionieren, sollte ein Agent Platzierung oder Routing selbstständig verändern.

Chipdesign: Verilog ist nur der Anfang

Im Chipdesign werden die Chancen größer – und die Konsequenzen von Fehlern drastischer.

LLMs können Verilog schreiben, Testbenches erzeugen und Toolskripte erklären. Doch syntaktisch gültiges RTL sagt wenig über funktionale Korrektheit, Synthesizierbarkeit, Timing, Fläche, Leistung oder Verifikationsabdeckung. Eine Untersuchung zu AutoChip koppelte Sprachmodelle iterativ an Compiler- und Simulationsergebnisse. Toolfeedback verbesserte die Ergebnisse nicht bei allen Modellen konsistent; im besten Fall stieg die Zahl erfolgreicher Designs um 5,8 Prozent, während eine geschickte Modellmischung Kosten senkte.[25] Die Lehre ist nicht „Verilog ist gelöst“, sondern: EDA-Feedback kann helfen, wenn Modell, Schleife und Kostenstrategie gemeinsam evaluiert werden.

Bei der physischen Implementierung zeigt AlphaChip eine andere Form von KI-gestütztem Design. Google DeepMind behandelt Floorplanning als sequenzielle Platzierungsaufgabe mit Reinforcement Learning und berichtet, dass die Methode für Blöcke mehrerer TPU-Generationen eingesetzt wurde.[26] Das ist hochwirksame spezialisierte Optimierung – aber kein allgemeiner Sprachagent, der einen Chip autonom von der Spezifikation bis zum Tape-out entwickelt.

Die aktuell deutlichste Bewegung in Richtung agentischer EDA kommt von den etablierten Toolketten. Synopsys beschreibt seinen Copilot für Wissenszugriff, RTL- und formale Testbench-Erzeugung sowie EDA-Workflows.[27] Im Juli 2026 kündigte das Unternehmen mit AMD und Microsoft zwei autonome Workflows zur Debug- und Implementierungs-Closure zur Evaluation an. Frühe, vom Anbieter berichtete Ergebnisse nennen 25 bis 40 Prozent kürzere Debug-Zyklen; der Zugang ist als Evaluation ausgewiesen, nicht als allgemeiner Nachweis vollautonomen Chipdesigns.[28]

Die Berichte von der DAC 2026 zeigen jedoch, dass „agentische EDA“ inzwischen über RTL und einzelne Closure-Schritte hinausreicht. EE Times fasst drei bestimmende Themen zusammen: Agenten als neue Orchestrierungsschicht, Multiphysik als zentralen Engpass und Standards als Voraussetzung für Interoperabilität.[29] Langlaufende Agenten sitzen dabei über bestehenden Verifikations-, Implementierungs- und Analysewerkzeugen, lesen Logs, wählen den nächsten Lauf und halten den Kontext über Tage. Ihre Qualität bleibt damit an die Physikmodelle und Solver gebunden, die sie aufrufen. Bei Chiplets und 3D-ICs müssen thermische, mechanische, elektromagnetische und Power-Integrity-Effekte deshalb früh in die Exploration einfließen, statt erst kurz vor dem Sign-off sichtbar zu werden.

Gleichzeitig wird Offenheit zu einer technischen Notwendigkeit. Für die letzte PPA-Optimierung müssen Teams je nach Block unterschiedliche Werkzeuge und Anbieter kombinieren können. Maschinenlesbare Standards wie Accelleras Functional Safety Language sowie Package Assembly Design Kits können Sicherheitsabsicht, Coverage-Hooks, Packaging-Regeln und zertifizierte Prüfabläufe so kodieren, dass Agenten sie über Tool- und Unternehmensgrenzen hinweg nachvollziehbar verwenden.[29] Der Agent ersetzt damit nicht den Sign-off; er verbindet spezialisierte Engines, Datenmodelle und Evidenz zu einem prüfbaren Ablauf.

Siemens EDA – aus der Mentor-Tradition – konkretisiert dieses Muster mit Questa One und dem Fuse EDA AI Agent. Die im Juli 2026 angekündigte Erweiterung mit NVIDIA soll domänenspezifische Agenten über Synthese, Verifikation, physische Implementierung, Custom-IC-, 3D-IC- und PCB-Flows orchestrieren und Entscheidungen fortlaufend gegen deterministische, physikbasierte EDA-Engines prüfen.[30][31] NVIDIA NeMo Gym, Nemotron-Modelle, OpenShell und CUDA-X adressieren dabei Training und Reasoning, abgesicherte Laufzeitumgebungen mit Zugriffskontrolle und Audit-Trails sowie die Beschleunigung langer Toolläufe. Siemens berichtet für die Bibliothekscharakterisierung von mehr als zehnfach kürzeren Durchlaufzeiten und fünf- bis zehnfach geringeren Tokenkosten; die erweiterten Funktionen sind allerdings für kommende Produktversionen angekündigt und bleiben Herstellerangaben.[31]

In dieser Domäne wird die Agentenarchitektur wahrscheinlich zuerst bei klar begrenzten Closure- und Verifikationsaufgaben reifen: Fehler clustern, Root Causes untersuchen, Assertions oder Tests vorschlagen, Toolparameter variieren, Multiphysik-Checks anstoßen und den nächsten Lauf planen. Tape-out-Freigaben, Sicherheitsziele und Sign-off bleiben deterministische, streng kontrollierte Prozesse. Der belastbare Fortschritt liegt nicht in einem „autonomen Chipdesigner“, sondern in Agenten, die längere Abläufe sicher orchestrieren und jeden Zwischenschritt mit Engineering-Evidenz absichern.

Was sich grundsätzlich verändern wird

Die Benutzeroberfläche wird vom Befehlsraum zum Absichtsraum

Menüs verschwinden nicht. Experten werden weiterhin Geometrie direkt bearbeiten, Constraints setzen und Reports lesen. Aber die primäre Einheit der Interaktion verschiebt sich vom Befehl zum Ziel: „Reduziere die Masse um acht Prozent, ohne Eigenfrequenz, Gussradien und vorhandene Schnittstellen zu verletzen.“ Der Agent übersetzt dieses Ziel in einen überprüfbaren Plan und zeigt, was er warum ändern will.

CAD-Modelle werden ausführbare Wissensobjekte

Ein gutes Modell enthält künftig nicht nur Geometrie oder Netze, sondern maschinenlesbare Absichten, Quellen, Annahmen, Prüfregeln und Freigaben. Design Intent wird vom informellen Erfahrungswissen zur operativen Schicht. Das erhöht den Wert guter Namenskonventionen, sauberer Parameter, modularer Makros, gepflegter Bibliotheken und versionierter Requirements massiv.

Konstruktion und Verifikation rücken zusammen

Heute sind „modellieren“ und „prüfen“ häufig getrennte Phasen. Der Agent braucht dagegen nach fast jedem relevanten Schritt Feedback. Simulation, DRC, ERC, Lint, Formal, DFM und Kostenmodelle werden zu Werkzeugen in einer kontinuierlichen Suchschleife. Wer die Prüfpipeline nicht automatisiert hat, kann auch den Agenten nicht zuverlässig automatisieren.

Engineering-Organisationen werden Agentenplattformen betreiben

Ein Unternehmensagent kann nicht allein aus einem Modellabo bestehen. Er benötigt Toolserver, freigegebene Wissensquellen, Identitäts- und Rechtemanagement, Observability, Evaluationsdaten, Sandbox-Infrastruktur und Release-Prozesse. Das erzeugt eine neue Schnittstelle zwischen Konstruktion, CAE/EDA, PLM, IT-Sicherheit und AI Engineering.

Praktische Takeaways: So beginnt man ohne Autonomie-Theater

1. Wählen Sie eine eng begrenzte, häufige Aufgabe. Gute Kandidaten sind Stücklisten, Dokumentation, DRC-Triage, Varianten aus bekannten Templates, Parameteränderungen oder Prüfberichtszusammenfassungen. Schlechte erste Kandidaten sind sicherheitskritische Neuentwicklungen mit unklaren Anforderungen.

2. Definieren Sie Erfolg vor dem Modell. Legen Sie 30 bis 100 repräsentative Aufgaben, harte Constraints, erlaubte Abweichungen und Reviewkriterien fest. Ohne Evalset optimieren Sie auf Demos.

3. Bauen Sie zuerst Read- und Verify-Tools. Ein Agent, der den Modellzustand zuverlässig lesen und prüfen kann, ist bereits wertvoll. Schreibrechte kommen danach, zunächst nur in Branches oder Kopien.

4. Halten Sie Werkzeuge klein und typisiert. Lieber set_parameter(name, value, unit) und run_drc(rule_set) als ein universelles execute_python(code). Mächtige Escape Hatches vervielfachen Risiko und erschweren Evals.

5. Machen Sie jeden Schritt reversibel und sichtbar. Preview, Diff, Undo, Checkpoint und Objektlinks sind keine UI-Details, sondern Trust-Infrastruktur.

6. Trennen Sie Generierung und Prüfung. Verwenden Sie CAD-Kernel, Solver, Regelprüfungen und unabhängige Verifier. Ein zweiter LLM-Call ist kein Ersatz für Physik oder Formalismus.

7. Messen Sie Nacharbeit, nicht nur Geschwindigkeit. Entscheidend ist die Zeit bis zur freigegebenen Lösung. Erfassen Sie First-Pass Yield, Human Edit Distance, kritische Verstöße und Recovery Rate.

8. Steigern Sie Autonomie nur mit Evidenz. Die Reifeleiter führt von Assistenz über einzelne Aktionen zum geschlossenen Regelkreis und erst dann zu begrenzter Autonomie. Jeder Schritt verlangt bessere Tests, feinere Rechte und stärkere Beobachtbarkeit.

Fazit

Agentisches CAD wird die Ingenieurarbeit nicht dadurch verändern, dass ein Chatbot plötzlich „konstruiert“. Es wird sie verändern, weil technische Absicht, Softwareaktionen und Verifikation in einer fortlaufenden, maschinenlesbaren Schleife zusammenfinden.

MCAD zeigt heute den Übergang von Hilfe zu nativen Modellaktionen. WSCAD demonstriert, wie schnell strukturierte elektrische Routinearbeit durch einen Copiloten ausführbar wird. Im PCB-Design macht KiCad durch offene Formate, API und Regelprüfungen agentische Experimente nachvollziehbar; Altium, PADS, OrCAD X und Proteus ergänzen stärker integrierte Daten-, Simulations- und Unternehmensprozesse. Im Chipdesign bewegen sich Synopsys, Siemens EDA und spezialisierte Ansätze wie AlphaChip in Richtung längerer, stärker autonomer Optimierungs- und Closure-Schleifen.

Aber der Maßstab bleibt Engineering, nicht Eloquenz: Ist das Artefakt nativ und editierbar? Sind Annahmen und Quellen sichtbar? Besteht es deterministische Checks? Ist jede Änderung nachvollziehbar und reversibel? Weiß der Agent, wann er stoppen und einen Menschen fragen muss?

Die Unternehmen, die diese Fragen früh beantworten, werden nicht nur schneller konstruieren. Sie werden Engineering-Wissen in eine neue, ausführbare Form überführen. Genau darin liegt das transformative Potenzial – und genau deshalb stehen wir erst am Anfang.

References

[1] „Building effective agents.“ Anthropic. https://www.anthropic.com/engineering/building-effective-agents. Published/updated: 2024-12-19. Accessed: 2026-08-11.

[2] „Architecture overview — Model Context Protocol.“ Model Context Protocol. https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture. Published/updated: 2026-07-28. Accessed: 2026-08-11.

[3] „A practical guide to building agents.“ OpenAI. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/. Published/updated: not listed. Accessed: 2026-08-11.

[4] „The Hitchhiker’s Guide to Agentic AI: From Foundations to Systems.“ Haggai Roitman. arXiv:2606.24937 [cs.AI]. https://arxiv.org/abs/2606.24937. Submitted: 2026-06-22; last revised: 2026-07-27 (v2). Accessed: 2026-08-11.

[5] „AI Native DevCon LDN.“ Tessl. https://tessl.io/events/devcon-ldn-26/. Published/updated: 2026 event page. Accessed: 2026-08-14.

[6] „Web MCP and the Agentic Web.“ Maximiliano Firtman, AI Native DevCon London 2026; Tessl Registry. https://tessl.io/registry/ainativedev/latest-aidevcon-speakers-london-2026/files/talk-firtman-web-mcp-agentic-web/outline.md. Published/updated: 2026-06. Accessed: 2026-08-14.

[7] „Text2CAD-Bench: A Benchmark for LLM-based Text-to-Parametric CAD Generation.“ Liang Wang et al. arXiv. https://arxiv.org/abs/2605.18430. Published/updated: 2026-05-18. Accessed: 2026-08-11.

[8] „Autodesk Assistant: Shaping the Future of Design and Make.“ Autodesk Fusion Blog. https://www.autodesk.com/products/fusion-360/blog/autodesk-assistant-ai/. Published/updated: 2026-07 (updated; day not listed). Accessed: 2026-08-11.

[9] „Siemens brings AI copilot, immersive design and integrated fluid and thermal simulation to NX.“ Siemens. https://news.siemens.com/de-de/siemens-designcenter-nx-summer-2025/. Published/updated: 2025-07-01. Accessed: 2026-08-11.

[10] „PTC Brings AI-Powered Guidance to the Design Environment with Creo 13.“ PTC. https://www.ptc.com/en/news/2026/ptc-brings-ai-powered-guidance-to-the-design-environment-with-creo-13. Published/updated: 2026-06-10. Accessed: 2026-08-11.

[11] „FreeCAD source documentation.“ FreeCAD. https://www.freecad.org/api/. Published/updated: not listed. Accessed: 2026-08-11.

[12] „freecad-mcp: MCP server for FreeCAD — 32 tools for AI-assisted 3D CAD modeling.“ blwfish. GitHub. https://github.com/blwfish/freecad-mcp. Published/updated: not listed. Accessed: 2026-08-11.

[13] „ELECTRIX AI – WSCAD Launches the First AI-Powered Electrical CAD.“ WSCAD GmbH. https://www.wscad.com/en/worlds-first-ai-powered-electrical-cad/. Published/updated: 2024-09-18; updated 2025-08-18. Accessed: 2026-08-11.

[14] „Release Notes | WSCAD ELECTRIX.“ WSCAD GmbH. https://www.wscad.com/en/electrix/release-notes/. Published/updated: continuously updated; ELECTRIX AI 2026 release 2026-02-12. Accessed: 2026-08-11.

[15] „Automating Design Tasks with Scripting.“ Altium Designer Technical Documentation. https://www.altium.com/documentation/altium-designer/scripting. Published/updated: 2023-01-31. Accessed: 2026-08-14.

[16] „PADS Professional Premium.“ Siemens Digital Industries Software. https://eda.sw.siemens.com/en-US/eda-cloud-solutions/pcb/pads/professional-premium/. Published/updated: not listed. Accessed: 2026-08-14.

[17] „EDA AI System.“ Siemens EDA. https://eda.sw.siemens.com/en-US/eda-cloud-solutions/eda-ai-system/. Published/updated: not listed. Accessed: 2026-08-14.

[18] „OrCAD X and PSpice FAQ.“ Cadence. https://www.cadence.com/en_US/home/tools/pcb-design-and-analysis/orcad/faqs.html. Published/updated: not listed. Accessed: 2026-08-14.

[19] „PCB Design and Circuit Simulator Software.“ Labcenter Electronics. https://www.labcenter.com/. Published/updated: not listed. Accessed: 2026-08-14.

[20] „About KiCad.“ KiCad. https://www.kicad.org/about/kicad/. Published/updated: not listed. Accessed: 2026-08-14.

[21] „Version 10.0.0 Released.“ The KiCad Development Team. https://www.kicad.org/blog/2026/03/Version-10.0.0-Released/. Published/updated: 2026-03-20. Accessed: 2026-08-11.

[22] „For Add-on Developers — KiCad IPC API.“ KiCad Developer Documentation. https://dev-docs.kicad.org/en/apis-and-binding/ipc-api/for-addon-developers/index.html. Published/updated: 2026-04-04. Accessed: 2026-08-11.

[23] „pcbGPT: Automatic PCB Schematic Synthesis from Natural Language Requirements.“ Tobias King et al. arXiv. https://arxiv.org/abs/2606.01188. Published/updated: 2026-05-31. Accessed: 2026-08-11.

[24] „PCBWorld: A Benchmark Environment for Engine-Grounded PCB Design Automation.“ Hyungseok Song et al. arXiv. https://arxiv.org/abs/2607.05915. Published/updated: 2026-08-03 (v2). Accessed: 2026-08-11.

[25] „Automatically Improving LLM-based Verilog Generation using EDA Tool Feedback.“ Jason Blocklove et al. arXiv. https://arxiv.org/abs/2411.11856. Published/updated: 2025-03-04 (v3). Accessed: 2026-08-11.

[26] „How AlphaChip transformed computer chip design.“ Anna Goldie and Azalia Mirhoseini, Google DeepMind. https://deepmind.google/blog/how-alphachip-transformed-computer-chip-design/. Published/updated: 2024-09-26. Accessed: 2026-08-11.

[27] „Generative AI for Chip Design.“ Synopsys. https://www.synopsys.com/ai/generative-ai.html. Published/updated: not listed. Accessed: 2026-08-11.

[28] „Synopsys Advances Agentic AI Chip Design with AMD and Microsoft.“ Synopsys. https://investor.synopsys.com/news/news-details/2026/Synopsys-Advances-Agentic-AI-Chip-Design-with-AMD-and-Microsoft/default.aspx. Published/updated: 2026-07-27. Accessed: 2026-08-11.

[29] „Agentic AI, Multi-Physics, and Standards Will Redefine Chips Design.“ Nitin Dahad, EE Times. https://www.eetimes.com/agentic-ai-multi-physics-and-standards-will-redefine-chips-design/. Published/updated: 2026-08-11. Accessed: 2026-08-12.

[30] „Questa One Smart Verification Solution.“ Siemens EDA. https://eda.sw.siemens.com/en-US/ic/questa/. Published/updated: not listed. Accessed: 2026-08-11.

[31] „Siemens advances self-verifying agentic AI workflows for semiconductor and PCB design.“ Siemens. https://news.siemens.com/en-us/siemens-nvidia-dac-2026/. Published/updated: 2026-07-26. Accessed: 2026-08-12.