Bei Gottlieb bauen wir KI-Agenten für Physical Engineers – Menschen, die Strahltriebwerke, medizinische Geräte und Fertigungssysteme entwerfen. Und wir haben etwas Unbequemes gelernt: Das Handbuch für den Aufbau von Software-Agenten funktioniert nicht, wenn die Konsequenzen physisch sind.
Der Grund offenbart etwas Grundlegendes darüber, was Physical Engineering von Software Engineering unterscheidet – und warum der Aufbau von Agenten für diesen Bereich ein völliges Umdenken erfordert.
Das Problem: Ein Asset vs. Fünf Assets
Im Software Engineering gibt es im Wesentlichen ein kritisches Asset: den Code.
Ein Push zu GitHub, und Sie haben 95 % des Wertes erfasst. Ihre Codebasis enthält die vollständige Spezifikation, das ausführbare Artefakt, die Versionshistorie und die Möglichkeit, das System überall zu replizieren.
Im Physical Engineering funktioniert das nicht so.
Fragen Sie einen Maschinenbauingenieur: Die CAD-Dateien machen vielleicht 25 % des Assets aus. Um tatsächlich ein Strahltriebwerk zu fertigen, benötigen Sie fünf kritische Assets:
1. Die Zeichnungen (was gebaut werden soll) – CAD-Dateien, Spezifikationen, Toleranzen, Montagepläne
2. Die Prozessdokumentation (wie es gebaut werden soll) – Fertigungsparameter, Montageabfolgen, Wärmebehandlungszyklen, Qualitätsprüfpunkte
3. Die Werkzeuge (Produktionsmittel) – kundenspezifische Formen, Spannvorrichtungen, Halterungen, CNC-Programme, Testgeräte
4. Die Testdaten (Beweis, dass es funktioniert) – Validierungsergebnisse, Fehleranalysen, zerstörende Prüfungen, behördliche Zertifizierungen
5. Die Fachkompetenz (institutionelles Wissen) – die erfahrenen Ingenieure, die "einfach wissen", was funktioniert
Hier ist die entscheidende Erkenntnis: Selbst mit perfekten CAD-Dateien können Sie eine Turbinenschaufel nicht replizieren.
Die Turbinenschaufeln von GE-Strahltriebwerken sind einkristalline Superlegierungsgussteile. Die Materialzusammensetzung ist in Patenten veröffentlicht. Wettbewerber wissen genau, was es ist. Aber sie können es nicht herstellen, weil der Prozess das Asset ist – Temperaturrampen, Abkühlsequenzen, Ofenatmosphäre. Dieses Wissen wurde über Jahrzehnte entwickelt.
Dies schafft ein fundamentales Spannungsfeld: Wissen im Physical Engineering ist über fünf Asset-Typen verteilt, von denen keiner allein ausreicht. Software konzentriert alles im Code.
Warum dies traditionelle KI-Agenten an ihre Grenzen bringt
Die meisten KI-Agenten-Architekturen setzen das Software-Modell voraus: Code ist die Wahrheit, Iteration ist günstig, Rollback ist einfach.
Aber als wir Agenten für physische Ingenieure bauten, stießen wir sofort auf Probleme:
Problem 1: Das Wissen ist nicht an einem Ort
Ein Ingenieur fragt: "Wie sieht der Wärmebehandlungszyklus für 17-4 PH Edelstahl aus?"
Die Antwort steht nicht in den CAD-Dateien. Sie befindet sich in:
- Prozessdokumentation (Lieferantenspezifikationen)
- Testdaten (Validierungsberichte aus früheren Projekten)
- Fachkompetenz ("wir haben das 2019 versucht und es ist gescheitert, weil...")
- Werkzeugbeschränkungen (unser Ofen kann diese Temperatur nicht erreichen)
Traditionelles RAG (Retrieval-Augmented Generation) setzt voraus, dass Dokumente die Antwort enthalten. Im Physical Engineering erfordert die Antwort eine Synthese über alle fünf Asset-Typen hinweg.
Problem 2: Fehler haben physische Konsequenzen
Ein Agent schlägt vor, Aluminium 6061-T6 anstelle von 7075-T6 zu verwenden. Der Code funktioniert perfekt. Aber:
- 6061 hat eine um 40 % geringere Festigkeit
- Das Bauteil versagt unter Last
- Der 50.000 $-Prototyp wird zerstört
- Das Projekt verzögert sich um 6 Wochen
Man kann ein maschinell bearbeitetes Teil nicht rückgängig machen. Man kann einen fehlgeschlagenen Belastungstest nicht patchen. Physische Iterationen kosten 10.000 $ bis 1 Mio. $ und dauern Wochen.
Problem 3: Das kritische Wissen ist "Tribal Knowledge"
Das wertvollste Ingenieurwissen ist nirgendwo dokumentiert:
- "Die Materialzertifikate dieses Lieferanten sind unzuverlässig"
- "Diese Toleranz ist theoretisch erreichbar, aber praktisch unmöglich"
- "Die Zeichnung sagt, verwende Methode A, aber jeder weiß, dass Methode B tatsächlich funktioniert"
Ein auf Dokumenten trainierter Agent übersieht das institutionelle Wissen, das dafür sorgt, dass Dinge in der Produktion tatsächlich funktionieren.
Die Gottlieb-Architektur: Fünf-Asset-Agent-System
Unsere Architektur ist vom Fünf-Asset-Modell inspiriert.
Multi-Modaler Wissensgraph
Anstelle von traditionellem RAG über Dokumente pflegen wir einen Wissensgraphen mit fünf Knotentypen:
- Zeichnungen – CAD-Dateien, Stücklisten, Montagepläne
- Prozess – Fertigungsspezifikationen, Lieferantendokumente, Arbeitsanweisungen
- Werkzeugbau – Anlagenkapazitäten, Vorrichtungsdesigns, CNC-Programme
- Tests – Validierungsergebnisse, Fehleranalysen, Materialzertifikate
- Expertise – Ingenieur-Annotationen, Erfahrungswissen, Entscheidungslogik
Wenn ein Ingenieur fragt: "Können wir dieses Material ersetzen?", dann:
- Ruft der Agent die Zeichnung ab (Geometrie und Toleranzen)
- Prüft er die Prozessdokumente (Qualifizierungsstatus des Lieferanten)
- Fragt er Werkzeugbeschränkungen ab (können unsere Anlagen dieses Material bearbeiten?)
- Überprüft er Testdaten (haben wir dieses Material schon einmal validiert?)
- Zeigt er Expertise-Knoten auf (was haben erfahrene Ingenieure über ähnliche Substitutionen dokumentiert?)
Die Antwort synthetisiert alle fünf Assets, nicht nur Dokumente.
Validierung gegen physische Constraints
Agenten für Software Engineering validieren gegen Code. Unsere Agenten validieren gegen die physische Realität:
Symbolic Constraint-Prüfung:
- Materialdatenbanken (tatsächliche Festigkeit, keine KI-Schätzungen)
- Toleranz-Stack-up-Analyse (geometrische Mathematik, keine Annäherung)
- Abgleich mit regulatorischen Anforderungen (exakte Compliance, nicht "klingt richtig")
Multi-Modell-Verifizierung für riskante Entscheidungen:
- Designänderungen: Zwei LLMs müssen unabhängig voneinander zustimmen, plus symbolischer Validator
- Materialsubstitutionen: Abgleich mit Materialdatenbank UND historischer Fehlerbibliothek
- Prozessmodifikationen: Validierung gegen Physiksimulation, nicht nur textbasierte Argumentation
Human-in-the-Loop für irreversible Aktionen:
- Bestellung von Werkzeugen im Wert von >50.000 $ → erfordert Genehmigung
- Freigabe von Zeichnungen für die Fertigung → erfordert Abzeichnung durch einen Fachingenieur
- Designänderungen nach dem ersten Serienteil → erfordert Review
Dies spiegelt wider, wie physische Ingenieure tatsächlich arbeiten: günstige Analyse im Vorfeld, teure Validierung, bevor physische Ressourcen gebunden werden.
Erfassung von institutionellem Wissen
Das schwierigste Problem: Erfahrungswissen zu erfassen, bevor es das Unternehmen verlässt.
Unser Ansatz:
- Decision Trace Logging: Jedes Mal, wenn ein Ingenieur einen Agentenvorschlag überschreibt, erfassen wir das Warum
- Fehler-Annotation: Wenn Prototypen versagen, markieren Ingenieure die relevanten Zeichnungen/Prozesse/Entscheidungen
- Review-Zyklen als Wissensgenerierung: Reviews durch erfahrene Ingenieure optimieren die Agenten
- Kollaborative Verfeinerung: Agenten schlagen vor, Ingenieure korrigieren, Korrekturen werden zu neuen Expertise-Knoten
Beispiel: Ein Agent schlägt eine Schweißsequenz vor. Der Ingenieur sagt: "Nein, schweiße diese Verbindungen zuerst, sonst verzerrt die thermische Spannung die Endmaße." Dies wird zu einem Expertise-Knoten, der mit diesem Geometrietyp verknüpft ist und zukünftige Vorschläge bereichert.
Mit der Zeit ruft der Agent nicht nur Dokumente ab – er akkumuliert das institutionelle Wissen, das erfahrene Ingenieure so wertvoll macht.
Was dies ermöglicht: Der Compound-Effekt
Durch die Berücksichtigung des Fünf-Asset-Modells ermöglichen wir Fähigkeiten, die für traditionelle Agenten unmöglich sind:
Projektübergreifender Wissenstransfer: "Zeige mir jedes Mal, wenn wir Inconel 718 in Hochtemperaturanwendungen verwendet haben" – ruft Zeichnungen, Prozesse, Testdaten und Fehlernotizen aus 10 Jahren Projekten ab.
Lieferantenrisikobewertung: "Dieser Lieferant hat gerade den Besitzer gewechselt" – der Agent zeigt alle Teile dieses Lieferanten, alternative Quellen, vergangene Qualitätsprobleme und Re-Qualifizierungsanforderungen auf.
Schnelle Designiteration mit Sicherheitsleitplanken: Ein Ingenieur skizziert eine Änderung. Der Agent validiert gegen: Zeichnungsstandards, Fertigungskapazitäten, Materialverfügbarkeit, vergangene Fehler bei ähnlichen Änderungen, regulatorische Anforderungen. Schlägt Verfeinerungen vor, noch bevor ein physischer Prototyp entsteht.
Beschleunigtes Onboarding: Ein neuer Ingenieur fragt: "Warum haben wir dieses Lager gewählt?" Der Agent zeigt: die Analyse (Testdaten), die Entscheidungslogik (Expertise-Knoten), die betrachtete Alternative (archivierte Zeichnungen) und die Fertigungsbeschränkung, die ausschlaggebend war (Prozessdokument).
Die tiefere Erkenntnis
Hier ist, was wir gelernt haben: KI-Agenten für das Physical Engineering können nicht nur eine intelligentere Suche sein. Sie müssen modellieren, wie Ingenieurwissen tatsächlich existiert – verteilt, voneinander abhängig und über Jahrzehnte akkumuliert.
Software-Agenten können revolutionär sein, weil Software formbar ist: schnell bereitstellen, Dinge ausprobieren, schnell patchen.
Agenten für das Physical Engineering müssen evolutionär sein: Sie akkumulieren im Laufe der Zeit institutionelles Wissen, ermöglichen schnellere Iterationen innerhalb von Sicherheitsgrenzen und verhindern teure Fehler, bevor sie passieren.
Die Ironie dabei: Dies macht sie defensiver als reine Software-Agenten. Unser "Moat" (Wettbewerbsvorteil) ist nicht das LLM oder der Code – es ist der Fünf-Asset-Wissensgraph, den wir für jeden Kunden aufbauen und der sein institutionelles Wissen in einer abfragbaren, kumulierbaren Form speichert.
Dies ist die Zukunft der KI für physische Industrien: Ingenieure nicht zu ersetzen, sondern ihnen endlich ein System zu geben, das respektiert, wie ihr Wissen tatsächlich funktioniert.
