Entscheidungen in der Pflanzenzüchtung hängen von Daten ab, die sich über Genomik, Feldversuche, Bildmaterial, Umweltbedingungen und Modellausgaben erstrecken. Bayer Crop Science führt hunderte Konfigurationen von Machine-Learning-(ML-)Modellen gegen diese Daten über Nutzpflanzen, Regionen und Teams hinweg aus, und jeder Lauf muss wiederholbar und kontrolliert sein. Um diese Anforderung zu erfüllen, baute Bayer die Connected Decision Engine (CDE), ein System zum Bereitstellen, Orchestrieren, Überwachen und Wiederverwenden von ML-Workflows. CDE gibt Züchtern, Analysten, Forschern, Data Scientists und Data Engineers eine konsistente Möglichkeit, Analysen auszuführen und bewahrt dabei Ausführungshistorie und betriebliche Kontrollen.
Mit wachsender Verbreitung verlagerte sich der Engpass vom Ausführen von Workflows zum Verstehen derselben. Die Erklärung eines Ergebnisses bedeutete, Kontext aus APIs, Dokumentation, Metadatenspeichern, Dashboards und Protokollen zusammenzusetzen. Ein Benutzer, der wissen wollte, warum ein Workflow fehlschlug, was ein Modell tat oder woher ein Ergebnis stammte, musste dennoch wissen, welches System er untersuchen sollte. Um diese Lücke zu schließen, baute Bayer die Agentic Decision Engine (ADE), eine Multi-Agenten-Oberfläche in natürlicher Sprache über CDE. Ein Supervisor-Agent leitet jede Frage an einen spezialisierten Agenten weiter, der Spezialist ruft Kontext aus dem relevanten System ab, und der Benutzer erhält eine Antwort, ohne den operativen Stack durchsuchen zu müssen. In seiner ersten Phase beantwortet ADE etwa 80 Prozent der Benutzerfragen ohne Beteiligung eines Ingenieurs.
ADE läuft auf Amazon Bedrock AgentCore, einem AWS-Service zum Erstellen, Verbinden und Optimieren von Agenten in großem Maßstab mit beliebigen Frameworks oder Modellen. AgentCore ermöglichte es dem Team, sich auf das Agentenverhalten zu konzentrieren, anstatt ein eigenes Agent-Hosting, Sitzungsisolation und eine Tool-Zugriffsschicht zu betreiben. Drei AgentCore-Fähigkeiten bestimmten diese Wahl: eine verwaltete Laufzeit, die jede Benutzersitzung isoliert, IAM-grenzwerter (AWS Identity and Access Management) Tool-Zugriff über AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, die Authentifizierung und Autorisierung außerhalb des Agentencodes hält, und ein frameworkagnostisches Design, das dem Team erlaubte, seine eigene LangGraph-Orchestrierung und Modellwahl einzubringen.
Um den Start vorzubereiten und ADE danach zu betreiben, engagierte Bayer AWS Unified Operations. Das Engagement stellte einen benannten Technical Account Manager (TAM) und einen generativen KI Domain Specialist Engineer (DSE) bereit, die vom Entwurf bis zur Produktion als Verlängerung des ADE-Teams arbeiteten. Der TAM brachte als strategischer Berater von Bayer ein etabliertes Verständnis von Bayers Betriebsmodell und Geschäftsprioritäten mit. Der DSE brachte generative KI-Fachkompetenz auf AWS mit. In drei technischen Standups pro Woche besprach und traf das Team Designentscheidungen. Der DSE baute ein fundiertes Wissen über die ADE-Workload und die Arbeitsweise des Bayer-Teams auf, sodass die technische Beratung sowohl das Verhalten der AWS-Services als auch Bayers Kontext widerspiegelte. Dieser Beitrag folgt diesem Weg: die ADE-Architektur, fünf während des Baus getroffene Designentscheidungen, die Arbeiten zur Vorbereitung der Plattform auf die Produktion und wie sie nach dem Start betrieben wird.
Architekturübersicht
ADE ist in vier Schichten organisiert: die Benutzererfahrung, die Agenten-Orchestrierung, die Spezialagenten sowie die Tools und Datenquellen, die diese Agenten aufrufen (Abbildung 1). Benutzer erreichen ADE über ein React-Web-Frontend, und Anfragen durchlaufen einen Identity Proxy für Microsoft Entra ID, bevor sie die Agenten erreichen. GitHub Actions erstellt die Agenten-Container-Images, pusht sie zu Amazon Elastic Container Registry (Amazon ECR)und stellt sie in der AgentCore Runtime bereit, einer Funktion von Amazon Bedrock AgentCore.
Amazon Bedrock AgentCore runtime hostet die Agenten, und da die Runtime framework-agnostisch ist, betreibt das Team seine eigene LangGraph-basierte Orchestrierung direkt darauf. Das Team wählte LangGraph wegen seiner expliziten graphbasierten Ablaufsteuerung und des Checkpointings für mehrstufige Workflows. LangGraph orchestriert den Workflow, wobei ein Supervisor Agent als Einstiegspunkt jede Anfrage klassifiziert, einen Spezialisten auswählt und Ergebnisse kombiniert, wenn eine Frage mehrere Domänen umfasst. Die Datenebene ist nach Verantwortlichkeit getrennt. Amazon DynamoDB speichert den LangGraph-Checkpoint-State. Amazon Aurora PostgreSQL speichert Sitzungsaufzeichnungen, Nutzerfeedback und Analysedaten. Amazon ElastiCache cached Agentenantworten mit einer time to live (TTL). Domäneninhalte in Amazon Simple Storage Service (Amazon S3) werden mit Amazon Titan Text Embeddings V2 eingebettet und in Amazon OpenSearch Serverless für Retrieval Augmented Generation (RAG) indexiert. Amazon CloudWatch erfasst Runtime- und Anwendungs-Telemetrie. AgentCore Gateway stellt Backend-APIs Agenten als Model Context Protocol (MCP) Tools bereit und hält Authentifizierung und Autorisierung außerhalb des Agentencodes.
Abbildung 1: Agentic Decision Engine Architektur auf Amazon Bedrock AgentCore
ADE betreibt in der Produktion 22 Spezialistenagenten, von denen jeder auf eine Domäne mit eigenen Tools und Datenquellen beschränkt ist. Beispielsweise beantwortet der Domain Expert Agent konzeptionelle Fragen über RAG. Der Operational Agent ruft Live-Workflowstatus und -ergebnisse aus dem CDE ab. Der Troubleshooting Agent analysiert operative Telemetrie. Der Visualization Agent erzeugt Diagramme oder liefert bestehende Dashboards zurück. Ein kundenspezifisches Models as Skill Muster wandelt Modellcode und Dokumentation in Skilldefinitionen um, die in einer zentralen Registrierung gespeichert werden, sodass Agenten modellspezifische Fragen anhand der Implementierung des Modells statt aus generischem Modellwissen beantworten.
Wenn ein Züchter fragt: „Warum ist mein Phenotyping-Workflow gestern fehlgeschlagen?“, klassifiziert der Supervisor die Absicht und leitet die Anfrage an den Troubleshooting Agent weiter. Dieser Agent liest die Telemetrie des Workflows in CloudWatch und seinen Status über die CDE API durch das AgentCore Gateway, identifiziert die Fehlerstelle und gibt eine Diagnose über den Supervisor zurück (Abbildung 2). Der Züchter durchsucht keine Protokolle direkt. Mit dem Troubleshooting Agent dauert eine Diagnose, die früher über eine Stunde manueller Protokollsuche und Warten auf Ingenieursunterstützung erforderte, nun weniger als 10 Minuten.
Abbildung 2: ADE-Anfragefluss: Intent-Klassifizierung, Cache-Lookup, Spezialisten-Routing und Antwort
Fünf Designentscheidungen auf dem Weg in die Produktion
Das Unified Operations TAM und DSE nahmen als Mitglieder des Arbeitsteams an den folgenden Entscheidungen teil, nicht als Eskalationsstelle im Nachhinein. Das ermöglichte Bayer, jede Designentscheidung gegen das Verhalten der AWS-Services zu testen, bevor sie sich darauf festlegte, während die Verantwortung für die Architektur und die endgültige Entscheidung verblieb.
1. Orchestrierungsstate externalisieren, ohne die Runtime als stateless zu behandeln
Die AgentCore runtime bietet isolierte Sitzungen, die den Ausführungskontext über Aufrufe hinweg innerhalb des Lebenszyklus einer Sitzung bewahren. Dieser Kontext ist kein dauerhafter Speicher für einen mehrstufigen Workflow. ADE schreibt LangGraph-Checkpoints nach DynamoDB, damit der Graph nach Scale-out-Ereignissen, Neustarts oder Sitzungsgrenzen fortgesetzt werden kann, ohne dass eine einzige Ausführungsumgebung verfügbar bleiben muss.
Prinzip: Nutzen Sie die Runtime-Sitzung für die aktive Ausführung und persistieren Sie den für die Wiederaufnahme oder Rekonstruktion des Workflows erforderlichen State in einem dauerhaften Service.
2. Unternehmensidentität, Gateway-Zugriff und Downstream-Autorisierung trennen
Bayer standardisiert auf Microsoft Entra ID für die Nutzeridentität, während sich ADEs Services gegenseitig mit AWS-nativen Mechanismen autorisieren. Statt ein Token über jede Vertrauensgrenze hinweg zu erzwingen, gab das Team jeder Grenze einen eigenen Mechanismus.
Entra ID bleibt die Quelle der Nutzeridentität. AWS Identity and Access Management (IAM) autorisiert Service-zu-Service-Aufrufe. Die Outbound-Autorisierung des AgentCore Gateway regelt den Zugriff auf Downstream-CDE-Services. Eine Request-Interceptor-AWS-Lambda-Funktion führt eine benutzerdefinierte Validierung durch und übergibt die Autorisierungsattribute, die Downstream-Tools benötigen. Das Team arbeitete den Token-Vertrag an jedem Hop mit dem DSE durch.
Prinzip: Identitätsfehler in Agentensystemen häufen sich an den Übergängen zwischen Nutzeridentität, Agentenidentität und Tool-Identität. Definieren Sie Issuer, Audience, Claims, Scopes und die Gültigkeitsdauer der Credentials an jedem Hop, statt ein Token, das für eine Grenze gültig ist, an der nächsten wiederzuverwenden.
3. Modellauswahl als Interface-Vertrag behandeln
Während der Entwicklung evaluierte das Team eine neuere Modellversion mit aktiviertem Reasoning Mode. Bei dieser Version war die Kombination aus Tool-Nutzung und strukturiertem Output, von der ADE abhängt, nicht mit der Implementierung seiner Agenten kompatibel. Das DSE bestätigte die Einschränkung, und das Team behielt das aktuelle Modell für das Release bei.
Grundsatz: Für Agenten mit Werkzeugnutzung wird die Modellwahl durch die vollständige Schnittstelle eingeschränkt: Tool-Aufrufe, strukturierte Ausgabe, Streaming-Verhalten, Reasoning-Funktionen, Latenz, Quota-Verfügbarkeit und modellspezifische Anfrage-Semantik. Ein neueres Modell ist nicht automatisch ein Drop-in-Ersatz.
4. Kontrollieren Sie die Werkzeugoberfläche, bevor sie den Prompt kontrolliert
CDE verwaltet mehr als 500 Modellkonfigurationen. Ein dedizierter MCP-Server pro API hätte zusätzlichen Aufwand für Bereitstellung, Authentifizierung und Versionsmanagement bedeutet. ADE registriert stattdessen OpenAPI-Spezifikationen beim AgentCore Gateway, das die REST-Operationen als MCP-Tools verfügbar macht. Das Hinzufügen oder Ändern einer API wird damit zu einer Schema- und Gateway-Konfigurationsänderung statt zu einer neuen Server-Bereitstellung.
Tool-Schemata und -Beschreibungen verbrauchen zudem Eingabe-Tokens und konkurrieren mit der Anfrage des Nutzers und dem abgerufenen Kontext. ADE begrenzt Tools nach Fachagenten (Specialist Agent), anstatt jedem Agenten den gesamten Katalog bereitzustellen. Bei größeren Katalogen unterstützt AgentCore Gateway die semantische Toolsuche, sodass ein Agent relevante Tools finden kann, ohne bei jedem Durchlauf den gesamten Katalog zu laden.
Grundsatz: Begrenzen Sie den Tool-Katalog pro Agent. Jede Tool-Definition fügt Tokens hinzu und erweitert den Entscheidungsraum des Modells.
5. Ausbau komplexer Fähigkeiten von Tools zu Agenten
Die Visualisierung begann als Tool, das von anderen Agenten aufgerufen wurde. Als sie wuchs, benötigte sie eine eigene Datenabfrage, Logik zur Diagrammauswahl, Wiederholungsversuche, Fehlerbehandlung sowie eine Entscheidung darüber, ob ein Diagramm erzeugt oder ein vorhandenes Dashboard zurückgegeben werden soll. Das Team machte daraus einen spezialisierten Visualization Agent. Der Agent erzeugt Diagramme bei Bedarf mit matplotlib und Plotly im AgentCore Code Interpreter, einer Funktion von Amazon Bedrock AgentCore, die eine sandboxed Code-Ausführungsumgebung bereitstellt, und tauscht Daten über Amazon S3 mit ihr aus. Wenn ein vorgefertigtes Dashboard die bessere Antwort ist, gibt der Agent das vorhandene Amazon Quick- oder Power BI-Asset zurück.
Grundsatz: Ein Tool führt eine abgegrenzte Operation aus. Wenn eine Fähigkeit beginnt, Zustände, Wiederholungen, Planung, Richtlinien oder Darstellungsentscheidungen zu übernehmen, modellieren Sie sie als Agenten.
ADE auf den Produktionsbetrieb vorbereiten
Als der Build in Richtung Launch ging, verschob sich der Fokus vom Design auf die Betriebsfähigkeit: das Erkennen von Agentenfehlern, die Zuordnung von Inferenzkosten und die Härtung der Bereitstellung.
Observability: Aufgabenfehler messen, nicht nur Ausnahmen
Eine Supervisor-Architektur verwandelt eine Nutzeranfrage in eine Kette von Modellaufrufen, Tool-Aufrufen und Agentenübergaben. Die endgültige Antwort kann falsch sein, selbst wenn jede HTTP-Anforderung erfolgreich war. ADE ist genau darauf gestoßen: Anwendungsweite Exception-Handler fingen Agentenfehler ab und gaben Antworten zurück, die das Monitoring als erfolgreich zählte. Nach der Reproduktion des Problems mit dem DSE fügte das Team benutzerdefinierte CloudWatch-Metriken innerhalb der Fehlerpfade sowie Alarme für agentenspezifische Bedingungen hinzu: Tool-Aufruffehler, Drosselung, Modell-Timeouts und Fehler bei der Validierung strukturierter Ausgaben. Traces und AufruflProtokolle verfolgen jede Anfrage über den Supervisor und die Fachagenten hinweg.
Grundsatz: Unterscheiden Sie zwischen Transporterfolg und Aufgabenerfolg. Die Agent-Observability sollte zeigen, ob die Aufgabe abgeschlossen wurde, welcher Agent oder welches Tool das Ergebnis verändert hat und ob die Antwort die erwartete Quelle verwendet hat.
Kostenzuordnung: Abrechnungszuordnung mit Anfrageebenen-Telemetrie kombinieren
Eine ADE-Anfrage kann mehrere Modelle und Tools aufrufen, daher erklären kontoebene Amazon Bedrock-Ausgaben nicht die Unit Economics. Das Team entwarf den Zuordnungsansatz mit dem DSE anhand von drei Mechanismen, die unterschiedliche Fragen beantworten. Amazon Bedrock application inference profiles ordnen die abgerechnete Modellnutzung einer Anwendung oder Workload zu. Anfragemetadaten und Modell-Aufrufprotokollierung verknüpfen die Token-Nutzung mit einem bestimmten Agenten, Feature oder einer bestimmten Anfrage. IAM-Principal-Zuordnung fügt eine Identitätsdimension hinzu. Zusammen ermöglichen sie dem Team, die Kosten pro Interaktion abzuschätzen, teure Agenten zu identifizieren und festzustellen, ob Prompts, abgerufener Kontext oder Tool-Definitionen die Token-Nutzung antreiben. In der Praxis verbrauchten die Visualization- und Operational-Agenten, die auf MCP-Tools und mehrere Tool-Aufrufe setzen, die meisten Tokens.
Dieselbe Telemetrie deckte während der Launch-Vorbereitung eine Workload mit einem großen, sich wiederholenden Eingabepräfix und ohne Prompt-Cache-Aktivität auf. Bei unterstützten Modellen reduziert das Platzieren stabiler Anweisungen und Tool-Definitionen in einem cachebaren Prompt-Präfix die wiederholte Eingabeverarbeitung, was die Latenz und die Tokenkosten senkt. Für ADE senkte das Caching des stabilen Prompt-Präfixes die Eingabe-Token-Kosten um 20–30 Prozent.
Sicherheit und Launch-Bereitschaft
IAM-Rollen sind auf die jeweilige Verantwortung jedes Agenten beschränkt. Der Troubleshooting Agent kann die Betriebsdaten lesen, die er für die Diagnose benötigt, kann aber keine Workflows ändern. Der Domain Expert Agent kann seinen Retrieval-Index abfragen, jedoch keine nicht verwandten CDE-APIs aufrufen. In der heutigen Produktionsumgebung werden die Antworten der ADE-Agenten durch Least Privilege, schreibgeschützten, auf jeden Agenten begrenzten Tool-Zugriff, Validierung strukturierter Ausgaben der Agentenantworten und Antworten gesteuert, die auf abgerufenen CDE-Daten und Telemetrie basieren statt auf offener Generierung. Bayer plant zudem, Amazon Bedrock Guardrails als zusätzliche Ebene über diese Kontrollen zu bewerten, ergänzend zu den bereits in CDE-Mehrrunden-Workflows verwendeten benutzerdefinierten Sicherheitsprüfungen.
Vor dem Launch führte Unified Operations gemeinsam mit dem ADE-Team eine Critical Workload Review und eine Well-Architected-Überprüfung mit dem Generative AI Lens durch. Da der DSE die Workload bereits kannte, zielten beide Überprüfungen auf ADEs spezifische Fehlermodi, Kapazitätsrisiken und Bereitstellungslücken ab, statt auf generische Best Practices. Die Feststellungen umfassten Lücken in der Fehler-Sichtbarkeit über Supervisor- und Fachagenten hinweg, veränderbare Container-Image-Tags, eingeschränkte Image-Nachverfolgbarkeit und fehlende Schwachstellen-Scans. Das Team reagierte mit stärkeren Alarmen, unveränderlichen versionierten Images, Scan on Push in Amazon ECR und Lifecycle-Richtlinien für ungenutzte Images.
Der DSE prüfte mit dem Team auch Skalierungs- und Quotenanforderungen. Lasttests validierten sowohl die Anwendung als auch ihre Service-Quoten und deckten einen Netzwerkfehlermodus auf, der leere Antworten zurückgab; das Team behob diesen vor dem Produktionsereignis. Bis zum Launch hatte das Team 35 Blocker bis zur Lösung mit Unified Operations verfolgt.
Launch, Betrieb und nächste Schritte
Bayer führte ADE zunächst in einer geschlossenen Nutzergruppe ein, anstatt es sofort der gesamten Organisation zu öffnen. Seit dem Start haben mehr als 100 Nutzerinnen und Nutzer aus dem Bereich Bayer Crop Science ADE genutzt, darunter Züchter, Analysten, Forscher, Data Scientists und Ingenieure. Neben seinen 22 spezialisierten Agents stellt ADE rund 20 API-Tools bereit und kann bei der Erweiterung Agents von Drittanbietern hosten. Die Bereitstellung dieser APIs über AgentCore Gateway anstelle eines eigenen Servers pro API senkte den Integrationsaufwand pro API um mehr als 99 Prozent. In seiner ersten Phase hat ADE etwa 80 Prozent der Nutzerfragen ohne Einschaltung eines Ingenieurs beantwortet.
Die CDE bleibt die gesteuerte Ausführungsschicht für Analysen. ADE fügt darüber eine Natural-Language-Schicht hinzu, sodass Nutzer ohne Kenntnis des Speicherorts oder der Oberfläche der einzelnen zugrunde liegenden Systeme nach dem Workflow-Status, Ergebnissen, Modellverhalten und Fehlern fragen können.
Das Engagement verlagerte sich dann von der Startbereitschaft auf den laufenden Betrieb. Das DSE trifft sich weiterhin mit dem Team, sodass Issue-Triage und operative Reviews auf vorhandenen Kenntnissen über ADE aufbauen statt mit einem neuen Einarbeitungsprozess zu beginnen. ADEs kritische CloudWatch-Alarms, einschließlich der zuvor beschriebenen agentenspezifischen Alarms, wurden in AWS Incident Detection and Response integriert. Wenn einer ausgelöst wird, kommen AWS Incident Management Engineers innerhalb von 5 Minuten hinzu und starten mit dem Kontext der Workload statt bei null. Auf der Sicherheitsseite unterstützen AWS Security Incident Response Engineers das Team bei potenziellen oder aktiven Sicherheitsvorfällen, sodass ADE eine AWS-Überwachungs- und Reaktionsabdeckung sowohl für betriebliche als auch für sicherheitsrelevante Probleme hat.
Da die Agent-zu-Agent-Kommunikation bereits etabliert ist, konzentriert sich Bayer als Nächstes auf die Interoperabilität von Agenten in der Hybrid Cloud. Das Team untersucht, wie Agenten, die in verschiedenen Umgebungen laufen, einander entdecken und ohne manuelle Konfiguration miteinander kommunizieren können.
Fazit
Bayer hat seine Analyseplattform nicht durch ADE ersetzt. Es machte CDE leichter abfragbar und betreibbar. Der Großteil der Produktionsarbeit lag außerhalb der Prompts: dauerhafter Zustand, Identitätsgrenzen, Tool-Scoping, Observierbarkeit auf Aufgabenebene, Kostenzuordnung und Launch-Bereitschaft. Bayer besaß die Architektur und jede dieser Entscheidungen. In Zusammenarbeit mit einem fest zugeordneten DSE und TAM im Rahmen von AWS Unified Operations testete das Team diese Entscheidungen während des Entwurfs gegen das Verhalten der AWS-Services und trug denselben Kontext in den Betrieb.
Um mehr zu erfahren, erkunden Sie Amazon Bedrock AgentCore, Amazon Bedrock Kostenzuordnung, AWS Well-Architected-Leitfaden für Generative AI, und AWS Unified Operations.
Die Autorinnen und Autoren möchten sich bei Sijie Shi, Jorge Gomes, Naveen Reddy, Iago Fonseca, Mateus Silva und Sushimitha Jarugula für ihre Beiträge zum Design, zur Entwicklung und zum Launch von ADE bedanken.