So fängt es meistens an. Aus irgendeiner Ecke des Unternehmens kommt diese Forderung. Aber wie geht man an die Sache ran? Kollegen von tng waren so nett und führten einen eintägigen Workshop mit dem Titel „Designing Agentic Systems“ für mein Team durch.
Dieser Workshop basierte hauptsächlich auf dem Buch von Antonio Gulli: Agentic Design Patterns. A Hands-On Guide to Building Intelligent Systems.
Oder gutes Beispiel das KI manchmal allein nicht ausreicht, um Qualität des Outputs zu sichern. 😉
Im ersten Teil des Workshops sprachen wir kurz über LLMs und was eigentlich Agents sind und beschäftigten uns dann ausführlicher mit den Patterns von denen es eine ganze Reihe gibt. Das wohl prägnanteste Learning war, dass jedes dieser Patterns eine Entscheidung für etwas und gleichzeitig gegen etwas anderes ist. Diese Trade Offs führen dazu, dass es gar nicht die eine korrekte Architekturentscheidung geben kann. Alle Patterns sind abhängig davon um welche Use Cases es sich handelt, welches Risiko eingegangen werden kann und in welcher Umgebung das Ganze stattfindet.
Insgesamt gib es vier Cluster zu denen man diese Patterns zuordnen kann:
- Foundations
- Coordination
- Reasoning
- Quality, Safety & Oversight
Nachdem wir die Pattens durchgearbeitet hatten und ein gemeinsames Verständnis für diese gebildet hatten, ging es in die Gruppenarbeit. In kleinen Teams zu 2 bis 3 Menschen bekamen wir die Aufgabe eine agentische Architektur für einen in der realen Welt vorkommenden Use Case zu designen. Das war in unserem Fall ein Beispiel mit dem wir uns alle leicht verbinden konnten. Ein Reiseplannungs-Agent. Das Ziel war dabei natürlich nicht die eine „korrekte“ Architektur zu finden, sondern eine gut begründete Variante zu erstellen. Wir arbeiteten rein mit Visualisierungen in Excalidraw, aber es hätte auch jede andere Whiteboadlösung sein können.
In der Timebox von 2,5 Stunden, die anfänglich großzügig bemessen erschien, wurde schnell klar, dass gerade über die Fülle der Kombinationsmöglichkeiten – z.B. nicht alles kann und sollte zum Beispiel einem LLM überlassen werden – ergaben sich viele spannende Diskussionen. Sehr hilfreich war dabei, dass die Kollegen von tng immer wieder in unsere Breakout Sessions sprangen, um uns wichtige Impulse zu geben.
Am Schluss stellten wir uns gegenseitig unsere Ergebnisse vor. Wir hatten ins unseren Gruppen alles unterschiedliche Lösungen gewählt. In einem Teamworkshop mit dem Ziel eine Architektur zu finden, hätte jetzt noch die Phase der Festlegung auf das erste Experiment kommen müssen.
So blieben für uns folgende Erkenntnisse:
- Der Tag war sehr gut investierte Zeit
- In the real world, müsste jetzt noch ein Tag für die Erstellung und Implementierung eines POC folgen. Dazu dann die iterative Verbesserung durch Testabeckung und z.B. Guardrails, etc.
- Es gibt nicht die eine „richtige“ Architektur
- Patterns sind Trade Offs
- Es ist sehr gut Unterstützung von Menschen mit mehr Expertise und Erfahrung in dieser Diskussion zu haben (ha, ha, nicht ganz neu!)
Insgesamt werden wir unsere Architekturentscheidungen mit Hilfe dieser Learnings noch einmal reviewen und gegebenenfalls anpassen.
