Fünf Stolpersteine für Multi-Agent-Systeme in der Produktion
Viele Teams bauen in wenigen Tagen einen Multi-Agent-Prototyp, scheitern aber im Betrieb. Orchestrierung, Modellauswahl pro Agent, zuverlässiger Betrieb, sichere Code-Ausführung und Monitoring sind laut Deep Insight die zentralen Herausforderungen.
Der Aufbau eines Multi-Agent-Systems ist inzwischen recht unkompliziert. Die eigentlichen Herausforderungen beginnen erst, wenn es in den Produktivbetrieb gehen soll. Dank Open-Source-Frameworks und Cloud-Diensten lässt sich ein Agent innerhalb weniger Tage einrichten. Ein paar Tool-Aufrufe, ein paar Zeilen Prompt, und man hat etwas, das beeindruckend aussieht. Doch sobald Teams versuchen, über einen Piloten hinaus zu echten Geschäftsanwendungen zu gelangen, stoßen sie auf eine vertraute Wand. Wer schon einmal versucht hat, einen Agenten in Produktion zu bringen, wird diese Frustrationen kennen:
Warum hält sich der Agent nicht an unsere Geschäftslogik, überspringt Validierungsschritte oder erkennt Randfälle nicht?
Man passt den Prompt an, fügt weitere Beispiele hinzu, tauscht das Modell aus. Dieselben Probleme kommen immer wieder. Das liegt daran, dass Agenten keiner festen Abfolge von Anweisungen folgen. Sie treffen ihre eigenen Entscheidungen auf Grundlage des Kontexts. Anweisungen allein reichen nicht aus. Man muss gestalten, wie der Agent denkt, wann er verifiziert und was er tut, wenn etwas schiefgeht. Genau deshalb ist es inzwischen entscheidend, über reines Prompt Engineering hinauszugehen und die gesamte kognitive Architektur sowie den Ausführungsfluss des Agenten zu entwerfen.
Um diese Herausforderungen direkt anzugehen, hat das AWS Solutions Architecture Team Deep Insight entwickelt, ein Multi-Agent-System in Produktionsqualität. In dieser Beitragsserie teilt das Team in drei Teilen die Erkenntnisse, die es beim Bau von Deep Insight aus erster Hand gewonnen hat. Wir zeigen, wie wir die von Anthropic vorgeschlagenen Context-Engineering-Techniken (Multi-Agent-Architektur, strukturierte Notizen, Human-in-the-Loop und mehr) in einer echten Produktionsumgebung angewendet haben. Wir beleuchten auch die dabei auftretenden Kompromisse (mit Code) und die operativen Erkenntnisse aus dem Deployment und Betrieb dieses Agenten auf AWS.
Dies ist Teil 1 einer dreiteiligen Serie. Sie definiert die fünf zentralen Herausforderungen, die jedes Multi-Agent-Produktionssystem lösen muss, und zeigt, wie jede Schicht des Stacks diese adressiert, vom Strands Agents SDK und Amazon Bedrock über Amazon Bedrock AgentCore und Application Load Balancer bis hin zu AWS Fargate. Die Teile 2 und 3 behandeln Context Engineering und das Produktions-Deployment.
Deep Insight ist ein Multi-Agent-System, das komplexe Datenanalysen in automatisierte Erkenntnisse umwandelt. Bei Vorgabe einer CSV-Datei und eines Prompts in natürlicher Sprache arbeitet eine Hierarchie spezialisierter Agenten (Coordinator, Planner, Supervisor, Coder, Validator, Reporter und Tracker) an der Analyse zusammen. Gemeinsam laden sie die Daten, führen Analysen durch, erstellen Diagramme, validieren Berechnungen und erzeugen einen professionellen Bericht (.docx) mit Quellenangaben.
Die Architektur betrachten wir später im Detail. Zunächst sehen wir sie in Aktion. Für die Demo speisen wir Werbedaten eines fiktiven Lebensmittelunternehmens namens Yummy Food ein (yummy-food-market.csv) zusammen mit einer Datei mit Spaltendefinitionen (column_definitions.json) und geben den Prompt: Analysiere dies aus Vertriebs- und Marketingsicht, erstelle Diagramme und Erkenntnisse und erzeuge einen.docx-Bericht. Deep Insight erstellt einen Analyseplan, legt ihn dem Nutzer zur Freigabe vor und führt die Analyse nach der Freigabe aus.
Das folgende Demo-Video der Deep Insight Web-Version zeigt den kompletten Workflow, vom Hochladen der Daten und Prüfen des Analyseplans bis zum Streaming in Echtzeit und dem Herunterladen des fertigen Berichts.
Deep Insight ist auf GitHub als Open Source mit einer vollständigen Einrichtungsanleitung verfügbar und bietet drei Deployment-Optionen, die die Spanne von der Entwicklung bis zur Produktion abdecken.
Die erste ist die Self-Hosted-Version, die lokal über die CLI läuft. Sie ist auf schnelle Iteration optimiert und bietet vollen Zugriff auf Code-Ebene auf jeden Agenten, jeden Prompt und jeden Workflow. Die Einrichtung dauert etwa 10 Minuten, was sie für die Entwicklung besonders geeignet macht. (Ein Demo-Video zur Self-Hosted-Version ist auf YouTube verfügbar.)
Die zweite ist die Web-Version, eine browserbasierte Oberfläche zum Hochladen von Daten, Prüfen von Analyseplänen (Human-in-the-Loop, kurz HITL) und Herunterladen von Berichten, ganz ohne Code, wodurch sie auch für Nicht-Entwickler zugänglich ist. (Das vorherige Demo-Video zeigt die Web-Version in Aktion.)
Die dritte ist die Managed AgentCore-Version, eine Produktions-Deployment-Option, die auf Amazon Bedrock AgentCore basiert, einer Plattform zum Erstellen, Verbinden und Optimieren von Agenten in großem Maßstab, mit beliebigen Frameworks und Modellen. Diese Version deployed die Agenten auf dem AgentCore Runtime, einer Funktion von Amazon Bedrock AgentCore. Das System läuft vollständig innerhalb einer privaten Virtual Private Cloud (VPC), mit einem eigenen Code Interpreter, der separat auf AWS Fargate gehostet wird, und die Agenten laufen parallel in isolierten Umgebungen pro Nutzer. Sie ist die richtige Wahl, wenn man Session-Isolation und ein privates VPC-Deployment benötigt. Teil 3 behandelt ihr Deployment und ihren Betrieb ausführlich.
Alle drei teilen sich dieselbe Multi-Agent-Architektur, sodass ein in der Entwicklung validierter Agent unverändert in die Produktion überführt werden kann.
Der Bau eines Multi-Agent-Produktionssystems erfordert mehr als gute Prompts. Man braucht den richtigen Technologie-Stack und die passende Infrastruktur, um zu adressieren, wie Agenten zusammenarbeiten, wie sie schlussfolgern, wie man sie deployed, wo sie Code sicher ausführen und wie man den operativen Zustand überwacht. Deep Insight löst Probleme in diesen fünf Schlüsselbereichen. Da die Agenten sowohl Code als auch Berichtsinhalte erzeugen, behandeln wir in Solution detail 2 auch Kontrollen für verantwortungsvolle KI im Produktionsbetrieb.
Das folgende Architekturdiagramm (Abbildung 1) veranschaulicht dies auf einen Blick. Die grünen Boxen repräsentieren die Multi-Agent-Struktur von Strands Agents, die die Herausforderungen 1 und 2 aus der vorstehenden Tabelle adressiert. Darauf gehen wir im folgenden Abschnitt Solution detail 1: Multi-agent system design im Detail ein. Die übrigen im Diagramm gezeigten Infrastrukturkomponenten adressieren die Herausforderungen 3, 4 und 5, die wir in Solution detail 2: Production deployment and operations durchgehen.
Deep Insight nutzt eine Multi-Agent-Architektur, bei der acht Agenten zusammenarbeiten, um ein hochwertiges Ergebnis zu erzeugen. Jeder Agent arbeitet in seinem eigenen unabhängigen Kontext, führt ausschließlich seine spezialisierten Aufgaben aus und gibt nur komprimierte Ergebnisse weiter.
Der Coordinator leitet Nutzeranfragen weiter, der Planner zerlegt Aufgaben in einzelne Schritte, der Plan Reviewer sammelt Nutzerfeedback, und der Supervisor ruft die passenden spezialisierten Agenten entsprechend dem Plan auf. Der Coder schreibt und führt Datenanalyse-Code aus, der Validator prüft Berechnungen, der Reporter erstellt den finalen Bericht, und der Tracker verfolgt den Fortschritt. Wir erklären dies anhand von drei Schichten:
Zwei zentrale Muster des Strands Agents SDK werden kombiniert, um den Ausführungsfluss über diese Agenten hinweg zu steuern. Zum ersten definiert das Graph-Muster die Ausführungsreihenfolge und den Fluss der Agenten als gerichteten Graphen. Anfragen fließen vom Coordinator zum Planner, zum Plan Reviewer und dann zum Supervisor, mit einem bedingten Zweig, der bei Änderungswünschen zum Planner zurückführt.
Die Bestimmung des nächsten Schritts über eine Bedingung macht komplexe Workflows wie HITL und Fehlerbehandlung unkompliziert. Zum zweiten ermöglicht das Agents-as-Tools-Muster, dass der Supervisor spezialisierte Agenten (Coder, Validator, Reporter, Tracker) bei Bedarf als Tools aufruft. Jeder arbeitet in einem unabhängigen Kontext und gibt nur Ergebnisse zurück, wodurch die Kontextnutzung minimiert wird, während domänenspezifisches Fachwissen erhalten bleibt.
Dieser Abschnitt zeigt, wie die Architektur Routing, Planung und Orchestrierung löst.
Diese Schicht verwandelt eine Nutzeranfrage in einen freigegebenen Ausführungsplan.
Der Coordinator ist der Einstiegspunkt für Nutzeranfragen. Er beantwortet einfache Begrüßungen direkt und leitet komplexe Aufgaben wie Datenanalysen mit einer handoff_to_planner-Markierung an den Planner weiter.
Die zentrale Designentscheidung betrifft die Modellauswahl: Da der Coordinator nur klassifiziert, verwendet er das leichte Claude Haiku, wodurch Opus-Kosten für einfache Begrüßungen vermieden werden und schnelle Antworten geliefert werden.
# builder.py: bedingte Kanten für Routing-Entscheidungen builder.set_entry_point("coordinator") builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner) Die Routing-Bedingungen stammen aus dem Prompt des Coordinators: Jede Anfrage, die Tools, Reasoning oder mehrstufiges Denken erfordert, geht an den Planner.
In der Multi-Agent-Struktur von Deep Insight übernimmt der Planner-Agent die entscheidende Rolle, Aufgaben auf die Agenten zu verteilen. Bevor die eigentliche Arbeit beginnt, zerlegt er große Aufgaben in kleinere Schritte, und jeder spezialisierte Agent führt diese einzeln aus, wodurch der Kontext jedes Agenten klein bleibt.
Der Planner verwendet ein Claude Opus Modell mit aktiviertem Extended Thinking, um den Analyseplan zu erstellen. Er organisiert den Plan in einem [ ]-Checklistenformat, das konkrete Aufgaben für jeden Agenten festlegt, gespeichert in einer Variablen namens full_plan. Er zerlegt die Anfrage in 5 bis 10 klare Schritte, wie im folgenden Beispiel gezeigt:
## Titel Analysebericht zu Konsumgutscheins-Kaufmustern und Werbewirksamkeit ## Schritte ### 1. Coder: Umfassende Datenanalyse und Generierung von Insights - [ ] Alle Datendateien aus dem Pfad './data/*' laden und die Struktur verstehen - [ ] Die Kaufhistorie der Konsumenten analysieren (Muster, Praeferenzen, Kundensegmente) - [ ] Die Werbedaten nach Kanal analysieren (Kosten, Wirksamkeit, Kanalvergleich) - [ ] Analyse auf Kategorieebene (Werbewirksamkeit bei Frischware, Fertigprodukten und Gesundheitsprodukten) - [ ] Zentrale Geschaeftskennzahlen berechnen (Conversion Rate, CPA, ROAS usw.) - [ ] Visualisierungen erstellen (mehr als 5 Diagramme, Diagramme zu Konsumentensegmenten) - [ ] Strategische Marketing-Insights ableiten - [ ] Berechnungsmetadaten generieren (zur Validierung) ### 2. Validator: Berechnungspruefung und Erstellung von Zitat-Metadaten - [ ] Verifikationsziele identifizieren und Filterberechnungen extrahieren - [ ] Datendateien direkt laden und Neuberechnungen durchfuehren - [ ] Die Genauigkeit der Leistungskennzahlen pro Kanal ueberpruefen - [ ] Die Datenkonsistenz von Visualisierungen und Grafiken validieren - [ ] Zitat-Metadaten generieren (Referenznummern fuer verifizierte Elemente) ### 3.
Reporter: Erstellung des Marketing-Analyseberichts - [ ] Ueberblick im Bericht verfassen - [ ] Strukturierten Bericht anhand der verifizierten Analyseergebnisse erstellen - [ ] Visualisierungen und Analyseabschnitte einfuegen - [ ] Empfehlungen zur Marketingstrategie und Verbesserungsvorschlaege praesentieren - [ ] Professionellen Marketingbericht im DOCX-Format generieren 1.3 Plan Reviewer Der Plan Reviewer ist ein HITL-Knoten, der den Plan dem Nutzer praesentiert und dessen Zustimmung oder Aenderungsfeedback einsammelt. Gibt es Feedback, kehrt der Ablauf zum Planner zurueck, um den Plan zu ueberarbeiten. Nach der Freigabe uebergibt er die Aufgabe an den Supervisor.
Eine maximale Anzahl an Ueberarbeitungen ( MAX_PLAN_REVISIONS ) ist festgelegt, um Endlosschleifen zu verhindern.
# builder.py: Bidirektionale bedingte Kanten des Plan Reviewer builder.add_edge("plan_reviewer", "planner", condition=should_revise_plan) builder.add_edge("plan_reviewer", "supervisor", condition=should_proceed_to_supervisor) builder.set_max_node_executions(25) In der Web-Version zeigt der Plan Reviewer ein Browser-Modal an, in dem der Nutzer den Plan liest und ihn freigibt oder Aenderungsfeedback eingibt. Ein Countdown von 300 Sekunden genehmigt den Plan automatisch, wenn keine Rueckmeldung eingeht.
Abbildung 3: Ausfuehrung des Plan Reviewer Agents in der Web-UI
Ohne Planung entscheidet der Agent alles zur Laufzeit, eine Kurskorrektur macht bisherige Arbeit ungueltig, und Nutzer haben keinen Einblick in den Fortschritt. Mit Planner und Plan Reviewer kann der Nutzer den Plan pruefen und ueberarbeiten, den Fortschritt in Echtzeit verfolgen und nur den fehlgeschlagenen Schritt erneut ausfuehren.
Der Supervisor fuehrt den full_plan des Planner der Reihe nach aus und ruft dabei die Agents der Ebene 3 (Coder, Validator, Reporter, Tracker) als Tools auf, die ueber Tool Use bei ihm registriert sind.
# nodes.py: Registrierung der Sub-Agents als Tools beim Supervisor agent = strands_utils.get_agent( agent_name="supervisor", system_prompts=apply_prompt_template(prompt_name="supervisor", prompt_context={}), model_id=os.getenv("SUPERVISOR_MODEL_ID", os.getenv("DEFAULT_MODEL_ID")), prompt_cache_info=(True, "default"), tool_cache=True, tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool], streaming=True, ) Der Systemprompt des Supervisors definiert strenge Workflow-Regeln:
Jeder Agent der Ebene 3 (Coder, Validator, Reporter, Tracker) ist als PythonAgentTool verpackt und enthaelt Tool Use Aufrufe vom Supervisor. Jeder wird als unabhaengige Agent() Instanz im Strands SDK mit eigenem Systemprompt, eigener Model ID und eigenem Toolset erstellt.
Der Supervisor ruft Tool Use Aufrufe in dieser Reihenfolge auf, basierend auf der Checkliste des Planner:
Der Tracker laeuft nach jedem Agent, damit der Supervisor den Fortschritt verfolgen und die Abschlussregel durchsetzen kann (kein Weitergehen, bevor alle Punkte mit [x] markiert sind). Da er die Checkliste allein durch LLM-Reasoning ohne Tools aktualisiert, verursacht er kaum Mehraufwand.
Deep Insight passt Modell und Einstellungen an die Rolle jedes Agents an. Das ist keine reine Modellauswahl, sondern eine architektonische Entscheidung zur Optimierung von Kosten und Qualitaet.
Die Agents Supervisor, Coder und Reporter nutzen Prompt Caching, um ihre Systemprompts und Tooldefinitionen zu cachen, was die Kosten fuer Eingabe-Tokens bei wiederholten Aufrufen um bis zu 90 Prozent senkt. Der Coordinator laeuft nur einmal, und Validator und Tracker laufen jedes Mal mit unterschiedlichen Kontexten, weshalb Caching fuer sie wirkungslos bleibt und deaktiviert bleibt. Diese selektive Caching-Strategie ist ein bewusster Kompromiss zwischen Kosten und Leistung.
Wenn Loesungsdetail 1 beschrieben hat, was das System tut, definiert dieser Abschnitt, wo und wie es sicher betrieben wird. Alles Folgende behandelt Infrastrukturentscheidungen fuer den Produktivbetrieb. Konkret behandelt dieser Abschnitt die sichere Ausfuehrungsumgebung fuer LLM-generierten Code sowie die betriebliche Sichtbarkeit fuer das Team.
Der Coder Agent schreibt und fuehrt Python fuer die Datenanalyse aus. In der Self-Hosted-Version laeuft er lokal ueber subprocess.run(), doch in der Produktivumgebung (AgentCore) sind Sicherheit und Isolation entscheidend. LLM-generierten Code direkt auf einem Produktionsserver auszufuehren ist riskant: Das Modell koennte Systemdateien loeschen, Ressourcen in einer Endlosschleife ausschoepfen oder auf Analysedaten anderer Nutzer zugreifen.
Deep Insight loest dies mit fluechtigen Containern pro Session auf AWS Fargate und einem ALB. Diese Komponenten laufen nicht isoliert voneinander. Wie in Abbildung 1 gezeigt, laufen AgentCore Runtime, der ALB und die Fargate Tasks innerhalb derselben privaten VPC.
VPC Endpunkte verbinden sie mit Amazon Simple Storage Service (Amazon S3), Amazon Bedrock und Amazon Elastic Container Registry (Amazon ECR), ohne das oeffentliche Internet zu durchqueren. Security Groups beschraenken, welche Komponenten die Code Interpreter Container erreichen koennen. AWS Identity and Access Management (IAM) Rollen begrenzen jede Komponente auf genau die AWS-Ressourcen, die sie benoetigt.
Amazon CloudWatch sammelt Container-Protokolle und Observability-Daten von AgentCore Observability, einer Funktion von Amazon Bedrock AgentCore.
Die Container-Isolation schuetzt die Infrastruktur, regelt aber nicht, was die Agents erzeugen. Der Validator Agent ueberprueft Berechnungen erneut. Er erkennt keine Prompt-Injection-Anweisungen, die in hochgeladenen Daten versteckt sind, und praeft keinen LLM-generierten Text auf schaedliche oder unbelegte Inhalte. Fuer Produktivumgebungen empfehlen wir, Amazon Bedrock Guardrails als Control fuer verantwortungsvolle KI zu ergaenzen: Inhaltsfilter und Prompt-Attack-Erkennung auf Nutzer-Prompts und hochgeladene Daten anwenden sowie Contextual Grounding Checks auf Agent-Ausgaben anwenden, damit der Berichtstext auf den Quelldaten und verifizierten Berechnungen bleibt.
Ein Produktionssystem ist mit Code allein nicht vollstaendig. Das Team muss den Systemzustand bewerten, Probleme diagnostizieren und Ergebnisse pruefen, weshalb Deep Insight eine Web-UI und ein Ops Dashboard bietet.
Ein auf FastAPI basierendes Web-Interface, das ueber das AgentCore Native Protocol ( boto3.invoke_agent_runtime() ) mit dem Backend kommuniziert. Nutzer laden Daten hoch und geben einen Prompt ein, verfolgen dann den Fortschritt ueber Server-Sent Events (SSE) Streaming. Wird der Plan erzeugt, oeffnet sich ein Modal, in dem der Nutzer ihn freigeben oder Aenderungsfeedback geben kann (HITL). Der fertige Bericht laesst sich direkt herunterladen. Sowohl Koreanisch als auch Englisch werden unterstuetzt.
Abbildung 4: Screenshot der Web-Version von Deep Insight
Das Ops Dashboard ist optional. Deep Insight funktioniert auch ohne es, bietetTeams, die es benoetigen, jedoch diese Funktionen:
Abbildung 5: Screenshot des Ops Dashboards von Deep Insight
Abbildung 6: Detailansicht des Ops Dashboards von Deep Insight
Die Multi-Agent-Architektur von Deep Insight beschraenkt sich nicht auf den einzelnen Bereich der Erstellung von Datenanalyseberichten. Die folgenden beiden Beispiele zeigen, dass die hierarchischen Orchestrierungsprinzipien in voellig verschiedenen Domains wirksam bleiben.
Die Korea Sales Division von LG Electronics baute ChatInsight auf derselben Multi-Agent-Architektur wie Deep Insight, da Datenanalyseanfragen dort 2 bis 3 Wochen dauerten und dabei die Absicht zwischen Marketers und Data Scientists verloren ging. Der Coordinator routet nach Komplexitaet, der Planner verfolgt die Aufgaben, und der Supervisor orchestriert Coder und Reporter, wobei der Zustand zwischen den Agents kumulativ ueber eine Datei all_results.txt weitergegeben wird. Eine Analyse, die 3 Tage dauerte, dauert nun 30 Minuten, eine Produktivitaetssteigerung um den Faktor 288. Marketer ohne SQL-Kenntnisse koennen den Agent Daten erkunden und Strategien vorschlagen lassen (siehe das Agentic AI Insight Extraction System von LG Electronics im AWS Tech Blog).
Abbildung 7: Architektur des Agentic AI Marketing-Insight-Systems von LG Electronics
Praesentiert auf der AWS re:Invent 2025 (Session SNR203), wendet TechRecon die Architektur von Deep Insight auf Technologie-Strategie an. Angesichts eines Unternehmens und einer Branche sammelt ein Researcher Technologie-Trends, der Coder analysiert, der Validator verifiziert, und der Reporter erstellt eine Landscape Analysis und ein Technical Position Paper. Die Architektur ist fast identisch mit Deep Insight, gebaut mit dem Graph Pattern des Strands Agents SDK sowie Extended Thinking und Prompt Caching, wobei der Researcher den Coder als primaeren Ausfuehrungs-Agent ersetzt. Sie zeigt, dass das Design ein universelles Muster ist: Tauscht man die Rollen und Prompts der Agents aus, loest dieselbe Orchestrierungsstruktur voellig andere Probleme.
(Mehr dazu: TechRecon GitHub | AWS re:Invent Session Video)
Einen Agenten zu bauen, der im Produktivbetrieb funktioniert, ist keine Frage der Modellfaehigkeiten. Es ist eine Frage der Architektur. Deep Insight bietet eine erprobte Antwort:
LG Electronics’ Marketing-Insight-System und der TechRecon-Fall auf der re:Invent 2025 haben diese Designprinzipien bestaetigt.
In Teil 2 betrachten wir vier Ebenen von Context-Engineering-Techniken zur Ueberwindung von Kontextfenster-Grenzen auf dieser Architektur, von der Isolation auf Architekturebene ueber das Prompt-Design und die Tool-Optimierung bis hin zu Verifikations-Safeguards, und vergleichen unseren Ansatz mit der Engineering-Forschung von Anthropic.
Deep Insight ist Open Source. Erkunden Sie den Code und erweitern Sie ihn fuer Ihre eigene Domain.
Yoonseo ist Solutions Architect und hilft Kunden dabei, geschaeftliche Herausforderungen mit AWS-Technologien zu loesen. Mit einem starken Interesse an AI/ML konzentriert sie sich darauf, Kunden bei der Gestaltung und Optimierung von agentic-AI-Workloads sowie bei der Unterstuetzung von Infrastruktur- und Evaluationsumgebungen zu helfen.
Jesam ist Solutions Architect und unterstuetzt Enterprise-Kunden bei der Einfuehrung von Cloud-Technologien und der Loesung geschaeftlicher Herausforderungen. Mit dem Fokus auf AI/ML, einschliesslich Empfehlungssystemen und generativer KI, hilft er Kunden, Architekturen zu entwerfen, die ihren geschaeftlichen Anforderungen entsprechen.
Jiyun ist Solutions Architect und hilft Kunden aus der Software- und Internetbranche, ihre Workloads in die Cloud zu migrieren. Sie arbeitet mit Kunden an der Gestaltung von Cloud-Loesungen, die ihnen helfen, ihre Geschaeftsziele zu erreichen.
Kyutae, Ph.D., ist AI Specialist Solutions Architect und hilft Kunden aus verschiedenen Branchen beim Entwurf und Aufbau von Applied-AI-Workloads, gestuetzt auf umfangreicher Erfahrung im maschinellen Lernen, in MLOps und agentic AI. Sein Fokus liegt auf intelligenter Automatisierung und operativer Innovation durch agentic AI, wobei er autonome Entscheidungsfindung und Multi-Agenten-Kollaborationsarchitekturen in reale Geschaeftsumgebungen bringt. Durch diese Arbeit hilft er Kunden, AWS-AI/ML-Services und angewandte generative KI zu nutzen, um greifbare Geschaeftsergebnisse zu erzielen und einen nachhaltigen Wettbewerbsvorteil aufzubauen.
Gonsoo ist AI/ML Specialist Solutions Architect bei AWS. Gestuetzt auf Erfahrung mit vielfaeltigen AI/ML-Anwendungsfaellen und Produktivbereitstellungen arbeitet er eng mit Kunden zusammen, um ihre AI/ML-Herausforderungen zu loesen. Er teilt sein AI/ML-Wissen ausserdem mit Data Scientists, Entwicklern und Analysten und moechte damit zu einem positiven Wandel in Korea und weltweit beitragen.
Chloe ist Senior Solutions Architect im Korea-Retail-Team bei Amazon Web Services. Sie hilft Retail- und E-Commerce-Kunden in Korea, skalierbare und kosteneffiziente Cloud-Architekturen zu entwerfen und AI/ML-Services einzufuehren, um ihre Geschaeftsergebnisse zu beschleunigen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Building a multi-agent system is now pretty straightforward. Taking it to production is where the real challenges begin. Thanks to open source frameworks and cloud services, you can set up an agent in a matter of days. A few tool calls, a few lines of prompt, and you have something that looks impressive. But the moment teams try to move beyond a pilot and into real business applications, they hit a familiar wall. If you’ve ever tried to put an agent into production, these frustrations will sound familiar:
Why doesn’t the agent follow our business logic, skip validation steps, or catch edge cases?
You tweak the prompt, add more examples, swap out the model. The same problems keep coming back. That’s because agents don’t follow a fixed sequence of instructions. They make their own judgments based on context. Instructions alone aren’t enough. You need to design how the agent thinks, when it verifies, and what it does when things go wrong. This is exactly why it’s become critical to go beyond prompt engineering alone and design the agent’s entire cognitive architecture and execution flow.
To tackle these challenges head-on, the AWS Solutions Architecture team built Deep Insight, a production-grade multi-agent system. In this post series, we share what the team learned firsthand while building Deep Insight across three posts. We will walk through how we applied Context Engineering techniques proposed by Anthropic (multi-agent architecture, structured note-taking, human-in-the-loop, and more) in a real production environment. We also cover the trade-offs we encountered along the way (with code) and the operational insights we gained from deploying and running this agent on AWS.
This is Part 1 of a three-part series. It defines the five core challenges any production multi-agent system must solve and shows how each layer of the stack addresses them, from Strands Agents SDK and Amazon Bedrock to Amazon Bedrock AgentCore, Application Load Balancer, and AWS Fargate. Parts 2 and 3 cover Context Engineering and production deployment.
Deep Insight is a multi-agent system that turns complex data analysis into automated insights. Given a CSV file and a natural-language prompt, a hierarchy of specialized agents (Coordinator, Planner, Supervisor, Coder, Validator, Reporter, and Tracker) collaborates on the analysis. Together they load the data, run analyses, generate charts, validate calculations, and produce a professional report (.docx) with citations.
We will explore the architecture in detail later. First, let’s see it in action. For the demo, we feed advertising data from a fictional food company, Yummy Food ( yummy-food-market.csv ) with a column definitions file ( column_definitions.json ), and provide the prompt: Analyze this from a sales and marketing perspective, generate charts and insights, and produce a.docx report. Deep Insight generates an analysis plan, presents it to the user for approval, and, once approved, executes the analysis.
The Deep Insight web demo video that follows shows the full workflow, from uploading data and reviewing the analysis plan to real-time streaming and downloading the finished report.
Deep Insight is open sourced on GitHub with a full setup guide, and offers three deployment options spanning development to production.
The first is the Self-Hosted version, which runs locally through the CLI. It’s optimized for rapid iteration with full code-level access to every agent, prompt, and workflow. It sets up in about 10 minutes, which makes it well suited to development. (A Self-Hosted demo video is available on YouTube.)
The second is the Web version, a browser-based UI for uploading data, reviewing analysis plans (Human-in-the-Loop, or HITL), and downloading reports, all without writing code, making it accessible for non-developers. (The preceding demo video shows the Web version in action.)
The third is the Managed AgentCore version, a production deployment option powered by Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. This version deploys the agents on AgentCore runtime, a capability of Amazon Bedrock AgentCore. The system runs entirely within a private virtual private cloud (VPC), with a custom Code Interpreter hosted separately on AWS Fargate, and agents run concurrently in isolated per-user environments. It’s the right choice when you need session isolation and private VPC deployment. Part 3 covers its deployment and operations in detail.
All three share the same multi-agent architecture, so an agent validated in development deploys to production as-is.
Building a production multi-agent system takes more than good prompts. You need the right technology stack and infrastructure to address how agents collaborate, how they reason, how you deploy them, where they safely execute code, and how you monitor operational health. Deep Insight solves problems across these five key areas. Because the agents generate both code and report content, we also cover responsible AI controls for production in Solution detail 2.
The following architecture diagram (Figure 1) illustrates this at a glance. The green boxes represent the Strands Agents multi-agent structure, which addresses challenges 1 and 2 from the preceding table. We will cover this in detail in the upcoming Solution detail 1: Multi-agent system design section. The remaining infrastructure components shown in the diagram address challenges 3, 4, and 5, which we will walk through in Solution detail 2: Production deployment and operations.
Deep Insight uses a multi-agent architecture in which eight agents collaborate to produce one high-quality deliverable. Each agent works in its own independent context, performs only its specialized tasks, and passes only compressed results onward.
The Coordinator routes user requests, the Planner breaks tasks into discrete steps, the Plan Reviewer collects user feedback, and the Supervisor invokes the appropriate specialized agents according to the plan. The Coder writes and executes data analysis code, the Validator verifies calculations, the Reporter generates the final report, and the Tracker tracks progress. We will explain this across three layers:
Two key patterns from the Strands Agents SDK are combined to control execution flow across these agents. First, the Graph pattern defines the execution order and flow of agents as a directed graph. Requests flow Coordinator, Planner, Plan Reviewer, then Supervisor, with a conditional branch looping back to the Planner on revision requests. Determining the next step by condition makes complex workflows like HITL and error handling straightforward. Second, the Agents-as-Tools pattern lets the Supervisor invoke specialized agents (Coder, Validator, Reporter, Tracker) as tools only when needed. Each works in an independent context and returns only results, minimizing context usage while preserving domain expertise.
This section shows how the architecture solves routing, planning, and orchestration.
This layer turns a user request into an approved execution plan.
The Coordinator is the entry point for user requests. It handles basic greetings directly and routes complex tasks like data analysis to the Planner with a handoff_to_planner marker.
The key design decision is model selection: because the Coordinator only classifies, it uses the lightweight Claude Haiku, avoiding Opus-level costs on basic greetings and delivering fast responses.
# builder.py: conditional edges for routing decisions builder.set_entry_point("coordinator") builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner) Routing conditions come from the Coordinator’s prompt: any request needing tools, reasoning, or multi-step thinking goes to the Planner.
In Deep Insight’s multi-agent structure, the Planner agent plays the critical role of distributing tasks across agents. Before substantive work begins, it breaks large tasks into smaller steps, and each specialized agent executes them one at a time, keeping each agent’s context small.
The Planner uses a Claude Opus model with Extended Thinking turned on to develop the analysis plan. It organizes the plan into a [ ] checklist format that specifies concrete tasks assigned to each agent, stored in a full_plan variable. It breaks the request into 5–10 clear steps, as shown in the following example:
## title Yummy Food Consumer Purchase Patterns and Advertising Effectiveness Analysis Report ## steps ### 1. Coder: Comprehensive Data Analysis and Insight Generation - [ ] Load all data files from './data/*' path and understand structure - [ ] Analyze consumer purchase history (patterns, preferences, customer segments) - [ ] Analyze advertising data by channel (cost, effectiveness, channel comparison) - [ ] Category-level analysis (fresh food, convenience food, health food ad effectiveness) - [ ] Calculate key business metrics (conversion rate, CPA, ROAS, etc.) - [ ] Generate visualizations (5+ charts, consumer segment charts) - [ ] Derive strategic marketing insights - [ ] Generate calculation metadata (for validation) ### 2. Validator: Calculation Verification and Citation Metadata Generation - [ ] Identify verification targets and extract filter calculations - [ ] Load data files directly and perform recalculations - [ ] Verify accuracy of per-channel performance metrics - [ ] Validate data consistency of visuals and graphs - [ ] Generate citation metadata (reference numbers for verified items) ### 3.
Reporter: Marketing Analysis Report Generation - [ ] Write report overview - [ ] Create structured report using verified analysis results - [ ] Insert visualizations and analysis sections - [ ] Present marketing strategy recommendations and improvement proposals - [ ] Generate professional marketing report in DOCX format 1.3 Plan Reviewer The Plan Reviewer is a HITL node that presents the plan to the user and collects approval or revision feedback. If there is feedback, it loops back to the Planner to revise the plan. If approved, it hands the task off to the Supervisor.
A maximum revision count ( MAX_PLAN_REVISIONS ) is set to prevent infinite loops.
# builder.py: Plan Reviewer's bidirectional conditional edges builder.add_edge("plan_reviewer", "planner", condition=should_revise_plan) builder.add_edge("plan_reviewer", "supervisor", condition=should_proceed_to_supervisor) builder.set_max_node_executions(25) In the Web version, the Plan Reviewer shows a browser modal where the user reads the plan and approves it or enters revision feedback. A 300-second countdown auto-approves the plan if no response arrives.
Figure 3: Plan Reviewer agent execution in the web UI
Without planning, the agent decides everything at runtime, a mid-course correction invalidates previous work, and users have no visibility into progress. With the Planner and Plan Reviewer, the user can review and revise the plan, monitor progress in real time, and re-execute only a failed step.
The Supervisor executes the Planner’s full_plan in order, invoking the Layer 3 agents (Coder, Validator, Reporter, Tracker) as tools registered on it through Tool Use.
# nodes.py: registering sub-agents as tools on the Supervisor agent = strands_utils.get_agent( agent_name="supervisor", system_prompts=apply_prompt_template(prompt_name="supervisor", prompt_context={}), model_id=os.getenv("SUPERVISOR_MODEL_ID", os.getenv("DEFAULT_MODEL_ID")), prompt_cache_info=(True, "default"), tool_cache=True, tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool], streaming=True, ) The Supervisor’s system prompt defines strict workflow rules:
Each Layer 3 agent (Coder, Validator, Reporter, Tracker) is wrapped as a PythonAgentTool and receives Tool Use calls from the Supervisor. Each is created as an independent Agent() instance in the Strands SDK with its own system prompt, model ID, and toolset.
The Supervisor invokes Tool Use calls in this order, based on the Planner’s checklist:
Tracker runs after every agent so the Supervisor can track progress and enforce the completion rule (no moving on until all items are [x]). Because it updates the checklist with LLM reasoning and no tools, it adds little overhead.
Deep Insight tailors the model and settings to each agent’s role. This isn’t a model selection. It’s an architectural decision to optimize cost and quality.
The Supervisor, Coder, and Reporter agents use Prompt Caching to cache their system prompts and tool definitions, reducing input token costs by up to 90 percent on repeated calls. The Coordinator runs only once, and the Validator and Tracker run with different contexts each time, so caching is ineffective for them and stays disabled. This selective caching strategy is a deliberate cost/performance trade-off.
If Solution detail 1 defined what the system does, this section defines where and how it runs safely. Everything from here on covers infrastructure decisions for production operations. Specifically, this section covers the secure execution environment for LLM-generated code, and operational visibility for the team.
The Coder agent writes and runs Python for data analysis. In the Self-Hosted version it runs locally through subprocess.run(), but in production (AgentCore) security and isolation are essential. Running LLM-generated code directly on a production server is risky: the model might delete system files, exhaust resources in an infinite loop, or reach other users’ analysis data.
Deep Insight solves this with per-session ephemeral containers on AWS Fargate and ALB. These components don’t run in isolation. As shown in Figure 1, AgentCore runtime, the ALB, and the Fargate tasks all run inside the same private VPC.
VPC endpoints connect them to Amazon Simple Storage Service (Amazon S3), Amazon Bedrock, and Amazon Elastic Container Registry (Amazon ECR) without traversing the public internet. Security groups restrict which components can reach the Code Interpreter containers. AWS Identity and Access Management (IAM) roles scope each component to only the AWS resources it needs.
Amazon CloudWatch collects container logs and observability data from AgentCore Observability, a capability of Amazon Bedrock AgentCore.
Container isolation protects the infrastructure, but it doesn’t govern what the agents generate. The Validator agent re-verifies calculations. It doesn’t detect prompt-injection instructions hidden in uploaded data or screen LLM-generated text for harmful or ungrounded content. For production deployments, we recommend adding Amazon Bedrock Guardrails as a responsible AI control: apply content filters and prompt attack detection to user prompts and uploaded data, and apply contextual grounding checks to agent outputs so that report text stays grounded in the source data and verified calculations.
A production system isn’t complete with code alone. The team must assess system health, diagnose issues, and review results, so Deep Insight provides a Web UI and an Ops dashboard.
A FastAPI-based web interface that communicates with the backend through the AgentCore Native Protocol ( boto3.invoke_agent_runtime() ). Users upload data and enter a prompt, then monitor progress through Server-Sent Events (SSE) streaming. When the plan is generated, a modal lets the user approve or give revision feedback (HITL). The finished report can be downloaded directly. Both Korean and English are supported.
Figure 4: Deep Insight web version screenshot
The Ops dashboard is optional. Deep Insight works fine without it, but it adds these features for teams that need them:
Figure 5: Deep Insight Ops dashboard screenshot
Figure 6: Deep Insight Ops dashboard detail view
Deep Insight’s multi-agent architecture isn’t confined to the single domain of data analysis report generation. The following two examples demonstrate that the hierarchical orchestration design principles remain effective in entirely different domains.
LG Electronics’ Korea Sales Division built ChatInsight on the same multi-agent architecture as Deep Insight, where data analysis requests had taken 2–3 weeks and lost intent between marketers and data scientists. The Coordinator routes by complexity, the Planner tracks tasks, and the Supervisor orchestrates the Coder and Reporter, with inter-agent state passed cumulatively through an all_results.txt file. Analysis that took 3 days now takes 30 minutes, a 288x productivity improvement. Marketers who don’t know SQL can let the agent explore data and propose strategies (see the LG Electronics Agentic AI Insight Extraction System on the AWS Tech Blog ).
Figure 7: LG Electronics Agentic AI marketing insight system architecture
Presented at AWS re:Invent 2025 (session SNR203), TechRecon applies Deep Insight’s architecture to technology strategy. Given a company and sector, a Researcher gathers technology trends, the Coder analyzes, the Validator verifies, and the Reporter produces a Landscape Analysis and a Technical Position Paper. The architecture is nearly identical to Deep Insight, built with the Strands Agents SDK Graph pattern and Extended Thinking and Prompt Caching, with Researcher replacing Coder as the primary execution agent. It shows the design is a general-purpose pattern: swap the agents’ roles and prompts, and the same orchestration structure solves entirely different problems.
(Read more: TechRecon GitHub | AWS re:Invent Session Video )
Building an agent that works in production is not a matter of model capability. It’s a matter of architecture. Deep Insight offers a proven answer:
LG Electronics’ marketing insight system and the TechRecon case at re:Invent 2025 validated these design principles.
In Part 2, we examine four layers of Context Engineering techniques for overcoming context-window limits on top of this architecture, from architecture-level isolation to prompt design, tool optimization, and verification safeguards, comparing our approach with Anthropic’s engineering research.
Deep Insight is open source. Explore the code and extend it for your own domain.
Yoonseo is a Solutions Architect who helps customers solve business challenges using AWS technologies. With a strong interest in AI/ML, she focuses on helping customers design and optimize agentic AI workloads, along with supporting infrastructure and evaluation environments.
Jesam is a Solutions Architect who helps enterprise customers adopt cloud technologies and solve business challenges. With a focus on AI/ML, including recommendation systems and generative AI, he helps customers design architectures that meet their business needs.
Jiyun is a Solutions Architect who helps customers in the software and internet industries migrate their workloads to the cloud. She works with customers to design cloud solutions that help them achieve their business goals.
Kyutae, Ph.D. is an AI Specialist Solutions Architect who helps customers across industries design and build applied AI workloads, drawing on extensive experience in machine learning, MLOps, and agentic AI. He focuses on intelligent automation and operational innovation through agentic AI, bringing autonomous decision-making and multi-agent collaboration architectures into real-world business environments. Through this work, he helps customers use AWS AI/ML services and applied generative AI to achieve tangible business outcomes and build a sustainable competitive advantage.
Gonsoo is an AI/ML Specialist Solutions Architect at AWS. Drawing on experience across diverse AI/ML use cases and production deployments, he works closely with customers to solve their AI/ML challenges. He also shares AI/ML knowledge with data scientists, developers, and analysts, aiming to contribute to positive change in Korea and around the world.
Chloe is a Senior Solutions Architect on the Korea Retail team at Amazon Web Services. She helps retail and e-commerce customers in Korea design scalable, cost-effective cloud architectures and adopt AI/ML services to accelerate their business outcomes.