cost analysis implemented.

thesis/chapters/02-stand-der-forschung.qmd

@@ -1,61 +1,180 @@
 # Stand der Forschung {#sec-forschung}
 
-Dieses Kapitel beschreibt den aktuellen wissenschaftlichen und technologischen 
-Stand zu Multi-Agent-Systemen, Kommunikationsarchitekturen und KI-Plattformen.
+Dieses Kapitel beschreibt den aktuellen wissenschaftlichen und technologischen Stand zu Multi-Agent-Systemen, Kommunikationsarchitekturen und KI-Plattformen. Die Darstellung ermöglicht eine Einordnung bestehender Ansätze und bildet die Grundlage für die spätere Identifikation bestehender Forschungs- und Technologielücken.
+
+Das Kapitel gliedert sich in drei Hauptteile. Zunächst werden die theoretischen Grundlagen von Multi-Agenten-Systemen (MAS), einschließlich spieltheoretischer Konzepte und grundlegender Architekturprinzipien, erörtert (@sec-mas-grundlagen). Darauf aufbauend analysiert @sec-frameworks den Stand der Technik bei Multi-Agent-Frameworks. Die Auswahl der untersuchten Frameworks – AutoGen, CrewAI und LangChain – wurde auf Basis ihrer entsprechenden architektonischen Ansätze und ihrer Eignung für die Anforderungen der satware AI Autonomous Agent Platform (SAAP) getroffen. LangChain dient als etabliertes, modulares Basis-Framework, während AutoGen und CrewAI spezialisierte, neuere Ansätze für die dynamische bzw. rollenbasierte Agenten-Orchestrierung repräsentieren [@aimultiple2025].
+
+Diese Auswahl ermöglicht einen umfassenden Vergleich der führenden Paradigmen in der Agenten-Entwicklung und deren Eignung für die Anforderungen der SAAP-Plattform. Der dritte Teil des Kapitels untersucht die technologischen Ökosysteme, die für die Implementierung der SAAP-Plattform relevant sind. Dies umfasst eine Analyse von Kommunikationsprotokollen (@sec-protokolle), Integrationsstrategien für Large Language Models (LLMs) wie Ollama, Hugging Face und OpenRouter (@sec-llm-integration), etablierte Enterprise-KI-Plattformen (@sec-enterprise-plattformen) und die rechtlichen sowie technischen Anforderungen an eine DSGVO-konforme KI (@sec-dsgvo).
 
 ## Grundlagen der Multi-Agenten-Systeme {#sec-mas-grundlagen}
 
-Multi-Agent-Systeme (MAS) sind ein Teilgebiet der Künstlichen Intelligenz, 
-das sich mit der Konzeption und Implementierung von Systemen befasst, die aus 
-mehreren autonomen, interagierenden Einheiten – den Agenten – bestehen [@wooldridge2001].
+Multi-Agent-Systeme (MAS) sind ein Teilgebiet der Künstlichen Intelligenz, das sich mit der Konzeption und Implementierung von Systemen befasst, die aus mehreren autonomen, interagierenden Einheiten – den Agenten – bestehen. Diese Agenten arbeiten zusammen, um Probleme zu lösen, die die Fähigkeiten eines einzelnen Agenten übersteigen würden [@wooldridge2001]. Im Gegensatz zu monolithischen Systemen zeichnen sich MAS durch Dezentralisierung, Parallelität und Robustheit aus.
+
+### Theoretische Grundlagen und Architekturprinzipien {#sec-theorie}
+
+Die theoretischen Grundlagen von Multi-Agent-Systemen sind interdisziplinär und stützen sich auf Konzepte aus der Spieltheorie, der Logik und der verteilten Problemlösung [@russell2021; @fagin2020; @stone2000]. Diese Prinzipien sind entscheidend für das Verständnis, wie Agenten rational entscheiden, kooperieren und ihre Ziele erreichen.
+
+#### Durchgängiges Anwendungsbeispiel: Automatisierte Bearbeitung einer komplexen IT-Serviceanfrage
+
+Zur Veranschaulichung der theoretischen Konzepte wird in diesem Kapitel ein durchgängiges Anwendungsbeispiel verwendet, das die Kernkompetenzen der satware AG widerspiegelt: die automatisierte Bearbeitung einer komplexen IT-Serviceanfrage. In diesem Szenario meldet ein Kunde ein kritisches Problem, z.B. einen Ausfall einer Cloud-Datenbank, die für das zentrale ERP- oder CRM-System des Kunden essenziell ist.
+
+Der Ausfall einer geschäftskritischen Datenbank – etwa eines Cloud-basierten ERP- oder CRM-Backends – stellt für den Kunden ein erhebliches operatives Problem dar. Solche Systeme bilden den Kern vieler täglicher Abläufe, darunter Auftragsbearbeitung, Kundenverwaltung, Buchhaltung oder Logistikprozesse. Sobald die Datenbank nicht mehr erreichbar ist, kommt es in Unternehmen jeder Größe zu unmittelbaren Einschränkungen der Arbeitsfähigkeit.
+
+Die Komplexität ergibt sich auch daraus, dass die Ursachen eines solchen Ausfalls häufig nicht eindeutig erkennbar sind. Der Fehler kann in sehr unterschiedlichen Bereichen liegen, etwa im Netzwerk des Cloud-Anbieters, in fehlerhaften Konfigurationen, in Sicherheitsmechanismen oder in Abhängigkeiten anderer Dienste.
+
+Ein Multi-Agent-System soll diesen Prozess autonom bearbeiten, von der Klassifizierung über die Lösungsfindung bis zur Dokumentation.
+
+#### Spieltheorie als Grundlage für rationale Entscheidungen
+
+Die Spieltheorie liefert das mathematische Instrumentarium zur Analyse von strategischen Interaktionen zwischen rationalen Agenten [@russell2021]. In unserem Beispiel der IT-Serviceanfrage könnten zwei Agenten – ein Analyse-Agent und ein Ressourcen-Agent – um begrenzte Rechenressourcen konkurrieren. Der Analyse-Agent möchte schnellstmöglich eine Ursache identifizieren (hohe Geschwindigkeit), während der Ressourcen-Agent die Einhaltung der Service Level Agreements (SLAs) und die effiziente Zuweisung von Experten sicherstellen muss (hohe Qualität und Kosteneffizienz).
+
+Eine zu schnelle, aber fehlerhafte Diagnose durch den Analyse-Agenten kann zu unnötigen Eskalationen führen, was die Kosten erhöht. Die Spieltheorie hilft dabei, ein Gleichgewicht (z.B. ein Nash-Gleichgewicht) zu modellieren, bei dem beide Agenten ihre Strategien so anpassen, dass das Gesamtsystem – eine schnelle und korrekte Lösung unter Einhaltung der SLAs – optimal funktioniert [@messie2005].
+
+#### Logische Theorien des Wissens und der rationalen Handlung
+
+Logische Theorien des Wissens und der rationalen Handlung sind essenziell, um das Verhalten von Agenten nachvollziehbar zu machen [@fagin2020]. Jeder Agent verfügt über eine Wissensbasis und handelt auf Basis logischer Schlussfolgerungen. Wenn der Analyse-Agent beispielsweise eine Lösung vorschlägt, muss er dies begründen können. Diese Nachvollziehbarkeit ist für Enterprise-Anwendungen, insbesondere im IT-Support und in regulierten Branchen, von entscheidender Bedeutung.
 
-### Theoretische Grundlagen und Architekturprinzipien
+#### Verteilte Problemlösung
 
-Die theoretischen Grundlagen von Multi-Agent-Systemen sind interdisziplinär 
-und stützen sich auf Konzepte aus der Spieltheorie, der Logik und der 
-verteilten Problemlösung [@russell2021].
+Das Konzept der verteilten Problemlösung beschreibt, wie Agenten eine komplexe Aufgabe in Teilaufgaben zerlegen und durch Koordination gemeinsam lösen [@stone2000]. In unserem Beispiel wird der Gesamtprozess der Bearbeitung der IT-Serviceanfrage auf mehrere spezialisierte Agenten aufgeteilt, die den Alesi-Agenten der satware AG nachempfunden sind:
+
+1. **Aufgabenteilung**: Ein Jane Alesi (Koordination)-Agent nimmt die Anfrage entgegen, ein Leon Alesi (IT-Systemintegration)-Agent analysiert die Logs, ein John Alesi (Softwareentwicklung)-Agent sucht nach Code-Fixes, und ein Justus Alesi (Recht)-Agent prüft die Einhaltung der Datenschutzbestimmungen bei der Log-Analyse.
+
+2. **Informationsaustausch**: Die Agenten kommunizieren über einen zentralen Nachrichtenbus, ein in modernen Enterprise-Architekturen weitverbreitetes Integrationsmuster [@hohpe2004]. Solche Messaging-Systeme ermöglichen eine lose Kopplung der beteiligten Komponenten, stellen standardisierte Kommunikationsprotokolle bereit und gewährleisten eine zuverlässige Zustellung der Nachrichten.
+
+3. **Koordination**: Der Jane Alesi-Agent wartet auf die Diagnose, koordiniert die Suche nach einer Lösung (John Alesi) und stellt sicher, dass alle Schritte dokumentiert werden.
+
+Diese drei Säulen – Spieltheorie, Logik und verteilte Problemlösung – bilden das Fundament, auf dem moderne Multi-Agent-Frameworks aufbauen.
 
 ## Stand der Technik: Frameworks für Multi-Agent-Systeme {#sec-frameworks}
 
-Aufbauend auf den theoretischen Grundlagen hat sich eine dynamische Landschaft 
-von Frameworks entwickelt. Für diese Arbeit wurden drei der prominentesten 
-Frameworks ausgewählt: AutoGen, CrewAI und LangChain.
+Aufbauend auf den theoretischen Grundlagen hat sich eine dynamische Landschaft von Frameworks entwickelt, die die Implementierung von Multi-Agent-Systemen vereinfachen. Marktanalysen prognostizieren ein signifikantes Wachstum für den KI-Agenten-Markt, mit Schätzungen, die von einem Volumen von 7,84 Mrd. USD im Jahr 2025 auf 52,62 Mrd. USD bis 2030 ausgehen [@marketsandmarkets2025].
+
+![Wachstum des KI-Agenten-Markts bis 2030 (Quelle: MarketsandMarkets)](../figures/ki-agenten-markt.png){#fig-markt}
+
+Diese Expansion wird durch die Entwicklung von Open-Source-Frameworks vorangetrieben, die unterschiedliche Architekturen und Philosophien verfolgen. Für diese Arbeit wurden drei der prominentesten Frameworks ausgewählt: AutoGen, CrewAI und LangChain.
+
+Die Auswahl der Frameworks erfolgte durch ein systematisches Screening-Verfahren. Die Auswahl stützt sich auf typische Anwendungsfälle:
 
-### AutoGen: Konversationsbasierte Agenten-Koordination
+- **AutoGen** eignet sich insbesondere für Forschungs- und Prototyping-Szenarien, in denen das Verhalten von Agenten flexibel modelliert und iterativ verfeinert werden muss.
+- **CrewAI** adressiert Produktionsszenarien mit klar strukturierten Rollen und koordinierter Aufgabenverteilung innerhalb von Multi-Agenten-Teams.
+- **LangChain** ist auf generalistische LLM-Anwendungen ausgerichtet, insbesondere für modulare Pipelines, Chains, Tools, Memory-Management und Retrieval-Augmented Generation (RAG).
 
-AutoGen, ein von Microsoft entwickeltes Framework, ermöglicht die Erstellung 
-von Multi-Agenten-Systemen durch konversationsbasierte Interaktionen [@wu2023autogen].
+### AutoGen: Konversationsbasierte Agenten-Koordination {#sec-autogen}
 
-![AutoGen-Architektur](../figures/autogen-architektur.png){#fig-autogen}
+AutoGen, ein von Microsoft entwickeltes Framework, ermöglicht die Erstellung von Multi-Agenten-Systemen, die durch konversationsbasierte Interaktionen zusammenarbeiten [@wu2023autogen]. Der zentrale Entwurfsgedanke ist die dynamische und flexible Aufgabenverteilung, bei der Agenten autonom ihre Rollen und die Abfolge der Aufgaben aushandeln können.
 
-### CrewAI: Rollenbasierte Orchestrierung
+![UML-Komponentendiagramm der AutoGen-Architektur](../figures/autogen-architektur.png){#fig-autogen}
 
-CrewAI verfolgt einen strukturierten Ansatz mit klarer rollenbasierter 
-Orchestrierung.
+Die Architektur von AutoGen basiert auf einem zentralen GroupChat Manager, der die Konversation zwischen verschiedenen Agenten-Typen, wie dem User Proxy Agent und mehreren Assistant Agents, orchestriert. Diese Architektur ermöglicht eine flexible Zusammenarbeit, bei der Agenten auf externe Werkzeuge (Tools), Large Language Models (LLMs) und menschliche Eingaben zugreifen können.
 
-### LangChain: Modulares Framework für LLM-Anwendungen
+### CrewAI: Rollenbasierte Orchestrierung {#sec-crewai}
 
-LangChain ist eine umfassende, modulare Bibliothek zur Entwicklung von 
-Anwendungen, die auf Large Language Models basieren.
+CrewAI verfolgt einen strukturierten Ansatz, der auf einer klaren rollenbasierten Orchestrierung beruht. Im Gegensatz zur dynamischen Konversation in AutoGen werden in CrewAI jedem Agenten eine spezifische Rolle (role), ein Ziel (goal) und eine Hintergrundgeschichte (backstory) zugewiesen [@sparkco2025].
+
+### LangChain: Modulares Framework für LLM-Anwendungen {#sec-langchain}
+
+LangChain ist kein reines Multi-Agent-Framework, sondern eine umfassende, modulare Bibliothek zur Entwicklung von Anwendungen, die auf Large Language Models basieren [@langchain2025]. Seine Stärke liegt in der Abstraktion und Verkettung von LLM-Aufrufen, was als "Chains" bezeichnet wird.
+
+![UML-Komponentendiagramm der LangChain-Architektur](../figures/langchain-architektur.png){#fig-langchain}
+
+Die Architektur von LangChain ist hochgradig modular und besteht aus Kernkomponenten wie Agents (die Entscheidungen treffen), Chains (die Arbeitsabläufe definieren), Memory (um den Zustand von Konversationen zu speichern) und Tools (externe Funktionalitäten).
 
 ## Kommunikationsprotokolle für Multi-Agent-Systeme {#sec-protokolle}
 
-### KQML und FIPA-ACL
+Effektive Kommunikation ist die Grundlage für die Koordination in Multi-Agent-Systemen. Sie wird durch Protokolle geregelt, die Syntax und Semantik der Nachrichten festlegen [@finin1995; @fipa2001].
+
+### Grundlagen: KQML und FIPA-ACL {#sec-kqml-fipa}
+
+Die Knowledge Query and Manipulation Language (KQML), entwickelt in den 1990er Jahren, führte das Konzept eines mehrschichtigen Kommunikationsmodells ein [@finin1995].
+
+![KQML als dreischichtiges Kommunikationsmodell](../figures/kqml-modell.png){#fig-kqml}
 
-Die Knowledge Query and Manipulation Language (KQML) führte das Konzept eines 
-mehrschichtigen Kommunikationsmodells ein.
+Die FIPA Agent Communication Language (FIPA-ACL) baut auf KQML auf und adressiert dessen semantische Unklarheiten durch eine stärkere Formalisierung [@fipa2001].
 
-### Message-Queue-Architekturen
+### Stand der Technik: Message-Queue-Architekturen {#sec-message-queues}
 
-Moderne Multi-Agent-Systeme setzen zunehmend auf Message-Queue-Technologien 
-wie RabbitMQ oder Apache Kafka.
+Aufgrund der Einschränkungen traditioneller Protokolle setzen moderne Multi-Agent-Systeme zunehmend auf Message-Queue-Technologien wie RabbitMQ oder Apache Kafka.
+
+![Architektur einer Message-Queue-basierten Agentenkommunikation](../figures/message-queue-architektur.png){#fig-message-queue}
+
+Diese Architektur bietet entscheidende Vorteile:
+
+- **Skalierbarkeit**: Der Durchsatz kann durch die Verteilung der Queues auf mehrere Server leicht erhöht werden.
+- **Robustheit**: Fällt ein Agent aus, bleiben die Nachrichten in der Queue erhalten und können später verarbeitet werden.
+- **Flexibilität**: Agenten, die in unterschiedlichen Programmiersprachen geschrieben sind, können problemlos über eine gemeinsame Message Queue kommunizieren.
 
 ## Integration von Large Language Models {#sec-llm-integration}
 
-Die Integration von LLMs hat sich als entscheidender Faktor für die 
-Leistungsfähigkeit moderner Multi-Agent-Systeme erwiesen.
+Die Integration von Large Language Models (LLMs) hat sich als entscheidender Faktor für die Leistungsfähigkeit moderner Multi-Agent-Systeme erwiesen [@bommasani2021].
+
+### Grundlegender Workflow und Integrationsstrategien {#sec-llm-workflow}
+
+![UML-Aktivitätsdiagramm eines typischen LLM-Workflows](../figures/llm-workflow.png){#fig-llm-workflow}
+
+Für die technische Integration von LLMs haben sich zwei Hauptstrategien etabliert:
+
+1. **Lokale Modellinferenz**: Das LLM wird direkt auf der eigenen Infrastruktur des Unternehmens betrieben. Plattformen wie Ollama und Hugging Face ermöglichen dies [@certlibrary2025].
+
+2. **Externe API-Integration**: Die Agenten greifen über eine API auf Cloud-basierte LLMs zu. Plattformen wie OpenRouter vereinheitlichen den Zugriff [@openrouter2025].
+
+### Vergleich von Integrationsplattformen {#sec-plattform-vergleich}
+
+| Kriterium | Ollama | Hugging Face | OpenRouter |
+|-----------|--------|--------------|------------|
+| Hosting-Modell | Lokal (On-Premise) | Lokal & Cloud (Hybrid) | Cloud-basiert |
+| Datenhoheit | Vollständig | Hoch (bei lokaler Inferenz) | Gering |
+| Modell-Vielfalt | Gut | Sehr hoch | Sehr hoch |
+| Setup & Wartung | Einfach | Mittel bis hoch | Sehr einfach |
+| DSGVO-Konformität | Sehr hoch | Hoch (bei korrekter Konfiguration) | Herausfordernd |
+
+: Vergleich von Integrationsplattformen {#tbl-plattformen}
+
+## Enterprise-KI-Plattformen {#sec-enterprise-plattformen}
+
+Neben den spezialisierten Frameworks haben sich umfassende Enterprise-KI-Plattformen etabliert, die darauf abzielen, KI-Funktionalitäten einem breiteren Anwenderkreis zugänglich zu machen.
+
+### Architekturen und Zielsetzungen {#sec-enterprise-architektur}
+
+Enterprise-KI-Plattformen basieren typischerweise auf einer mehrschichtigen Architektur, die eine klare Trennung von Daten-, Modell- und Anwendungsebene vorsieht [@sanchez2025].
+
+![Beispielhafte Architektur einer Enterprise-KI-Plattform](../figures/enterprise-ki-architektur.png){#fig-enterprise}
+
+### Vergleich führender Plattformen {#sec-plattform-vergleich-enterprise}
+
+| Kriterium | Microsoft Copilot Studio | Google Vertex AI |
+|-----------|-------------------------|------------------|
+| Architektur & Hosting | Cloud-basiert (Azure) | Cloud-basiert (Google Cloud) |
+| Datenhoheit & DSGVO | Mechanismen vorhanden | Grundsätzlich geringe lokale Kontrolle |
+| Modell-Flexibilität | Eingeschränkt | Sehr hoch |
+| Eignung für lokale MAS | Gering | Mittel |
+
+: Vergleich führender Enterprise-Plattformen {#tbl-enterprise}
+
+## DSGVO-konforme KI: Rechtliche und Technische Aspekte {#sec-dsgvo}
+
+Die Nutzung von KI-Systemen in Unternehmen unterliegt strengen rechtlichen Rahmenbedingungen, allen voran der Datenschutz-Grundverordnung (DSGVO) der Europäischen Union.
+
+### Rechtlicher Rahmen und Grundprinzipien {#sec-dsgvo-rahmen}
+
+Für den Einsatz von KI-Systemen sind insbesondere die folgenden DSGVO-Prinzipien relevant [@edpb2024]:
+
+1. **Datenminimierung**: Es dürfen nur solche Daten verarbeitet werden, die für den Zweck unbedingt erforderlich sind.
+2. **Transparenz**: Betroffene müssen nachvollziehen können, wie und warum Entscheidungen getroffen werden.
+3. **Zweckbindung**: Daten dürfen nur für den ursprünglich definierten Zweck verwendet werden.
+4. **Recht auf Erklärbarkeit**: Nutzer haben Anspruch auf Auskunft über die Logik automatisierter Entscheidungen (Art. 22 DSGVO).
+
+### Technische Schutzmaßnahmen {#sec-pets}
+
+Zur praktischen Umsetzung der DSGVO-Anforderungen haben sich verschiedene technische Verfahren etabliert, die unter dem Begriff Privacy-Enhancing Technologies (PETs) zusammengefasst werden [@voigt2024]:
+
+| Technik | Beschreibung | DSGVO-Bezug |
+|---------|--------------|-------------|
+| Datenanonymisierung | Personenbezogene Daten werden entfernt oder durch Pseudonyme ersetzt | Datenminimierung |
+| Differential Privacy | Mathematisches Rauschen verhindert Rückschlüsse auf Einzelpersonen [@dwork2014] | Datenminimierung |
+| Federated Learning | Dezentrales Training ohne Rohdatenübertragung [@rehman2023] | Datenminimierung, Zweckbindung |
+| Audit Logging | Lückenlose Protokollierung für Nachvollziehbarkeit | Transparenz, Erklärbarkeit |
 
-## DSGVO-konforme KI {#sec-dsgvo}
+: Privacy-Enhancing Technologies zur Umsetzung der DSGVO-Anforderungen {#tbl-pets}
 
-Die Nutzung von KI-Systemen unterliegt strengen rechtlichen Rahmenbedingungen, 
-allen voran der Datenschutz-Grundverordnung (DSGVO).
+Die Kombination dieser Techniken ermöglicht die Entwicklung von KI-Systemen, die sowohl leistungsfähig als auch datenschutzkonform sind.

thesis/chapters/03-problemanalyse.qmd

@@ -1,40 +1,144 @@
 # Problemanalyse {#sec-problemanalyse}
 
-Dieses Kapitel untersucht die Anforderungen an eine lokale, DSGVO-konforme 
-Multi-Agenten-Plattform für den Enterprise-Einsatz.
+Dieses Kapitel untersucht die Anforderungen an eine lokale, DSGVO-konforme Multi-Agenten-Plattform für den Enterprise-Einsatz und setzt diese in Bezug zum aktuellen Stand der Technik bei Multi-Agent-Frameworks (@sec-frameworks). Ziel ist es, die Stärken und Limitationen bestehender Ansätze systematisch zu analysieren. Durch die Anwendung einer Multi-Criteria Decision Analysis (MCDA) werden die relevanten Kriterien quantitativ bewertet, um fundierte Erkenntnisse über die Eignung bestehender Plattformen für den geplanten Einsatz zu gewinnen und eine sachlich begründete Motivation für die Entwicklung der satware AI Autonomous Agent Platform (SAAP) abzuleiten.
 
 ## Einordnung der Problemstellung {#sec-einordnung}
 
-Die Forschungsfrage zielt auf die Entwicklung einer lokalen, autonomen 
-Multi-Agent-Plattform ab, die Effizienz, Skalierbarkeit und DSGVO-Konformität 
-gewährleistet.
+Die Forschungsfrage dieser Arbeit zielt auf die Entwicklung einer lokalen, autonomen Multi-Agent-Plattform ab, die Effizienz, Skalierbarkeit und DSGVO-Konformität gewährleistet. Die Notwendigkeit dieser Entwicklung ergibt sich aus zwei zentralen Bereichen: den inhärenten technologischen Limitationen der bestehenden Open-Source-Frameworks für den Enterprise-Einsatz und den spezifischen, nicht erfüllten Anforderungen der satware AG.
 
-### Technologische Limitationen aktueller Frameworks
+### Technologische Limitationen aktueller Frameworks {#sec-limitationen}
 
-Die analysierten Frameworks weisen signifikante Limitationen auf:
+Die in @sec-frameworks analysierten Frameworks LangChain, AutoGen und CrewAI sind exzellente Werkzeuge für Prototyping und die Entwicklung von Proof-of-Concepts. Für den produktiven, lokalen Einsatz in regulierten Unternehmensumgebungen weisen sie jedoch signifikante technologische Limitationen auf.
 
-| Limitation | Beschreibung | Auswirkungen |
-|------------|--------------|--------------|
-| Fehlendes Ressourcenmanagement | Keine nativen Mechanismen zur Steuerung der Rechenlast | Unkontrollierte Skalierung |
-| Abhängigkeit von Cloud-APIs | Standardkonfigurationen auf Cloud-LLMs ausgerichtet | DSGVO-Probleme |
-| Mangelnde Persistenz | Fehlende robuste Speichermechanismen | Erschwerte Auditierung |
+| Limitation | Beschreibung | Auswirkungen auf Enterprise-Einsatz |
+|------------|--------------|-------------------------------------|
+| Fehlendes Ressourcenmanagement | Die Frameworks bieten keine nativen Mechanismen zur Steuerung der Rechenlast (CPU, GPU, RAM) oder zur Priorisierung von Agenten. | Führt zu unkontrollierter Skalierung, Ressourcenkonflikten und unzuverlässiger Performance in lokalen Umgebungen. |
+| Abhängigkeit von Cloud-APIs | Die Standardkonfigurationen der Frameworks sind stark auf kommerzielle Cloud-LLMs (z.B. OpenAI) ausgerichtet. | Verhindert die DSGVO-konforme Verarbeitung sensibler Daten und führt zu hohen, unvorhersehbaren Betriebskosten. |
+| Mangelnde Persistenz und Governance | Es fehlt an zentralen, robusten Speichermechanismen für den Agenten-Zustand, die Konversationen und die Tool-Nutzung. | Erschwert Auditierung, Nachvollziehbarkeit (Erklärbarkeit) und die Wiederherstellung nach Systemausfällen. |
+| Unzureichende Kommunikations-Abstraktion | Die Kommunikation erfolgt oft ad-hoc über LLM-Prompts (AutoGen) oder einfache sequenzielle Aufrufe (CrewAI), nicht über standardisierte, asynchrone Protokolle. | Schränkt die Skalierbarkeit und die Interoperabilität mit bestehenden Unternehmenssystemen (z.B. SAP, ERP) ein. |
 
 : Technologische Limitationen aktueller Frameworks {#tbl-limitationen}
 
-## Bewertungsmethodik: MCDA {#sec-mcda}
+Die zentrale technologische Limitation liegt in der Architekturfokussierung. Die Frameworks sind primär auf die Orchestrierung der LLM-Logik ausgerichtet, vernachlässigen jedoch die betrieblichen Anforderungen (Operationalization, MLOps) einer Enterprise-Plattform.
 
-Die Multi-Criteria Decision Analysis (MCDA) wird zur objektiven Bewertung 
-der Frameworks eingesetzt.
+### Unternehmensspezifische Anforderungen {#sec-anforderungen-satware}
 
-### Weighted Sum Model (WSM)
+Die satware AG benötigt eine Plattform, die die oben genannten Limitationen adressiert und gleichzeitig die spezifischen Anforderungen des Unternehmens erfüllt, um die bestehende "Alesi-Agenten-Familie" in den Markt zu bringen:
+
+1. **Lokaler Betrieb und DSGVO-Konformität**: Die Plattform muss vollständig On-Premise oder in einer dedizierten, DSGVO-konformen Cloud-Umgebung betrieben werden können.
+
+2. **Integration heterogener Agenten**: Die Plattform muss die bestehenden Alesi-Agenten (z.B. Jane Alesi, Leon Alesi) über definierte Schnittstellen einbinden können.
+
+3. **Ressourceneffizienz und Skalierbarkeit**: Die Plattform muss die begrenzte lokale Hardware optimal nutzen.
+
+4. **Auditierbarkeit und Monitoring**: Für den Enterprise-Einsatz ist ein zentrales Dashboard für Monitoring und Management erforderlich.
+
+## Bewertungsmethodik für Multi-Agent-Plattformen {#sec-mcda}
+
+Die Identifikation der Forschungslücke muss über eine rein qualitative Beschreibung der Limitationen hinausgehen. Um die Notwendigkeit der Entwicklung einer neuen Plattform objektiv und wissenschaftlich fundiert zu begründen, wird eine quantitative Gap-Analyse durchgeführt. Diese Analyse basiert auf der Multi-Criteria Decision Analysis (MCDA), einem etablierten Verfahren zur Bewertung komplexer Alternativen anhand mehrerer, oft konkurrierender Kriterien.
+
+### Multi-Criteria Decision Analysis (MCDA) {#sec-mcda-methode}
+
+Die Multi-Criteria Decision Analysis (MCDA), auch bekannt als Multi-Criteria Decision Making (MCDM), ist ein wissenschaftliches Verfahren, das entwickelt wurde, um Entscheidungsträger bei der Auswahl der besten Option aus einer Reihe von Alternativen zu unterstützen, wenn mehrere, oft widersprüchliche Bewertungskriterien gleichzeitig berücksichtigt werden müssen.
+
+**Auswahl des Weighted Sum Model (WSM)**: Für die vorliegende Gap-Analyse wird das Weighted Sum Model (WSM) verwendet. Das WSM ist eine additive Methode, die sich durch ihre Transparenz und einfache Interpretierbarkeit auszeichnet.
+
+**Mathematische Formulierung des WSM**: Der Gesamtscore $S_j$ für eine Alternative $j$ wird berechnet:
 
 $$S_j = \sum_{i=1}^{n} W_i \cdot S_{ij}$$
 
+Wobei:
+
+- $S_j$: Der Gesamtscore der Alternative $j$
+- $W_i$: Das Gewicht des Kriteriums $i$
+- $S_{ij}$: Der normalisierte Score der Alternative $j$ in Bezug auf das Kriterium $i$
+- $n$: Die Gesamtzahl der Kriterien
+
+### Kriterienportfolio für die Plattformbewertung {#sec-kriterien}
+
+Der Kriterienkatalog wird direkt aus der Forschungsfrage und den spezifischen Herausforderungen der satware AG abgeleitet.
+
+| Kategorie | Kriterium | Beschreibung | Begründung der Wichtigkeit |
+|-----------|-----------|--------------|---------------------------|
+| I. Compliance & Governance | C1: Lokale Inferenzfähigkeit | Fähigkeit, LLMs vollständig On-Premise zu betreiben | DSGVO-Konformität (H1) |
+| | C2: Auditierbarkeit & Logging | Grad der Nachvollziehbarkeit von Agenten-Entscheidungen | Governance (H1) |
+| II. Technische Skalierbarkeit | C3: Asynchrone Kommunikation | Unterstützung von Message-Queue-Architekturen | Skalierbarkeit (H2) |
+| | C4: Ressourcenmanagement | Native Mechanismen zur Steuerung von Rechenressourcen | Effizienz (H4) |
+| III. Betriebliche Effizienz | C5: Integrationsfähigkeit (Tools) | Einfache Anbindung von externen Enterprise-Systemen | Effizienz (H4) |
+| | C6: Entwicklungsaufwand | Komplexität und Lernkurve des Frameworks | Kostenvorteile (H3) |
+| IV. Kostenstruktur | C7: Betriebskosten (LLM-Inferenz) | Kostenstruktur des Frameworks | Kostenvorteile (H3) |
+
+: Kriterienportfolio für die Plattformbewertung {#tbl-kriterien}
+
 ## Vergleich bestehender Frameworks {#sec-vergleich}
 
-Die Gap-Analyse zeigt, dass selbst LangChain mit Score 69 nur 49,3% des 
-Idealwerts erreicht.
+Die Gap-Analyse dient der Anwendung des definierten Kriterienportfolios auf die drei führenden Multi-Agent-Frameworks (LangChain, AutoGen, CrewAI).
+
+### Qualitative Betrachtung {#sec-qualitativ}
+
+Die qualitative Betrachtung dient der Begründung der Scores, die in der quantitativen Analyse verwendet werden. Die Bewertung erfolgt auf einer Skala von 1 (sehr schlecht) bis 5 (sehr gut).
+
+| Kriterium | LangChain | AutoGen | CrewAI | Qualitative Begründung |
+|-----------|-----------|---------|--------|------------------------|
+| C1: Lokale Inferenzfähigkeit | 4 | 3 | 3 | LangChain bietet die größte Flexibilität für lokale LLMs |
+| C2: Auditierbarkeit & Logging | 3 | 2 | 4 | CrewAI bietet durch strikte Struktur höchste Nachvollziehbarkeit |
+| C3: Asynchrone Kommunikation | 1 | 1 | 1 | Keines der Frameworks bietet native Message-Queue-Integration |
+| C4: Ressourcenmanagement | 1 | 1 | 1 | Alle delegieren Ressourcenmanagement an das Betriebssystem |
+| C5: Integrationsfähigkeit | 4 | 3 | 3 | LangChain bietet die größte Bandbreite an Tools |
+| C6: Entwicklungsaufwand | 3 | 3 | 4 | CrewAI bietet den geringsten Entwicklungsaufwand |
+| C7: Betriebskosten | 2 | 2 | 2 | Alle sind standardmäßig auf Cloud-APIs ausgerichtet |
+| **Summe** | **18** | **15** | **18** | |
+
+: Qualitative Betrachtung aktueller Frameworks {#tbl-qualitativ}
+
+### Quantitative Analyse {#sec-quantitativ}
+
+Zur Quantifizierung der Forschungslücke wird das Weighted Sum Model (WSM) angewendet.
+
+**Gewichtung der Kriterien** (Skala 1-5):
+
+| Kriterium | Gewicht (W) | Begründung |
+|-----------|-------------|------------|
+| C1: Lokale Inferenzfähigkeit | 5 | Grundvoraussetzung für Enterprise-Einsatz |
+| C2: Auditierbarkeit & Logging | 4 | Wichtig für Compliance-Vorschriften |
+| C3: Asynchrone Kommunikation | 5 | Entscheidend für Skalierbarkeit |
+| C4: Ressourcenmanagement | 4 | Optimale Nutzung lokaler Hardware |
+| C5: Integrationsfähigkeit | 3 | Einbindung der Alesi-Agenten |
+| C6: Entwicklungsaufwand | 2 | Reduzierung der Implementierungskosten |
+| C7: Betriebskosten | 5 | Direkte Kostensenkung |
+
+: Gewichtung der Kriterien {#tbl-gewichtung}
+
+**Berechnung der Gesamtscores**:
+
+| Framework | Berechnung | Gesamtscore |
+|-----------|------------|-------------|
+| LangChain | (5·4) + (4·3) + (5·1) + (4·1) + (3·4) + (2·3) + (5·2) = 69 | **69** |
+| AutoGen | (5·3) + (4·2) + (5·1) + (4·1) + (3·3) + (2·3) + (5·2) = 57 | **57** |
+| CrewAI | (5·3) + (4·4) + (5·1) + (4·1) + (3·3) + (2·4) + (5·2) = 67 | **67** |
+
+: Berechnung der Gesamtscores {#tbl-scores}
+
+**Visualisierung der Lücke (Gap)**:
+
+Der maximal erreichbare Score (Idealwert) beträgt:
+
+$$S_{max} = \sum_{i=1}^{7} W_i \cdot 5 = (5 + 4 + 5 + 4 + 3 + 2 + 5) \cdot 5 = 28 \cdot 5 = 140$$
+
+Die Ergebnisse zeigen, dass selbst das Framework mit dem höchsten Score (LangChain mit 69) nur **49,3%** des Idealwerts erreicht. Die größte Lücke (Gap) liegt in den hoch gewichteten Kriterien C3 (Asynchrone Kommunikation) und C4 (Ressourcenmanagement), in denen alle Frameworks den niedrigsten Score (1) erzielen.
+
+Diese quantitative Analyse belegt objektiv, dass keines der führenden Multi-Agent-Frameworks die Anforderungen an eine lokale, skalierbare und DSGVO-konforme Enterprise-Plattform erfüllt.
+
+## Schlussfolgerungen für die Plattformentwicklung {#sec-schlussfolgerungen}
+
+Die in diesem Kapitel durchgeführte Analyse hat die Notwendigkeit der Entwicklung einer neuen, maßgeschneiderten Multi-Agent-Plattform wissenschaftlich begründet und quantifiziert.
+
+**Zentrale Schlussfolgerungen**:
+
+1. **Signifikante Forschungslücke**: Die quantitative Analyse belegt, dass die führenden Open-Source-Frameworks (LangChain, AutoGen, CrewAI) die Anforderungen an eine lokale, skalierbare und DSGVO-konforme Enterprise-Plattform nicht erfüllen. Mit einem maximal erreichten Score von 49,3% des Idealwerts ist die Lücke signifikant und rechtfertigt die Forschungsarbeit.
+
+2. **Kritische Defizite**: Die größten Defizite liegen in den hoch gewichteten Kriterien Asynchrone Kommunikation (C3) und Ressourcenmanagement (C4). Diese Limitationen verhindern die Erfüllung der Hypothesen H2 (Skalierbarkeit) und H4 (Effizienz) mit dem aktuellen Stand der Technik.
 
-## Schlussfolgerungen {#sec-schlussfolgerungen}
+3. **Motivation für die SAAP-Plattform**: Die SAAP-Plattform muss als hybride Architektur konzipiert werden, die die Stärken der bestehenden Frameworks (z.B. LangChains Tool-Integration) nutzt, aber die kritischen Defizite durch eigene, dedizierte Komponenten schließt.
 
-Die Analyse belegt die Notwendigkeit einer neuen Plattformarchitektur.
+Die Ergebnisse dieser Analyse bilden die direkte Grundlage für die Anforderungsanalyse und die Konzeption der SAAP-Plattform in @sec-konzeption. Die in der MCDA-Analyse identifizierten Defizite werden in konkrete funktionale und nicht-funktionale Anforderungen übersetzt, die die Architektur der SAAP-Plattform erfüllen muss, um die Forschungsfrage zu beantworten und die Hypothesen zu validieren.

thesis/chapters/04-konzeption-entwicklung.qmd

@@ -1,53 +1,331 @@
 # Methodische Konzeption & Entwicklung {#sec-konzeption}
 
-## Methodischer Rahmen {#sec-methodik}
+Die vorangegangenen Kapitel 2 und 3 legten die theoretischen Grundlagen und analysierten den Stand der Technik im Bereich der Multi-Agenten-Systeme (MAS) und Large Language Models (LLMs). Dabei wurde die Notwendigkeit einer lokalen, DSGVO-konformen Plattform für datensensible Branchen herausgestellt und zugleich technologische Lücken in bestehenden Lösungen identifiziert. Aufbauend auf diesen Erkenntnissen widmet sich Kapitel 4 der methodischen Konzeption und Entwicklung der Satware AI Autonomous Agent Platform (SAAP).
 
-Die Entwicklung folgt einem iterativen, konstruktiven Ansatz nach ISO 9241-210.
+Die Entwicklung eines komplexen Softwaresystems wie der SAAP erfordert ein strukturiertes Vorgehen, das sowohl die technischen Anforderungen als auch die Bedürfnisse der zukünftigen Nutzer berücksichtigt. Dementsprechend orientiert sich die Methodik dieses Kapitels an einem iterativen, konstruktiven Ansatz, der eng mit dem Software-Lebenszyklus und dem User-Centered Design (UCD) verknüpft ist [@boehm1988; @iso9241].
 
-## Anforderungsanalyse {#sec-anforderungen}
+## Methodischer Rahmen und Vorgehensmodell {#sec-methodik}
 
-### Zielgruppenanalyse
+Der Software-Lebenszyklus (Software Life Cycle) beschreibt die Phasen, die ein Softwaresystem von der ersten Idee bis zur Außerbetriebnahme durchläuft [@gabler-softwarelebenszyklus]. Für die vorliegende Arbeit wird ein angepasstes, iteratives Vorgehensmodell gewählt, das die Phasen der Konzeption, Entwicklung und Evaluation in den Vordergrund stellt.
 
-**Primäre Nutzer:** Enterprise-Kunden in regulierten Sektoren  
-**Sekundäre Nutzer:** AI/IT-Teams (DevOps, Admins)
+Parallel dazu wird das Prinzip des User-Centered Design (UCD) angewandt. UCD ist ein iterativer Designprozess, bei dem der Fokus auf den Nutzern und ihren Anforderungen liegt [@idf-ucd]. Die vier Hauptphasen des UCD bilden die Struktur für die Unterkapitel dieses Kapitels:
 
-### Funktionale Anforderungen
+- **4.2 Nutzerbedürfnisse / Anforderungsanalyse**: Entspricht der UCD-Phase "Kontext verstehen" und "Anforderungen spezifizieren"
+- **4.3 Konzeption/Design**: Entspricht der UCD-Phase "Designlösungen entwickeln"
+- **4.4 Prototypische Entwicklung**: Dient der technischen Realisierung der Designlösungen
+- **4.5 Evaluation**: Entspricht der UCD-Phase "Evaluieren"
 
-| ID | Anforderung | Priorität |
-|----|-------------|-----------|
-| F1 | Agent Creation & Registration | Must Have |
-| F2 | Agent Lifecycle Management | Must Have |
-| F3 | Multi-Agent Communication | Must Have |
-| F7 | Chat Interface | Must Have |
+## Nutzerbedürfnisse / Anforderungsanalyse {#sec-anforderungen}
 
-: Funktionale Anforderungen {#tbl-funktional}
+Die Anforderungsanalyse bildet die unverzichtbare Grundlage für den gesamten Entwicklungsprozess. Sie dient der präzisen Definition dessen, was das zu entwickelnde System leisten muss, um die in Kapitel 1 formulierte Forschungsfrage zu beantworten und die in Kapitel 3 identifizierten technologischen Lücken zu schließen.
 
-## Systemarchitektur {#sec-architektur}
+### Zielgruppenanalyse und Kontext der Nutzung {#sec-zielgruppe}
 
-Die SAAP-Plattform folgt einer **Dreischicht-Architektur**:
+Die erfolgreiche Konzeption der SAAP-Plattform erfordert eine klare Definition der Zielgruppe und des Anwendungskontextes. Im Einklang mit der Forschungsfrage und den primären Geschäftszielen – On-Premise Deployment und DSGVO-Konformität für datensensible Branchen – ist die Zielgruppe der Enterprise-Kunde in hochregulierten Sektoren wie dem Gesundheitswesen, dem Finanzwesen oder der Rechtsberatung.
 
-1. **Präsentationsschicht** (Vue.js 3)
-2. **Geschäftslogik** (FastAPI)
-3. **Datenschicht** (PostgreSQL)
+**1. Primäre Nutzergruppen (Fachanwender:innen in regulierten Bereichen)**
 
-### Hybrid-LLM-Routing
+- **Rolle**: Mitarbeiter, die die spezialisierten Alesi-Agenten zur täglichen Entscheidungsunterstützung nutzen
+- **Fokus**: Fachliche Korrektheit, Effizienz der Agenten-Antworten und Einhaltung von Compliance-Vorgaben
+- **Bedürfnisse**: Intuitive Interaktion, zuverlässige Task-Delegation und absolute Datensicherheit
+- **Typische Use Cases**: Leitlinienkonformes Drafting von Befunden (Medizin), NDA/Vertrags-Checks (Recht/Compliance), Budget-Szenarien (Finanzen)
+
+**2. Sekundäre Nutzergruppen (AI/IT-Teams: Plattform-Admins, DevOps)**
+
+- **Rolle**: Verantwortlich für die lokale Installation, Wartung, Überwachung und Skalierung der Plattform
+- **Fokus**: Stabilität, Sicherheit, Wartbarkeit und Nachvollziehbarkeit (Audit-Trail)
+- **Bedürfnisse**: Einfaches Deployment (Docker), System-Monitoring, Agent Lifecycle Management und Audit-Fähigkeit
+
+### User Stories und Use Cases {#sec-userstories}
+
+Um die Bedürfnisse der identifizierten Zielgruppen greifbarer zu machen, werden exemplarische User Stories abgeleitet:
+
+**User Story 1: Rechtliche Compliance-Prüfung**
+
+> Als Fachexperte möchte ich dem Rechts-Agenten relevante Inhalte aus internen Prozessen bereitstellen können, damit er diese auf DSGVO-Konformität prüfen kann, ohne dass die Daten die sichere Umgebung verlassen.
+
+**User Story 2: System-Wartung und Skalierung**
+
+> Als IT-Administrator möchte ich über das Dashboard die Auslastung der Agenten-Instanzen überwachen und bei Bedarf neue Agenten-Instanzen hinzufügen, damit die Performance auch bei Spitzenlast gewährleistet ist.
+
+**User Story 3: Mehrstufiger Workflow**
+
+> Als Projektmanager möchte ich einen mehrstufigen Workflow starten, der verschiedene spezialisierte Agenten involviert, um eine komplexe Aufgabe automatisiert zu bearbeiten.
+
+![UML Use Case Diagram der SAAP-Plattform](../figures/use-case-diagram.png){#fig-usecase}
+
+Die detaillierten Beschreibungen der Use Cases sind im @sec-anhang zu finden.
+
+### Personas {#sec-personas}
+
+#### Persona 1: Dr. Elias Richter (45) – Der Compliance-Experte
+
+- **Rolle**: Senior Compliance Manager (Primärnutzer)
+- **Unternehmen**: Mittelständisches Finanzinstitut (Enterprise-Kunde)
+- **Ziele**: Einhaltung aller regulatorischen Vorgaben (MaRisk, BAIT), schnelle Antworten auf komplexe Rechtsfragen
+- **Herausforderungen**: Hoher Zeitdruck, Angst vor Datenlecks, mangelnde Transparenz bei KI-Antworten
+- **Zitat**: "Ich brauche eine Lösung, die mir schnelle Antworten liefert, aber ich muss zu 100% sicher sein, dass unsere sensiblen Kundendaten das Haus nicht verlassen."
+
+#### Persona 2: Sarah Müller (32) – Die DevOps-Ingenieurin
+
+- **Rolle**: DevOps Engineer (Sekundärnutzer/AI/IT-Team)
+- **Ziele**: Stabile, sichere und skalierbare IT-Infrastruktur
+- **Herausforderungen**: Komplexität bei KI-System-Wartung, fehlende Transparenz über Agenten-Aktivitäten
+- **Zitat**: "Die Plattform muss sich nahtlos in unsere bestehende Infrastruktur integrieren lassen."
+
+### Spezifikation der Anforderungen {#sec-spezifikation}
+
+#### Funktionale Anforderungen (F) {#sec-funktional}
+
+| ID | Bezug | Anforderung | Priorität |
+|----|-------|-------------|-----------|
+| F1 | Neuen Agenten registrieren | Agent Creation & Registration | Must Have |
+| F2 | User Story 2, 5 | Agent Lifecycle Management | Must Have |
+| F3 | User Story 3 | Multi-Agent Communication | Must Have |
+| F4 | User Story 2 | Real-time Dashboard Interface | Should Have |
+| F5 | User Story 1 | LLM Provider Integration | Must Have |
+| F6 | Aufgaben delegieren | Task Delegation System | Should Have |
+| F7 | User Story 1 | Chat Interface | Must Have |
+| F8 | Neuen Agenten registrieren | Agent Template System | Should Have |
+
+: Funktionale Anforderungen des Systems {#tbl-funktional}
+
+#### Nicht-Funktionale Anforderungen (N) {#sec-nichtfunktional}
+
+| ID | Bezug | Anforderung | Priorität | Erläuterung |
+|----|-------|-------------|-----------|-------------|
+| NF1 | User Story 2 | Performance & Skalierbarkeit | Must Have | 10+ parallele Agenten, Response-Zeit <30s für komplexe Aufgaben, <5s für einfache Anfragen |
+| NF2 | Daten persistent speichern | Database Persistence | Must Have | Alle Daten, Konfigurationen und Chat-Verläufe persistent gespeichert |
+| NF3 | User Story 4 | DSGVO-konforme Datenhaltung | Must Have | Lokale Datenspeicherung ohne externe Cloud-Services |
+| NF4 | User Story 2 | System Health Monitoring | Should Have | Überwachung von CPU, RAM, GPU-Auslastung |
+
+: Nicht-funktionale Anforderungen des Systems {#tbl-nichtfunktional}
+
+## Systemarchitektur / Konzeption {#sec-architektur}
+
+Die in @sec-anforderungen durchgeführte Anforderungsanalyse hat die funktionalen (F1-F8) und nicht-funktionalen (NF1-NF4) Anforderungen definiert. Aufbauend auf dieser Grundlage wird die konzeptionelle Ausgestaltung und die Systemarchitektur der Plattform beschrieben.
+
+### Architektonische Leitprinzipien {#sec-leitprinzipien}
+
+| Prinzip | Theoretische Grundlage | Anwendung auf SAAP | Bezug |
+|---------|------------------------|-------------------|-------|
+| Dreischicht-Architektur | Separation of Concerns [@marvie2002] | Trennung Präsentation, Geschäftslogik, Datenhaltung | NF1, F2 |
+| Lose Kopplung | Dependency Inversion Principle | Austausch von Komponenten ohne Systemänderungen | F5, F3 |
+| Containerisierung | Immutable Infrastructure [@newman2021] | Konsistente Deployment-Umgebungen | NF3, F2 |
+| Event-driven Architecture | Reactive Manifesto [@boner2014] | Asynchrone Verarbeitung, Echtzeit-Updates | F4, F3 |
+| Privacy by Design | Cavoukian (2011), Art. 25 DSGVO [@cavoukian2009] | Automatisierte Datenklassifizierung | NF3, F5 |
+
+: Architektonische Leitprinzipien {#tbl-leitprinzipien}
+
+### Dreischicht-Architektur der SAAP-Plattform {#sec-dreischicht}
+
+Die SAAP-Plattform folgt dem bewährten Muster einer Dreischicht-Architektur, das sich als Standard für skalierbare, wartbare Systeme etabliert hat [@richards2020]:
+
+1. **Präsentationsschicht**: Verantwortlich für Benutzerinteraktion (F4, F7)
+2. **Geschäftslogik-Schicht**: Orchestriert Agenten, verwaltet Lebenszyklen (F1-F8)
+3. **Datenschicht**: Persistente Speicherung (NF2, NF3, NF4)
+
+![Dreischicht-Architektur der SAAP-Plattform](../figures/dreischicht-architektur.png){#fig-architektur}
+
+### Hierarchische Multi-Agent-Koordination {#sec-hierarchisch}
+
+Die SAAP-Plattform nutzt eine **hierarchische Koordinations-Architektur** mit einem zentralen Koordinator-Agenten und spezialisierten Worker-Agenten. Diese Entscheidung basiert auf den spezifischen Anforderungen:
+
+1. **Maximierte Governance und Auditierbarkeit**: Zentrale Steuerungsinstanz für lückenlose Protokollierung
+2. **Garantierter Determinismus**: Sequenzielle oder klar definiert parallele Ausführungsmuster
+3. **Nahtlose Integration**: Abbildung der bestehenden "Alesi"-Agenten-Familie
+
+![Hierarchische Multi-Agent-Netzwerkarchitektur](../figures/hierarchisch-architektur.png){#fig-hierarchisch}
+
+### Adressierung der Lücken C3 & C4 {#sec-luecken}
+
+#### Lücke C3: Asynchrone Kommunikation
+
+Die SAAP-Plattform adressiert die Lücke durch eine **Event-driven Architecture** gemäß dem Reactive Manifesto [@boner2014]:
+
+- **Responsive**: Token-by-Token-Streaming für LLM-Responses
+- **Resilient**: Automatische Reconnection bei Verbindungsabbrüchen
+- **Elastic**: Hohe Parallelität durch Connection-Pooling
+- **Message-Driven**: Event-basierte Entkopplung von Sender und Empfänger
+
+![Synchrones vs. Asynchrones Modell](../figures/sync-async-vergleich.png){#fig-syncasync}
+
+#### Lücke C4: Ressourcenmanagement (Hybrid-LLM-Routing) {#sec-hybrid-routing}
 
 ```{mermaid}
 %%| label: fig-routing
 %%| fig-cap: "Privacy-aware Hybrid-LLM-Routing"
 flowchart TD
     A[Benutzeranfrage] --> B{Privacy Detector}
-    B -->|SENSIBEL| C[Colossus Lokal]
-    B -->|ÖFFENTLICH| D[OpenRouter Cloud]
-    C --> E[Koordinator Jane Alesi]
-    D --> E
+    B -->|PII erkannt| C[SENSIBEL: Colossus Lokal]
+    B -->|Keine PII| D{Routing Modus}
+    D -->|local| C
+    D -->|cloud| E[ÖFFENTLICH: OpenRouter]
+    D -->|auto| F{Keyword-Check}
+    F -->|sensibel| C
+    F -->|öffentlich| E
+    C --> G[Koordinator Jane Alesi]
+    E --> G
+    G --> H[Finale Antwort]
 ```
 
+Der Hybrid-LLM-Router implementiert automatisierte Datenklassifizierung mit vier Privacy Levels:
+
+| Privacy Level | Definition | Routing-Vorgabe |
+|---------------|------------|-----------------|
+| PUBLIC | Allgemeine Anfragen, keine sensiblen Daten | OpenRouter (Performance) |
+| INTERNAL | Unternehmensinterne, nicht-kritische Daten | Colossus bevorzugt |
+| CONFIDENTIAL | Geschäftsgeheimnisse, nicht-PII-Daten | Colossus erforderlich |
+| PRIVATE | Personenbezogene Daten (PII), medizinische/finanzielle Details | Colossus zwingend |
+
+: Privacy-Detection-Logik {#tbl-privacy}
+
+### Technologieauswahl {#sec-technologie}
+
+#### Frontend-Technologie
+
+| Kriterium | Vue.js 3 | React 18 | Angular 17 |
+|-----------|----------|----------|------------|
+| Bundle Size | ~33 KB (5 Pkt) | ~42 KB (4 Pkt) | ~143 KB (2 Pkt) |
+| Lernkurve | Moderat (4 Pkt) | Moderat (3 Pkt) | Steil (2 Pkt) |
+| TypeScript-Integration | Exzellent (5 Pkt) | Gut (3 Pkt) | Exzellent (5 Pkt) |
+| **Ergebnis** | **4,80 (Gewählt)** | 3,65 | 2,80 |
+
+: Evaluierung von Frontend-Technologien {#tbl-frontend}
+
+#### Backend-Technologie
+
+| Kriterium | FastAPI | Django REST | Flask |
+|-----------|---------|-------------|-------|
+| Async/Await Support | Native (5 Pkt) | Limitiert (2 Pkt) | Plugin (3 Pkt) |
+| OpenAPI-Generierung | Automatisch (5 Pkt) | Manuell (2 Pkt) | Manuell (2 Pkt) |
+| Performance (req/s) | ~15.000 (5 Pkt) | ~3.000 (2 Pkt) | ~4.500 (3 Pkt) |
+| **Ergebnis** | **4,85 (Gewählt)** | 2,30 | 3,15 |
+
+: Evaluierung von Backend-Technologien {#tbl-backend}
+
+#### Datenbank-Technologie
+
+**PostgreSQL** wurde ausgewählt aufgrund:
+
+- ACID-Konformität für Transaktionssicherheit
+- JSONB-Support für flexible Datenstrukturen
+- Native Audit-Trail-Fähigkeiten für DSGVO-Konformität (NF3)
+
+### Sicherheitsarchitektur und DSGVO-Konformität {#sec-sicherheit}
+
+Die Sicherheit und DSGVO-Konformität sind von Anfang an in die Architektur integriert (Security by Design, Privacy by Design) [@schneier2015].
+
+| Sicherheitsbereich | Architektonische Maßnahme | Standard | DSGVO-Artikel |
+|-------------------|---------------------------|----------|---------------|
+| Zugriffskontrolle | Kontext- und komponentenbasierte Zugriffsbeschränkung | OWASP ASVS V4 [@owasp2023] | Art. 32 |
+| Verschlüsselung | TLS 1.3 für alle Verbindungen | BSI TR-02102-2 [@bsi2025] | Art. 32 |
+| Speicher-Verschlüsselung | AES-256 für sensible Daten | BSI TR-02102-1 | Art. 32 |
+| Audit-Logging | Unveränderliche Protokollierung | BSI SYS.1.1.A22 [@bsi2023] | Art. 5, 25 |
+
+: Sicherheitsmaßnahmen nach Industriestandards {#tbl-sicherheit}
+
 ## Prototypische Implementierung {#sec-prototyp}
 
-### Technologie-Stack
+Die prototypische Umsetzung dient als Validierungsschritt der architektonischen Entwurfsentscheidungen. Methodisch folgt die Umsetzung dem Prinzip des Prototyping [@sciencedirect-prototype].
+
+### Technologie-Stack {#sec-stack}
+
+| Komponente | Technologie | Funktion |
+|------------|-------------|----------|
+| Backend | Python 3.11 / FastAPI | API-Gateway, Agenten-Orchestrierung |
+| Frontend | Vue.js 3 / TailwindCSS | Reaktive Benutzeroberfläche |
+| Kommunikation | WebSockets | Bidirektionale Echtzeit-Kommunikation |
+| Persistenz | PostgreSQL / SQLAlchemy | Speicherung von Agenten-Metadaten und Audit-Trails |
+| Infrastruktur | Docker / Docker Compose | Containerisierung und lokale Bereitstellung |
+
+: Technologie-Stack für Prototyping {#tbl-stack}
+
+### Repository-Struktur {#sec-repo}
+
+```
+saap/
+├── backend/                    # Python FastAPI Backend
+│   ├── main.py                 # API-Gateway & WebSocket-Server
+│   ├── services/               # Business-Logik
+│   ├── database/               # Persistenzschicht
+│   └── agents/                 # LLM-Provider-Adapter
+├── frontend/                   # Vue.js 3 Frontend
+│   └── src/
+│       ├── views/              # Dashboard-Views
+│       ├── components/         # UI-Komponenten
+│       ├── services/           # API-Service
+│       └── composables/        # WebSocket-Logik
+└── docker-compose.yml          # Container-Orchestrierung
+```
+
+### Frontend-Implementierung {#sec-frontend-impl}
+
+Die Frontend-Implementierung dient als zentrale Schnittstelle zur Visualisierung des Multi-Agenten-Systems. Das Designkonzept basiert auf einem strukturierten System Design:
+
+| Element | Spezifikation | Begründung |
+|---------|---------------|------------|
+| Primärfarbe | Blau (#2563EB) | Vermittelt Vertrauen und Professionalität [@heller2003] |
+| Sekundärfarbe | Grün (#16A34A) | Symbolisiert Erfolg und Sicherheit |
+| Akzentfarbe | Orange (#F97316) | Aufmerksamkeitsfarbe für Warnungen |
+| Typografie (Primär) | Inter | Für Bildschirme optimierte Sans-Serif |
+| Typografie (Code) | Fira Code | Monospace-Schriftart für technische Daten |
+
+: System Design Spezifikation {#tbl-design}
+
+![SAAP-Director Dashboard mit aktiven Agenten](../figures/saap-dashboard.png){#fig-dashboard}
+
+### Backend-Implementierung {#sec-backend-impl}
+
+Das Backend ist in vier logische Schichten unterteilt:
+
+1. **Router-Schicht** (api/ und main.py): Definiert Endpunkte und validiert Daten
+2. **Service-Schicht** (services/): Enthält Business-Logik inkl. `multi_agent_coordinator.py`
+3. **Agenten-Schicht** (agents/): Kapselt LLM-Provider-spezifische Logik
+4. **Persistenz-Schicht** (database/): Datenbankkommunikation über SQLAlchemy
+
+![Asynchroner Ablauf einer Benutzerinteraktion im Backend](../figures/sequenzdiagramm-backend.png){#fig-sequenz}
+
+### Multi-Agent-Implementierung {#sec-multiagent-impl}
+
+Die Multi-Agent-Implementierung basiert auf der zentralen Rolle von **Jane Alesi** als Koordinatorin:
+
+1. **Intent-Analyse**: Identifiziert den thematischen Schwerpunkt der Benutzeranfrage
+2. **Task-Delegation**: Leitet Anfrage an ausgewählten Spezialisten weiter
+3. **Response-Koordination**: Führt abschließende Qualitätskontrolle und Formatierung durch
+
+| Agent | Spezialisierung | Kernkompetenz | Farbcode |
+|-------|-----------------|---------------|----------|
+| John Alesi | Software-Entwicklung | Code-Analyse, Debugging | #14B8A6 |
+| Lara Alesi | Medizin & Gesundheit | Symptomanalyse, Diagnostik | #EC4899 |
+| Justus Alesi | Recht & Compliance | DSGVO, Vertragsrecht | #F59E0B |
+| Theo Alesi | Finanzen & Investment | Budgetplanung, Marktanalyse | #8B5CF6 |
+| Leon Alesi | System-Integration | Infrastruktur, Docker, APIs | #059669 |
+| Luna Alesi | Coaching & Strategie | Business-Strategie, Soft Skills | #F43F5E |
+
+: Rollen der Spezialisten-Agenten {#tbl-agenten}
+
+![Hierarchische Multi-Agent-Kommunikation](../figures/multi-agent-kommunikation.png){#fig-multiagent}
+
+### Persistenz und Logging {#sec-persistenz}
+
+Die Persistenzschicht ist für die Speicherung der Agenten-Metadaten und die Erstellung eines lückenlosen Audit-Trails verantwortlich.
+
+![ORM-Klassendiagramm der Persistenzmodelle](../figures/orm-klassendiagramm.png){#fig-orm}
+
+**Wichtige Logging-Prinzipien:**
+
+1. **Lückenlose Protokollierung**: Jede Anfrage und die finale Antwort werden gespeichert
+2. **Metrik-Erfassung**: Erfassung von `response_time` und `tokens_used` für Performance-Analyse
+3. **PII-Ausschluss**: Sensible Daten werden nur lokal verarbeitet
+
+## Zwischenfazit {#sec-zwischenfazit}
+
+Die prototypische Implementierung der SAAP-Plattform hat die konzeptionelle Architektur erfolgreich in funktionsfähigen Code überführt. Die zentralen architektonischen Entscheidungen wurden validiert:
+
+1. **Multi-Agent-Koordination**: Die Implementierung des Koordinator-Agenten Jane Alesi mit spezialisierten Worker-Agenten funktioniert wie geplant
+2. **Hybrid-LLM-Routing**: Der Privacy Detector steuert den Datenfluss dynamisch zwischen lokalem und externem LLM
+3. **Schichtenarchitektur**: Klare Trennung von Frontend, Backend und Persistenz gewährleistet Wartbarkeit
+4. **Echtzeit-Kommunikation**: WebSocket-Integration ermöglicht reaktives Benutzererlebnis
 
-- **Backend:** Python 3.11 / FastAPI
-- **Frontend:** Vue.js 3 / TailwindCSS
-- **Persistenz:** PostgreSQL / SQLAlchemy
-- **Infrastruktur:** Docker / Docker Compose
+Der funktionsfähige Prototyp bildet die Grundlage für die systematische Evaluation in Kapitel 5, wo die architektonischen Hypothesen anhand von Metriken wie Antwortzeit, Token-Verbrauch und Korrektheit des Privacy-Routings bewertet werden.