Bayer Crop Science baut Multi-Agenten-Engine auf Amazon Bedrock AgentCore

Vom Ausführen der Workflows zum Verstehen

Bayer Crop Science lässt Hunderte Konfigurationen von Machine-Learning-Modellen auf Daten aus Genomik, Feldversuchen, Bildmaterial, Umweltbedingungen und Modellergebnissen laufen. Jeder Lauf muss reproduzierbar und kontrolliert ablaufen. Um diese Anforderung zu erfüllen, hat Bayer die Connected Decision Engine (CDE) entwickelt, ein System zum Bereitstellen, Orchestrieren, Überwachen und Wiederverwenden von ML-Workflows für Züchter, Analysten, Forscher, Data Scientists und Data Engineers.

Mit wachsender Nutzung verlagerte sich der Engpass. Nicht mehr das Ausführen der Workflows war die Hürde, sondern ihre Erklärung. Nutzer mussten sich den Kontext aus APIs, Dokumentation, Metadatenspeichern, Dashboards und Logs zusammensuchen und wissen, welches System sie prüfen müssen, um zu erfahren, warum ein Workflow fehlgeschlagen ist oder woher ein Ergebnis stammt.

ADE ist Bayers Antwort darauf. Ein Supervisor-Agent leitet jede Frage an einen Spezialagenten weiter, dieser holt den Kontext aus dem jeweils zuständigen System, und der Nutzer erhält eine Antwort, ohne sich durch den operativen Stack arbeiten zu müssen.

So ist ADE aufgebaut

ADE läuft auf Amazon Bedrock AgentCore. Laut AWS gaben drei Fähigkeiten den Ausschlag: eine verwaltete Laufzeitumgebung, die jede Nutzersitzung isoliert, ein IAM-basierter Tool-Zugriff über AgentCore Gateway, der Authentifizierung und Autorisierung außerhalb des Agentencodes hält, sowie ein Framework-unabhängiges Design, mit dem Bayer seine eigene LangGraph-Orchestrierung und eigene Modelle einsetzen konnte.

Das System besteht aus vier Schichten: der Nutzeroberfläche, der Agenten-Orchestrierung, den Spezialagenten sowie den Tools und Datenquellen, die diese aufrufen. Nutzer greifen über ein React-Web-Frontend auf ADE zu, Anfragen laufen über einen Identity-Proxy für Microsoft Entra ID. GitHub Actions baut die Container-Images der Agenten, überträgt sie an Amazon ECR und stellt sie in der AgentCore-Laufzeit bereit. Bayer entschied sich für LangGraph wegen des expliziten, graphbasierten Kontrollflusses und des Checkpointings für mehrstufige Workflows.

• Zustand und Daten: Amazon DynamoDB speichert den LangGraph-Checkpoint-Zustand, Amazon Aurora PostgreSQL hält Sitzungsdaten, Feedback und Analysen, und Amazon ElastiCache puffert Agentenantworten mit begrenzter Lebensdauer (Time to Live).
• Retrieval: Fachinhalte in Amazon S3 werden mit Amazon Titan Text Embeddings V2 eingebettet und für RAG in Amazon OpenSearch Serverless indexiert.
• Tools: AgentCore Gateway stellt Backend-APIs den Agenten als Model-Context-Protocol-Tools (MCP) bereit. Amazon CloudWatch erfasst die Telemetrie.

In der Produktion betreibt ADE 22 Spezialagenten, die jeweils auf eine Domäne zugeschnitten sind. Der Domain Expert Agent beantwortet konzeptionelle Fragen per RAG, der Operational Agent ruft den aktuellen Workflow-Status und Ergebnisse aus der CDE ab, der Troubleshooting Agent analysiert operative Telemetrie, und der Visualization Agent erzeugt Diagramme oder liefert bestehende Dashboards zurück. Ein kundenspezifisches Muster namens Models as Skill überführt Modellcode und Dokumentation in Skill-Definitionen in einem zentralen Register, sodass Agenten aus der Implementierung eines Modells antworten statt aus generischem Modellwissen.

Designentscheidungen und Unterstützung durch AWS

Bayer arbeitete mit AWS Unified Operations zusammen, das einen festen Technical Account Manager und einen Domain Specialist Engineer für generative KI stellte. Beide nahmen an drei technischen Standups pro Woche teil und wirkten als Teil des Arbeitsteams an Designentscheidungen mit, während Bayer die Verantwortung für die Architektur und das letzte Wort behielt.

AWS beschreibt fünf Designentscheidungen aus dem Projekt. Drei davon sind im hier vorliegenden Quelltext enthalten:

• Orchestrierungszustand auslagern. Sitzungen der AgentCore-Laufzeit bewahren den Kontext innerhalb des Lebenszyklus einer Sitzung, sind aber kein dauerhafter Speicher. ADE schreibt LangGraph-Checkpoints nach DynamoDB, damit Graphen nach Scale-out-Ereignissen, Neustarts oder Sitzungsgrenzen fortgesetzt werden können.
• Identitätsgrenzen trennen. Entra ID bleibt die Quelle der Nutzeridentität, IAM autorisiert Aufrufe zwischen Diensten, und die ausgehende Autorisierung von AgentCore Gateway regelt den Zugriff auf nachgelagerte CDE-Dienste. Eine Lambda-Funktion als Request-Interceptor führt eine individuelle Validierung durch. Laut AWS häufen sich Identitätsfehler in Agentensystemen an den Übergängen zwischen Nutzer-, Agenten- und Tool-Identität.
• Modellauswahl als Schnittstellenvertrag behandeln. Bayer prüfte eine neuere Modellversion mit aktiviertem Reasoning-Modus, doch die Kombination aus Tool-Nutzung und strukturierter Ausgabe, auf die ADE angewiesen ist, war mit der Implementierung der Agenten nicht kompatibel. Das Team blieb für das Release beim bisherigen Modell.

Eine vierte Entscheidung betrifft die Kontrolle der Tool-Oberfläche. Die CDE verwaltet mehr als 500 Modellkonfigurationen, und ein eigener MCP-Server pro API hätte zusätzlichen Aufwand bei Bereitstellung, Authentifizierung und Versionsverwaltung verursacht. Stattdessen registriert ADE OpenAPI-Spezifikationen bei AgentCore Gateway, das die REST-Operationen als MCP-Tools bereitstellt.

Was das für Nutzer bedeutet

Der praktische Gewinn liegt in der schnelleren Diagnose. Fragt ein Züchter, warum ein Phänotypisierungs-Workflow fehlgeschlagen ist, leitet der Supervisor die Frage an den Troubleshooting Agent weiter, der die Telemetrie in CloudWatch und den Status aus der CDE-API über AgentCore Gateway ausliest. Laut dem AWS-Beitrag dauert eine Diagnose, die früher mehr als eine Stunde manueller Log-Suche und Warten auf Support durch Ingenieure erforderte, nun weniger als 10 Minuten.

Für Teams, die Agentensysteme auf AWS aufbauen, liefert die Fallstudie ein konkretes Muster: den Workflow-Zustand außerhalb der Laufzeit speichern, jeder Vertrauensgrenze einen eigenen Identitätsmechanismus geben und ein neues Modell vor dem Austausch gegen die gesamte Tool-Calling-Schnittstelle testen.