5 Produktionsherausforderungen in Multi-Agenten-Systemen und wie Deep Insight sie gelöst hat

Ein Multi-Agenten-System zu bauen ist nowadays ziemlich unkompliziert. Es in Produktion zu bringen ist der Punkt, an dem die eigentlichen Herausforderungen beginnen. Dank Open-Source-Frameworks und Cloud-Services 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 an eine bekannte Wand. Wenn Sie jemals versucht haben, einen Agenten in Produktion zu bringen, werden Ihnen diese Frustrationen bekannt vorkommen:

Warum folgt der Agent nicht unserer Geschäftslogik, überspringt Validierungsschritte oder erkennt Randfälle nicht?

Sie passen den Prompt an, fügen weitere Beispiele hinzu, wechseln das Modell. Die gleichen Probleme kehren immer wieder zurück. Das liegt daran, dass Agenten keiner festen Abfolge von Anweisungen folgen. Sie treffen eigene 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 Insightgebaut, ein produktionsreifes Multi-Agenten-System. In dieser Beitragsserie teilen wir in drei Beiträgen, was das Team beim Aufbau von Deep Insight aus erster Hand gelernt hat. Wir zeigen, wie wir die von Anthropic vorgeschlagenen Context-Engineering-Techniken (Multi-Agenten-Architektur, strukturierte Notizen, Human-in-the-Loop und mehr) in einer echten Produktionsumgebung angewendet haben. Wir gehen auch auf die dabei gewonnenen Trade-offs (mit Code) und die operativen Erkenntnisse ein, die wir aus dem Deployment und dem Betrieb dieses Agenten auf AWS gewonnen haben.

Überblick über die Blogserie

• Teil 1: 5 Produktionsherausforderungen in Multi-Agenten-Systemen und wie Deep Insight sie gelöst hat.
• Teil 2: Jenseits des Kontextfensters: Context-Engineering-Techniken und wie Deep Insight sie angewendet hat.
• Teil 3: Harness Engineering in der Praxis: Deep Insight von der Entwicklung in die Produktion bringen.

Dies ist Teil 1 einer dreiteiligen Serie. Er definiert die fünf Kernherausforderungen, die jedes Multi-Agenten-Produktionssystem lösen muss, und zeigt, wie jede Schicht des Stacks diese adressiert, von Strands Agents SDK und Amazon Bedrock über Amazon Bedrock AgentCore, Application Load Balancerbis hin zu AWS Fargate. Die Teile 2 und 3 behandeln Context Engineering und das Production Deployment.

Vorstellung von Deep Insight

Deep Insight ist ein Multi-Agenten-System, das komplexe Datenanalyse in automatisierte Erkenntnisse verwandelt. Bei einer CSV-Datei und einem Prompt in natürlicher Sprache arbeitet eine Hierarchie spezialisierter Agenten (Coordinator, Planner, Supervisor, Coder, Validator, Reporter und Tracker) bei der Analyse zusammen. Gemeinsam laden sie die Daten, führen Analysen durch, erstellen Diagramme, validieren Berechnungen und erzeugen einen professionellen Bericht (.docx) mit Quellenangaben.

Wir werden uns die Architektur später im Detail ansehen. Zunächst sehen wir sie in Aktion. Für die Demo geben wir Werbedaten eines fiktiven Lebensmittelunternehmens, Yummy Food (yummy-food-market.csv) zusammen mit einer Spaltendefinitionsdatei (column_definitions.json) ein und stellen den Prompt: Analysiere dies aus Vertriebs- und Marketingsicht, erstelle Diagramme und Erkenntnisse und produziere einen .docx-Bericht. Deep Insight erstellt einen Analyseplan, legt ihn dem Benutzer zur Genehmigung vor und führt nach der Genehmigung die Analyse aus.

Das Deep Insight Web-Demovideo das Folgende zeigt den vollständigen Arbeitsablauf, vom Hochladen der Daten und Prüfen des Analyseplans bis zum Echtzeit-Streaming und Herunterladen des fertigen Berichts.

Wie kann ich es ausprobieren?

Deep Insight ist Open Source auf GitHub veröffentlicht, mit einer vollständigen Einrichtungsanleitung, und bietet drei Deployment-Optionen von der Entwicklung bis zur Produktion.

Die erste ist die Self-Hosted-Version, die lokal über die CLI läuft. Sie ist für schnelle Iteration mit vollständigem Codezugriff auf jeden Agenten, jeden Prompt und jeden Workflow optimiert. Die Einrichtung dauert etwa 10 Minuten, was sie gut für die Entwicklung geeignet macht. (Ein Self-Hosted-Demovideo ist verfügbar auf YouTube.)

Das zweite ist die Web-Version, eine browserbasierte Benutzeroberfläche zum Hochladen von Daten, Überprüfen von Analyseplänen (Human-in-the-Loop bzw. HITL) und Herunterladen von Berichten – alles ohne Programmierung, was sie auch für Nicht-Entwickler zugänglich macht. (Das vorherige Demo-Video zeigt die Web-Version in Aktion.)

Das dritte ist die Managed AgentCore-Version, eine Produktionsbereitstellungsoption, die von Amazon Bedrock AgentCore betrieben wird – einer Plattform zum Erstellen, Verbinden und Optimieren von Agents in großem Maßstab, mit beliebigen Frameworks oder Modellen. Diese Version stellt die Agents auf dem AgentCore Runtime bereit, einer Funktion von Amazon Bedrock AgentCore. Das System läuft vollständig innerhalb einer privaten Virtual Private Cloud (VPC), mit einem benutzerdefinierten Code Interpreter, der separat auf AWS Fargate gehostet wird, und die Agents laufen gleichzeitig in isolierten Umgebungen pro Benutzer. Es ist die richtige Wahl, wenn Sie Sitzungsisolation und eine private VPC-Bereitstellung benötigen. Teil 3 behandelt ihre Bereitstellung und den Betrieb im Detail.

Alle drei teilen sich dieselbe Multi-Agent-Architektur, sodass ein in der Entwicklung validierter Agent unverändert in die Produktion überführt werden kann.

Lösungsübersicht

Der Aufbau eines produktionsreifen Multi-Agenten-Systems erfordert mehr als nur gute Prompts. Sie benötigen den richtigen Technologie-Stack und die passende Infrastruktur, um zu steuern, wie Agents zusammenarbeiten, wie sie schlussfolgern, wie Sie sie bereitstellen, wo sie Code sicher ausführen und wie Sie den operativen Zustand überwachen. Deep Insight löst Probleme in diesen fünf Schlüsselbereichen. Da die Agents sowohl Code als auch Berichtsinhalte generieren, behandeln wir in Lösungsdetail 2 auch Kontrollen für verantwortungsvolle KI (Responsible AI) für die Produktion.

Das folgende Architekturdiagramm (Abbildung 1) veranschaulicht dies auf einen Blick. Die grünen Felder repräsentieren die Multi-Agenten-Struktur von Strands Agents, die die Herausforderungen 1 und 2 aus der vorherigen Tabelle behandelt. Darauf gehen wir im Abschnitt Lösungsdetail 1: Entwurf des Multi-Agenten-Systems im Detail ein. Die übrigen im Diagramm gezeigten Infrastrukturkomponenten behandeln die Herausforderungen 3, 4 und 5, die wir in Lösungsdetail 2: Produktionsbereitstellung und Betrieb durchgehen werden.

Abbildung 1: Lösungsarchitektur

Lösungsdetail 1: Entwurf des Multi-Agenten-Systems

Deep Insight verwendet eine Multi-Agenten-Architektur, bei der acht Agents zusammenarbeiten, um ein hochwertiges Ergebnis zu erstellen. Jeder Agent arbeitet in seinem eigenen unabhängigen Kontext, führt nur seine spezialisierten Aufgaben aus und gibt nur komprimierte Ergebnisse weiter.

Abbildung 2: Multi-Agenten-Struktur

Der Coordinator leitet Benutzeranfragen weiter, der Planner zerlegt Aufgaben in einzelne Schritte, der Plan Reviewer sammelt Benutzerfeedback, und der Supervisor ruft die entsprechenden spezialisierten Agents gemäß dem Plan auf. Der Coder schreibt und führt Datenanalyse-Code aus, der Validator überprüft Berechnungen, der Reporter erstellt den Abschlussbericht, und der Tracker verfolgt den Fortschritt. Wir werden dies über drei Ebenen hinweg erklären:

• [1. Ebene] Coordinator zu Planner zu Plan Reviewer: Anfrageanalyse und Erstellung des Ausführungsplans.
• [2. Ebene] Supervisor: Orchestrierung spezialisierter Agents.
• [3. Ebene] Coder, Validator, Reporter, Tracker: Ausführung spezialisierter Aufgaben.

Zwei zentrale Muster aus dem Strands Agents SDK werden kombiniert, um den Ausführungsfluss über diese Agents hinweg zu steuern. Erstens definiert das Graph-Muster die Ausführungsreihenfolge und den Fluss der Agents als gerichteten Graphen. Anfragen fließen vom Coordinator zum Planner, zum Plan Reviewer und dann zum Supervisor, wobei ein bedingter Zweig bei Überarbeitungsanfragen zum Planner zurückschleift. Die Bestimmung des nächsten Schritts über eine Bedingung macht komplexe Workflows wie HITL und Fehlerbehandlung unkompliziert. Zweitens ermöglicht das Agents-as-Tools-Muster dem Supervisor, spezialisierte Agents (Coder, Validator, Reporter, Tracker) als Tools nur bei Bedarf aufzurufen. Jeder arbeitet in einem unabhängigen Kontext und gibt nur Ergebnisse zurück, was die Kontextnutzung minimiert und gleichzeitig die Domänenexpertise bewahrt.

Dieser Abschnitt zeigt, wie die Architektur Routing, Planung und Orchestrierung löst.

[1. Ebene] Coordinator zu Planner zu Plan Reviewer

Diese Ebene verwandelt eine Benutzeranfrage in einen genehmigten Ausführungsplan.

1.1 Coordinator (Routing): Nicht jede Anfrage benötigt teure Orchestrierung

Der Coordinator ist der Einstiegspunkt für Benutzeranfragen. Er behandelt einfache Begrüßungen direkt und leitet komplexe Aufgaben wie Datenanalyse mit einer handoff_to_planner-Markierung an den Planner weiter.

Die zentrale Designentscheidung ist die Modellauswahl: Da der Coordinator nur klassifiziert, verwendet er das leichtgewichtige Claude Haiku, wodurch Opus-Kosten bei einfachen Begrüßungen vermieden und schnelle Antworten geliefert werden.

# builder.py: conditional edges for routing decisions
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, Schlussfolgern oder mehrstufiges Denken erfordert, geht an den Planner.

1.2 Planner (Plainerstellung): Komplexe Analysen benötigen vor der Ausführung eine Zerlegung

In der Multi-Agent-Struktur von Deep Insight spielt der Planner-Agent die entscheidende Rolle, Aufgaben auf die Agents zu verteilen. Bevor die eigentliche Arbeit beginnt, zerlegt er große Aufgaben in kleinere Schritte, und jeder spezialisierte Agent führt sie einzeln aus, wodurch der Kontext jedes Agents klein bleibt.

Der Planner verwendet ein Claude Opus-Modell mit aktiviertem Extended Thinking, um den Analyseplan zu entwickeln. Er gliedert den Plan in ein [ ] Checklistenformat, das jedem Agent zugewiesene konkrete Aufgaben angibt, und speichert es in einer full_plan Variablen. Er zerlegt die Anfrage in 5–10 klare Schritte, wie im folgenden Beispiel gezeigt:

## 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

Der Plan Reviewer ist ein HITL-Knoten, der dem Benutzer den Plan präsentiert und Zustimmung oder Überarbeitungsfeedbackeinsammelt. Gibt es Feedback, springt er zum Planner zurück, um den Plan zu überarbeiten. Bei Zustimmung übergibt er die Aufgabe an den Supervisor. Eine maximale Überarbeitungsanzahl (MAX_PLAN_REVISIONS) ist festgelegt, um Endlosschleifen zu verhindern.

# 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 der Web-Version zeigt der Plan Reviewer ein Browser-Modal an, in dem der Benutzer den Plan liest und ihn genehmigt oder Überarbeitungsfeedback eingibt. Ein 300-Sekunden-Countdown genehmigt den Plan automatisch, wenn keine Antwort eingeht.

Abbildung 3: Ausführung des Plan Reviewer-Agents in der Web-UI

Ohne Planung entscheidet der Agent alles zur Laufzeit, eine Zwischenkorrektur macht frühere Arbeit ungültig, und Benutzer haben keine Sichtbarkeit des Fortschritts. Mit dem Planner und Plan Reviewer kann der Benutzer den Plan prüfen und überarbeiten, den Fortschritt in Echtzeit verfolgen und nur einen fehlgeschlagenen Schritt erneut ausführen.

[2. Ebene] Supervisor (Orchestrator): Spezialisierte Agents benötigen einen Dirigenten

Der Supervisor führt die full_plan des Planner der Reihe nach aus und ruft dabei die Agents der Ebene 3 (Coder, Validator, Reporter, Tracker) als Tools auf, die über Tool Use bei ihm registriert sind.

# 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,
)

Der System-Prompt des Supervisors definiert strenge Workflow-Regeln:

• Verpflichtende Ausführungsreihenfolge: Coder, Tracker, Validator, Tracker, Reporter, Tracker: Nachdem jeder Agent ausgeführt wurde, wird Tracker aufgerufen, um den Fortschritt zu verfolgen, wodurch der Supervisor den Gesamtzustand der Aufgabe verwalten kann.
• Regel zum Abschluss eines Abschnitts: Der Supervisor geht nicht zum nächsten Agent über, bevor alle Checklistenpunkte des aktuellen Agent als [x] markiert sind.
• Kontexterhalt: Der Supervisor übergibt jedem Tool-Agent die Variablen clues und full_plan, um den vollen Kontext zu bewahren und Informationsverlust zu verhindern.

[3. Schicht] Coder, Validator, Reporter, Tracker: Arbeitsteilung steigert die Qualität

Jeder Layer-3-Agent (Coder, Validator, Reporter, Tracker) ist verpackt als PythonAgentTool und erhält Tool-Use-Aufrufe vom Supervisor. Jeder wird als unabhängige Agent() -Instanz im Strands SDK mit eigenem System-Prompt, Modell-ID und Toolset erstellt.

Der Supervisor ruft Tool-Use-Aufrufe in dieser Reihenfolge auf, basierend auf der Checkliste des Planner:

1. Coder – Lädt Daten, schreibt und führt Analysecode aus, erzeugt PNG-Diagramme, sammelt Ergebnisse in all_results.txt und hinterlegt sie dort calculation_metadata.json zur Verifikation.
2. Tracker (1. Durchlauf) – Aktualisiert abgeschlossene Checklisten-Elemente von [ ] auf [x], woran der Supervisor festmacht, ob fortgefahren wird.
3. Validator – Führt jede Berechnung in calculation_metadata.json anhand der Quelldaten erneut durch. Übereinstimmungen innerhalb von 0.01 bestehen, Abweichungen werden markiert. Verifizierte Berechnungen gehen an citations.json damit der Reporter sie zitieren kann.
4. Tracker (2. Durchlauf) – Spiegelt den Abschlussstatus des Validator in der Checkliste wider.
5. Reporter – Liest all_results.txt und citations.json um den finalen DOCX-Bericht in zwei Versionen zu erzeugen, mit und ohne Zitationen.
6. Tracker (3. Durchlauf) – Spiegelt den finalen Abschlussstatus aller Aufgaben wider.

Der Tracker läuft nach jedem Agenten, damit der Supervisor den Fortschritt verfolgen und die Abschlussregel durchsetzen kann (kein Weitergehen, bevor alle Elemente [x] sind). Da er die Checkliste nur mit LLM-Reasoning und ohne Tools aktualisiert, verursacht er kaum Overhead.

LLM-Modellkonfiguration pro Agent

Deep Insight passt Modell und Einstellungen an die Rolle jedes Agenten an. Dies ist keine Modellauswahl. Es ist eine architektonische Entscheidung zur Optimierung von Kosten und Qualität.

Die Agenten Supervisor, Coder und Reporter verwenden Prompt Caching, um ihre System-Prompts und Tool-Definitionen zu cachen, wodurch die Eingabe-Token-Kosten bei wiederholten Aufrufen um bis zu 90 Prozent sinken. Der Coordinator läuft nur einmal, und der Validator sowie der Tracker laufen jedes Mal mit unterschiedlichen Kontexten, daher ist Caching für sie wirkungslos und bleibt deaktiviert. Diese selektive Caching-Strategie ist ein bewusster Kompromiss zwischen Kosten und Leistung.

Lösungsdetail 2: Produktionsbereitstellung und Betrieb

Wenn Solution detail 1 definiert was das System tut, so definiert dieser Abschnitt, wo und wie es sicher läuft. Alles Folgende behandelt Infrastrukturentscheidungen für den Produktionsbetrieb. Konkret behandelt dieser Abschnitt die sichere Ausführungsumgebung für LLM-generierten Code sowie die operative Sichtbarkeit für das Team.

1. Code-Ausführung: LLM-generierter Code benötigt eine sichere Ausführungsumgebung

Der Coder-Agent schreibt und führt Python zur Datenanalyse aus. In der Self-Hosted-Version läuft er lokal über subprocess.run(), aber in der Produktion (AgentCore) sind Sicherheit und Isolation essenziell. LLM-generierten Code direkt auf einem Produktionsserver auszuführen ist riskant: Das Modell könnte Systemdateien löschen, Ressourcen in einer Endlosschleife erschöpfen oder auf Analysedaten anderer Benutzer zugreifen. Deep Insight löst dies mit flüchtigen Containern pro Sitzung auf AWS Fargate und ALB. Diese Komponenten laufen nicht isoliert. Wie in Abbildung 1 gezeigt, laufen der AgentCore-Runtime, der ALB und die Fargate-Tasks alle innerhalb desselben privaten VPC. VPC-Endpunkte verbinden sie mit Amazon Simple Storage Service (Amazon S3), Amazon Bedrock und Amazon Elastic Container Registry (Amazon ECR), ohne das öffentliche Internet zu durchqueren. Sicherheitsgruppen beschränken, welche Komponenten die Code-Interpreter-Container erreichen können. AWS Identity and Access Management (IAM)-Rollen beschränken jede Komponente auf nur die AWS-Ressourcen, die sie benötigt. Amazon CloudWatch sammelt Container-Protokolle und Observability-Daten von AgentCore Observability, einer Funktion von Amazon Bedrock AgentCore.

• Benutzerdefiniertes Container-Docker-Image: Eine voptimierte Sandbox mit Schriftarten, Systembibliotheken und Python-Paketen für das Multi-Agenten-System.
• Container-Isolation: Jede Analysesitzung erhält einen unabhängigen Fargate-Container in einem privaten VPC-Subnetz ohne direkten Internetzugang.
• 2-stufige Ausführung: LLM-generierter Code wird base64-kodiert, über HTTP gesendet, in eine Datei geschrieben (Schritt 1) und dann über subprocess ausgeführt (Schritt 2).
• Sitzungsaffinität: Sticky-Session-Cookies des ALB leiten einen Agenten zurück zum selben Container, selbst wenn er Code mehrmals ausführt.
• Artefaktverwaltung: Diagramme, Berichte und Protokolle werden nach Abschluss der Analyse zu Amazon S3 hochgeladen. Container werden nach einer Stunde automatisch beendet.

Die Container-Isolation schützt die Infrastruktur, aber sie regelt nicht, was die Agenten generieren. Der Validator-Agent überprüft Berechnungen erneut. Er erkennt keine in hochgeladenen Daten versteckten Prompt-Injection-Anweisungen und prüft LLM-generierten Text nicht auf schädliche oder unbegründete Inhalte. Für Produktionsumgebungen empfehlen wir das Hinzufügen von Amazon Bedrock Guardrails als Responsible-AI-Kontrolle: wenden Inhaltsfilter und Prompt-Attack-Detection auf Benutzer-Prompts und hochgeladene Daten an, und wenden kontextuelle Grounding-Prüfungen auf Agent-Ausgaben an, damit der Berichtstext auf den Quelldaten und verifizierten Berechnungen basiert bleibt.

2. Betrieb und Überwachung: Teams benötigen Sichtbarkeit

Ein Produktionssystem ist nicht allein mit Code vollständig. Das Team muss den Systemzustand beurteilen, Probleme diagnostizieren und Ergebnisse prüfen, daher bietet Deep Insight eine Web-UI und ein Ops-Dashboard.

Web-UI (deep-insight-web)

Eine auf FastAPI basierende Webschnittstelle, die über das AgentCore Native Protocol (boto3.invoke_agent_runtime()) mit dem Backend kommuniziert. Benutzer laden Daten hoch und geben einen Prompt ein, dann verfolgen sie den Fortschritt über Server-Sent Events (SSE)-Streaming. Sobald der Plan generiert ist, ermöglicht ein modales Dialogfeld dem Benutzer, diesen zu genehmigen oder Revisionsfeedback zu geben (HITL). Der fertige Bericht kann direkt heruntergeladen werden. Sowohl Koreanisch als auch Englisch werden unterstützt.

Abbildung 4: Screenshot der Deep Insight Web-Version

Ops-Dashboard (deep-insight-web/ops)

Das Ops-Dashboard ist optional. Deep Insight funktioniert auch ohne es einwandfrei, aber es bietet Teams, die es benötigen, folgende Funktionen:

• Task-Tracking: Alle Metriken der Analysetasks, einschließlich Status, Token-Nutzung und verstrichener Zeit, werden in Amazon DynamoDB aufgezeichnet.
• Fehlerbenachrichtigung: Wenn eine Analyse fehlschlägt, wird sofort eine E-Mail über Amazon SNS an Administratoren gesendet.
• Admin-Dashboard: Ein dediziertes Admin-Dashboard ist durch JSON Web Token (JWT)-Authentifizierung über Amazon Cognito für sichere Task-Überwachung geschützt.

Abbildung 5: Screenshot des Deep Insight Ops-Dashboards

Abbildung 6: Detailansicht des Deep Insight Ops-Dashboards

Erweiterung der Deep Insight Architektur

Deep Insights Multi-Agenten-Architektur ist nicht auf die einzige Domäne der Berichtsgenerierung aus Datenanalyse beschränkt. Die folgenden beiden Beispiele zeigen, dass die hierarchischen Orchestrierungs-Entwurfsprinzipien in völlig anderen Domänen ebenso wirksam bleiben.

Fall 1: LG Electronics: Agentic-AI-gestütztes System zur Extraktion von Marketing-Insights

Die Korea Sales Division von LG Electronics baute ChatInsight auf derselben Multi-Agenten-Architektur wie Deep Insight, wobei Datenanalyseanfragen 2–3 Wochen dauerten und die Absicht zwischen Marketingfachleuten und Data Scientists verloren ging. Der Coordinator leitet nach Komplexität weiter, der Planner verfolgt Tasks, und der Supervisor orchestriert den Coder und den Reporter, wobei der Zustand zwischen Agenten kumulativ über eine all_results.txt-Datei übergeben wird. Eine Analyse, die 3 Tage dauerte, dauert jetzt 30 Minuten – eine Produktivitätsverbesserung um den Faktor 288. Marketingfachleute, die kein SQL beherrschen, können den Agenten Daten erkunden und Strategien vorschlagen lassen (siehe LG Electronics Agentic AI Insight Extraction System auf dem AWS Tech Blog).

Abbildung 7: Architektur des Agentic-AI-Marketing-Insight-Systems von LG Electronics

Fall 2: TechRecon: KI-gestützter Technology-Reconnaissance-Agent (re:Invent 2025)

Auf der AWS re:Invent 2025 vorgestellt (Session SNR203), wendet TechRecon die Architektur von Deep Insight auf Technologie strategien an. Angesichts eines Unternehmens und einer Branche sammelt ein Researcher Technologietrends, der Coder analysiert, der Validator verifiziert, und der Reporter erstellt eine Landscape Analysis und ein Technical Position Paper. Die Architektur ist nahezu identisch mit Deep Insight, aufgebaut mit dem Graph-Muster des Strands Agents SDK sowie Extended Thinking und Prompt Caching, wobei der Researcher den Coder als primären Ausführungs-Agenten ersetzt. Sie zeigt, dass das Design ein universelles Muster ist: Tauscht man die Rollen und Prompts der Agenten aus, löst dieselbe Orchestrierungsstruktur völlig unterschiedliche Probleme.

Abbildung 8: TechRecon-Ergebnisse

(Mehr lesen: TechRecon GitHub | AWS re:Invent Session Video)

Fazit

Einen Agenten zu bauen, der in der Produktion funktioniert, ist keine Frage der Modellfähigkeit. Es ist eine Frage der Architektur. Deep Insight bietet eine erprobte Antwort:

• Workflow-Management: Das Graph-Muster des Strands Agents SDK definiert die Ausführungsreihenfolge zwischen Agenten und implementiert HITL-Verzweigungen, während das Agents-as-Tools-Muster dem Supervisor ermöglicht, spezialisierte Agenten nur bei Bedarf aufzurufen.
• Reasoning-Engine: Wir weisen Claude-Modelle aus Amazon Bedrock nach Rolle zu (Haiku, dann Opus, dann Sonnet), um Kosten und Qualität zu optimieren.
• Deployment: Amazon Bedrock AgentCore bietet eine verwaltete Runtime mit Session-Isolation, privatem VPC-Deployment und OpenTelemetry-Observability.
• Code-Ausführung: Ein Application Load Balancer plus Amazon Elastic Container Service (Amazon ECS) auf Fargate isoliert die Ausführung von LLM-generiertem Code in ephemeren Sandbox-Containern pro Session und verhindert Sicherheitsprobleme wie den Zugriff auf Systemdateien, Ressourcenerschöpfung und unbeabsichtigte Weitergabe von Daten.
• Betrieb: Das SSE-Streaming der Web-UI und das Ops-Dashboard (DynamoDB + Cognito + SNS) bieten Sichtbarkeit für das gesamte Team.

Das Marketing-Insight-System von LG Electronics und der TechRecon-Fall auf dem re:Invent 2025 haben diese Designprinzipien validiert.

In Teil 2 untersuchen wir vier Schichten von Context-Engineering-Techniken zur Überwindung von Context-Window-Grenzen auf dieser Architektur, von der Isolation auf Architekturebene über Prompt-Design und Tool-Optimierung bis hin zu Verifikationsschutzmaßnahmen, und vergleichen unseren Ansatz mit der Engineering-Forschung von Anthropic.

Deep Insight ist Open Source. Erkunden Sie den Code und erweitern Sie ihn für Ihre eigene Domäne.

• GitHub
• Workshop: Deep Insight Workshop (Englisch | Koreanisch)

Über die Autoren