Refactoring in einsatzgerechter Geschwindigkeit: Ein „Agent Mesh“-Ansatz zur Modernisierung von Altsystemen mit Red Hat AI

Legacy-Software tritt nicht von selbst außer Dienst. Die Software verbleibt in der Produktion und häuft technische Schulden an. Sie widersetzt sich Veränderungen und wird schleichend zu einem Risiko – nicht aufgrund ihrer Funktionen, sondern weil sie neue Anforderungen nicht mehr unterstützt.

Vor dieser Herausforderung stehen führende Systemintegratoren (SIs), die Regierungsbehörden und Industrie unterstützen. In einem Portfolio kritischer Anwendungen verwalten SIs sowie Luft- und Raumfahrtunternehmen veraltete Python- und Java-Codebasen. Diese müssen auf eine moderne, sicherheitsorientierte und unterstützte Basis migriert werden – insbesondere auf Red Hat Enterprise Linux® 10 (RHEL 10).

Es geht nicht nur um ein Software-Upgrade. Es geht darum, die Geschwindigkeit der Softwarebereitstellung und der KI sowie das Sicherheitsniveau beizubehalten, auf die sich staatliche Rechenzentren, Einsatzbereiche in erster Linie oder mobile Systeme in Flugzeugen verlassen.

Für die US-Bundesregierung ist dies nicht nur Theorie. Das KI-Governance-Framework der GSA und das Department of War (DoW, Kriegsministerium) verlangen nun von Behörden und Diensten, verantwortungsvolle KI zu operationalisieren und nicht nur einzuführen. Für Verantwortliche in Verteidigung und Einsatz ist dieser Auftrag kein bloßes Kontrollkästchen für die Compliance. Es ist ein notwendiger Impuls, die Software-Factory zu optimieren, bevor den darin enthaltenen Agenten kritische Aufgaben anvertraut werden. 

Bei einem aktuellen Projekt war eine der festen Anforderungen die vollständige Offline-Kompatibilität. Umgebungen zur Unterstützung der nationalen Sicherheit verfügen konstruktionsbedingt oft über keinen Internetzugang. Abhängigkeiten von einem externen Dienst (GitHub, eine Cloud-API, eine Remote-Paket-Registry) können zu Schwachstellen oder einem Point of Failure werden. Zudem können sie dazu führen, dass das System die Compliance-Vorgaben nicht mehr erfüllt. 

Eine manuelle Modernisierung des Systems war technisch zwar möglich. Der geschätzte Engineering-Aufwand hätte jedoch Jahre in Anspruch genommen, wodurch dies im erforderlichen Umfang nicht praktikabel war. Die Alternative bestand darin, untätig zu bleiben und veraltete Systeme mit zunehmendem Betriebsrisiko weiter zu betreiben. Es stellte sich also die Frage, ob ein dritter Weg existiert: Könnten wir mithilfe von agentenbasierter Automatisierung einen effizienteren Prozess entwickeln? So könnten Engineers die Modernisierung in großem Umfang überwachen, anstatt die einzelnen Schritte manuell auszuführen.

Und das war möglich: Wir haben eine agentenbasierte Plattform mit Red Hat AI und Red Hat OpenShift AI entwickelt.

Das Problem bei der Modernisierung von Legacy-Systemen in großem Umfang

Die Brownfield-Migration – also das Verschieben von echtem Produktionscode im Gegensatz zu einem Greenfield-POC (Proof of Concept) – unterscheidet sich grundlegend von der Entwicklung neuer Systeme. Sie können nicht einfach einen Prompt in eine KI eingeben und die Aufgabe als erledigt betrachten.

Legacy-Codebasen weisen häufig folgende Merkmale auf:

• Veraltete Architekturen: Systeme, die auf Annahmen, Frameworks und Infrastrukturen basieren, welche die technischen Normen einer früheren Ära widerspiegeln.
• Begrenzte oder ungleichmäßige Testabdeckung: Große Teile der Codebasis entstanden, bevor das automatisierte Testen zum Standard wurde.
• Implizite Verhaltensverträge: Abhängigkeiten zwischen Modulen und Services, die in der Praxis zwar bestehen, aber nie formal dokumentiert oder erzwungen wurden.
• Kumulierte technische Schulden: Schichten von Workarounds, veralteten Bibliotheken und Kompatibilitäts-Fixes, die im Laufe der Zeit Teil des Produktionssystems wurden.

Bei Missionen zur nationalen Sicherheit ist die Bedeutung von Fehlern nicht abstrakt. Eine fehlgeschlagene Migration zerstört nicht nur eine App. Sie kann einen Workflow zum Erliegen bringen, eine Mission verzögern oder eine Sicherheitslücke in einer Infrastruktur schaffen, die Personen schützt.

Dies ist genau die Umgebung, in der große, universelle Frontier-Modelle, die hinter einer Cloud API ausgeführt werden, keine Option sind. Sie können keinen sensiblen Code an einen externen Endpunkt senden. Sie können ein unvorhersehbares Inferenzverhalten in großem Umfang nicht tolerieren. Selbst wenn Sie eine Verbindung zu Cloud Frontier-Modellen herstellen könnten, lässt sich der Token-Umfang und der Rechenaufwand nicht rechtfertigen, wenn sich Anfragen zu langen Argumentationsketten über riesige Parameterbereiche ausweiten. Bei einem Migrationsumfang, bei dem Systeme Millionen von Codezeilen enthalten, bedeutet dies schnell Latenz, Infrastrukturkosten und ein erhöhtes operatives Risiko.

Warum kleine, effiziente Modelle das richtige Instrument sind

Bei den meisten KI-Anwendungen ist der Instinkt, nach dem größten verfügbaren Modell zu greifen. Mehr Parameter, mehr Kontext, bessere Antworten. In isolierten, kritischen Umgebungen mit begrenzten Ressourcen versagt diese Logik schnell. Große Frontier-Modelle verursachen häufig übermäßige Latenzzeiten, unvorhersehbare Argumentationsschleifen und erhebliche GPU-Speicheranforderungen, die in kontrollierten Infrastrukturen schwer zu unterstützen sind.

Small Language Models (SLMs) eignen sich gut für agentische Workflows, da diese Systeme eine zuverlässige, wiederholbare Ausführung und Antworten mit geringer Latenz erfordern und nicht nur reine Modellskalierung. Kleinere Modelle können ein schnelles, deterministisches Verhalten liefern, das sich gut für Automatisierungsaufgaben wie Tool-Calling, Orchestrierung und strukturiertes Denken eignet. Sie lassen sich zudem einfacher per Fine Tuning anpassen und lokal betreiben. Dies ermöglicht Teams, eine Vielzahl domänenspezifischer Agenten bereitzustellen, ohne auf externe Endpunkte angewiesen zu sein. Mit anderen Worten: Wenn ein Modell nur eine Domain gut „kennt“, wird die Wahrscheinlichkeitsverteilung präziser und es neigt dazu, häufiger dieselbe Antwort zu geben.

Dennoch haben unsere Tests gezeigt, dass die Modellfähigkeit weiterhin stark mit der Kontextlänge und der Parameteranzahl korreliert, insbesondere bei Code-Migrationsaufgaben, die das Verständnis großer Softwaresysteme erfordern. Die Modelle, die in frühen Tests gut abschnitten, waren Varianten von Llama 4 und Claude-Modellen. Dies lag vor allem an ihren sehr großen Kontextfenstern (> 256.000 Token) und ihrer starken Argumentationsfähigkeit. Umgekehrt stellten wir fest, dass Claude unkomplizierte Engineering-Aufgaben manchmal zu komplex analysiert. Dies führt zu unnötig langen Argumentationsketten, welche die Token-Nutzung und Latenz erhöhen. Bei einem Migrationsumfang führt dieses Verhalten schnell zu erheblichen Computing-Kosten.

Aus diesem Grund führen wir Meta Maverick derzeit lokal aus. Aufgrund der GPU-Speicheranforderungen der größeren Modelle führen wir zudem parallele Tests mit Mistral-Modellen durch. Wir bewerten zudem Llama 4 Scout neu, das eine gute Leistung erbringt, aber in der aktuellen Umgebung ebenfalls die Grenzen der verfügbaren Rechenleistung erreicht.

Als praktische Übergangslösung haben wir eine hybride Modellstrategie implementiert. Diese nutzt kleinere Modelle und refaktorisiert gleichzeitig Workflows, um auftretende Kontexteinschränkungen zu mildern.

Unsere aktuelle Modellauswahl für das Agent Harness:

• mistralai/Devstral-Small-2-24B-Instruct: Für Coding-Agenten vorgesehen. Kontextfenster von 256.000 Token, starke Leistung bei Coding-Benchmarks, optimiert für Software-Analysen und Refactoring-Aufgaben.
• mistralai/Ministral-3-14B-Reasoning: Für Agenten ohne Coding-Fokus vorgesehen. Kontextfenster von 256.000 Token, effektiv für strukturiertes Denken, Abhängigkeitsanalysen und die Orchestrierung in Migrations-Workflows.

Zusätzlich zu den Agenten-Modellen verwendet das System spezielle Modelle für die Indizierung und den Abruf von Wissen:

• gpt-oss-120B: Dieses Modell erstellt den GraphRAG-Wissensgraph, der die globale Struktur der Codebasis darstellt.
• intfloat/e5-mistral-7B-instruct: Einbettungsmodell für die GraphRAG-Indizierung und den Vektorabruf.

Das waren keine Kompromissentscheidungen. Auf der Basis der verfügbaren Computing-Umgebung handelte es sich um sinnvolle Engineering-Entscheidungen. Die Kontextbeschränkungen sind eine Funktion der GPU-Kapazität, nicht eine Einschränkung der Architektur selbst. Mit der Skalierung der Infrastruktur können auch das Agent Harness und die Modellauswahlstrategie skalieren.

Die Agent Mesh-Architektur: Ein agentisches „Harness of Harnesses“ basierend auf OpenShift AI

Das Herzstück dieser Plattform ist ein agentisches Harness: ein modulares Orchestrierungs-Framework, das mehrere spezialisierte KI-Agenten koordiniert, die jeweils für einen bestimmten Teil des Migrations-Workflows verantwortlich sind. Dieses Harness wird auf OpenShift AI ausgeführt und nutzt vLLM für eine effiziente Modellinferenz mit niedriger Latenz. Im Laufe der Zeit entwickelt sich dieses Muster zu einem sogenannten Agent Mesh – einer Architektur aus mehreren Systemen, in der mehrere agentische Workflows zusammenarbeiten, Aufgaben koordinieren und den Status in komplexen Modernisierungsprogrammen teilen können.

Die Architektur leistet heute Folgendes:

Coding-Agenten – unterstützt von Devstral – analysieren Legacy-Python 2- oder Java-Quellcode, identifizieren veraltete APIs, generieren durch Refactoring überarbeitete Äquivalente und erstellen Charakterisierungstests, die das ursprüngliche Verhalten erfassen, bevor sich etwas ändert. Sie übersetzen nicht nur die Syntax, sie arbeiten auch daran, die Verhaltensabsicht beizubehalten.

Nicht codierende Agenten – unterstützt von Ministral – führen Reasoning-Aufgaben im gesamten Workflow durch, einschließlich Dependency Mapping, Migrationsplanung und Fortschrittsverfolgung. Eine deterministische Orchestrierungslogik regelt den Ausführungsfluss, sodass Agenten die Koordination von Migration, Validierung und Blockierung sowie die nächsten Schritte übernehmen.

Ein benutzerdefinierter Tracking-Management-Agent übernimmt die Integration mit GitLab (und kann in nicht vernetzten Umgebungen vollständig ausgetauscht werden). Bei dieser Komponente handelt es sich um vollständig überprüfbaren Code und nicht um eine Black Box. Dadurch können Unternehmen das Harness in ihre bestehenden Entwicklungs- und Governance-Systeme integrieren.

Das Harness selbst ist auf Modularität und Austauschbarkeit ausgelegt und kombiniert benutzerdefinierte Agenten mit Open Source-Agenten wie OpenCode. Auf die Frage von Unternehmen, ob das System eine Black Box ist, fällt die Antwort nuanciert aus: Die LLM-Inferenzschicht ist, wie jedes neuronale Netz, von Natur aus undurchsichtig. Allerdings sind Orchestrierungslogik, Agentencode, Ausgaben und Entscheidungspfade vollständig nachverfolgbar, auditierbar und inspizierbar, was für Unternehmen mit DoW-Sicherheitsanforderungen von entscheidender Bedeutung ist.

vLLM, das in OpenShift AI als Inferenz-Engine dient, ist eine wichtige Voraussetzung. Effiziente Inferenz ist mehr als eine Performance-Optimierung – in Umgebungen mit begrenzten GPU-Ressourcen ermöglicht sie erst Workflows mit mehreren Agenten. Dank der optimierten Bereitstellung von vLLM kann die Plattform die iterativen, mehrstufigen Reasoning Loops verarbeiten, die für Migrations-Workflows erforderlich sind, ohne die Rechenressourcen mit einer einzelnen Aufgabe zu überlasten.

Wenn zusätzliche agentische Harnesses für verwandte Aufgaben wie Tests, Sicherheitsüberprüfungen, Dokumentationserstellung oder Deployment-Validierung entstehen, können diese über das breitere Agent Mesh miteinander verbunden werden und ermöglichen so eine koordinierte Automatisierung in gesamten Modernisierungs-Pipelines.

Der Migrations-Workflow: Zuerst Python, dann Java

Die erste Phase dieses Projekts zielt auf die Migration von Python 2 zu Python 3 ab, die sowohl als konkrete Leistung als auch als Validierung des Frameworks dient. Python 2 erreichte 2020 das Ende seines Lebenszyklus. Systeme, die noch immer damit arbeiten, weisen ungepatchte Schwachstellen auf und erhalten keine Upstream-Unterstützung. Für Regierungs- und Unternehmenssysteme stellt dies kein theoretisches Risiko dar.

Unsere in Tests validierte Hypothese lautet, dass die Migrationskosten mit der Komplexität externer Abhängigkeiten steigen. Anwendungen, die eng an veraltete Drittanbieterpakete gebunden sind, erfordern für eine saubere Migration deutlich mehr Agent-Iterationen. Dies floss in das Modelldesign ein: weniger agentische Teilaufgaben pro Flow, engere Geltungsbereiche pro Iteration sowie mehr deterministische Validierungsschritte dazwischen.

Das 30-Tage-Ziel: 80 % Testabdeckung, keine GitLab-Abhängigkeit erforderlich, validierte funktionale Äquivalenz zwischen Python 2- und Python 3-Versionen.

Abbildung 1: Agentischer Softwarefabrik-Workflow von codierenden Agenten, nicht codierenden Agenten und Tools auf OpenShift AI.

Die 30/60/90-Tage-Roadmap wechselt dann zur Java-Migration mit Fokus auf OpenJDK- und Corretto-Versionen (7, 8, 11, 17, 21) in Richtung Java 25. Dabei unterscheiden sich die Migrationspfade, je nachdem, ob die Zielumgebung RHEL 8 oder RHEL 9/10 ist. Dabei handelt es sich weder um einen magischen Knopfdruck noch um eine Universallösung. Das agentische Framework dient als Ausgangspunkt. Jeder darin enthaltene Agent ist speziell für eine bestimmte Aufgabe im Migrations-Workflow konzipiert. Dies ermöglicht die Erweiterung auf Java, ohne das Framework von Grund auf neu entwickeln zu müssen.

Messen, was wirklich wichtig ist: Brownfield-KPIs

Viele KPIs für die agentische und herkömmliche Softwareentwicklung sind für die Greenfield-Entwicklung konzipiert. Sie gehen davon aus, dass Sie die Architektur kennen, Zugriff auf die Dokumentation haben und etwas Neues entwickeln. Sie belohnen Schnelligkeit.

Bei der Brownfield-Legacy-Migration ist Schnelligkeit ohne Korrektheit kein Erfolg, sondern erzeugt technische Schulden in KI-Geschwindigkeit.

Das KPI-Framework, das wir für dieses Projekt definiert haben, orientiert sich an 3 Fragen:

Funktioniert es? Rate der funktionalen Äquivalenz, Erfolgsquote bei Integrationstests, Änderungsfehlerquote. Dies sind Go/No-Go-Metriken. Wenn der umgestaltete Code bei identischen Eingaben keine mit dem Original identischen Ausgaben erzeugt, spielt alles andere keine Rolle.

Verstehen wir, wie es funktioniert? Akzeptanzrate der Entwickelnden, Testabdeckungs-Delta, Migrationsabschlussrate. Eine Migration ist noch nicht abgeschlossen, wenn lediglich der Code läuft. Sie ist erst abgeschlossen, wenn die verantwortlichen Entwickelnden den Code lesen, ihm vertrauen und ihn warten können.

Kann das Team langfristig die Verantwortung dafür übernehmen? Vertrauenswert der Entwickelnden, Zeit bis zum ersten Beitrag, Kapazitätsgewinn der Entwickelnden. Die maßgebliche Kennzahl für den ROI (Return on Investment) sind nicht die Token-Kosten pro Aufgabe. Es geht darum, wie viel Zeit das Engineering-Team von repetitiven Migrationsaufgaben zurückgewinnt, um sich auf wertvollere Beiträge konzentrieren zu können.

Geschwindigkeitsmetriken – Durchsatz, Iterationslatenz, Agentenaktionen pro Minute – gehören auf ein Engineering-Dashboard zur Systemoptimierung. Sie haben in einer Programmüberprüfung als Maßeinheit für Erfolg nichts verloren.

Was mit Red Hat AI und OpenShift AI möglich ist

Ohne eine Plattform, die dies tatsächlich unterstützt, funktioniert nichts davon. OpenShift AI bietet die Basis für alles, was hier beschrieben wird:

• Modellbereitstellung mit vLLM: Effiziente, skalierbare Inferenz für die Codierungs- und Reasoning-Modelle, auf denen das Agent Harness basiert.
• Workflows zur Modellanpassung: Unterstützung von Fine Tuning, LoRA und Quantisierung für Modelle, die in Umgebungen mit begrenzten Ressourcen ausgeführt werden müssen.
• Unterstützung für getrennte Cluster: Die Plattform ist für den Betrieb in Umgebungen ohne Internetzugang konzipiert, was hier eine Grundvoraussetzung darstellt.
• Audit-Protokollierung und Beobachtbarkeit: Die von den Stakeholdern geforderte Rückverfolgbarkeit und Erklärbarkeit ist direkt in die Plattform integriert und nicht nur nachträglich hinzugefügt.
• Modulare, containerisierte Architektur: Agenten sind containerisiert, austauschbar und über die bestehende OpenShift-Infrastruktur bereitstellbar, mit der Systemintegratoren, Luft- und Raumfahrtunternehmen sowie Bundesbehörden bereits vertraut sind.

Abbildung 2: Komponenten und Funktionen zur Erstellung von Agenten mit Red Hat AI.

Die Ergänzung von RHEL 10 als Ziellaufzeitumgebung ist kein Zufall. RHEL 10 bietet Sicherheitshärtung, aktualisierte Laufzeitunterstützung für modernes Python und Java sowie die von Regierungssystemen erforderliche Betriebszuverlässigkeit. Die Migration auf dieses System ist nicht nur eine Entscheidung für den Software-Lifecycle, sondern auch für die Sicherheit und Einsatzbereitschaft.

Das übergeordnete Muster: Agent Mesh über verschiedene Einsatzbereiche hinweg

Dieses Projekt ist ein Beispiel für ein Modell, das sich voraussichtlich in der Verteidigungsindustrie, in Bundesbehörden und in der Wirtschaft allgemein wiederholen wird. Der Bestand an Legacy-Software ist umfangreich. Die Engineering-Ressourcen für eine manuelle Migration sind nicht in dem Maße verfügbar, wie es die Problemstellung erfordert. Zudem verringern sich die Sicherheitsspielräume für den Betrieb nicht unterstützter Software.

Agentische KI auf einer Plattform wie OpenShift AI ist ein Kraftmultiplikator. Sie ermöglicht es einem qualifizierten Engineering-Team, die Migration einer Codebasis in einem Bruchteil der Zeit zu überwachen, deren manuelle Modernisierung Jahre dauern würde. Dies geschieht mit der Genauigkeit und Nachverfolgbarkeit, die kritische Umgebungen erfordern.

In diesem Modell koordinieren Agent Harnesses spezialisierte Agents, um einzelne Modernisierungsaufgaben durchzuführen. Wenn sich diese Strukturen auf angrenzende Funktionen ausweiten (z. B. Tests, Sicherheitsüberprüfungen, Deployment-Validierung), bilden sie ein Agent Mesh. Dabei handelt es sich um eine Harness-of-Harnesses-Architektur, die komplexe Engineering-Workflows in großen Softwarebeständen koordiniert.

Die Agenten führen repetitive Aufgaben aus. Engineering-Teams übernehmen die Architektur, die Überwachung, die Agentenbewertungen und die Ausnahmebehandlung. Diese Arbeitsteilung stellt das Modell dar.

Kleine Modelle. Effiziente Inferenz. Modulare Agenten. Isolierte Abläufe. Zielorientierte Systemmodernisierung.

Abschließende Überlegung

Frontier-Modelle sind außergewöhnliche Reasoning-Engines. Speziell entwickelte agentische Plattformen sind Einsatztools.

Für Behörden geht es nicht darum, den neuesten KI-Trend zu übernehmen. Es geht darum, über die nötige Infrastruktur und KI-Funktionen zu verfügen, um kritische Systeme sicher, modern und einsatzbereit zu halten.

Wir entwickeln sie mit Red Hat AI.

Mehr erfahren

• Red Hat AI
• Red Hat OpenShift AI