Von Idee zu Präsentation: Was wir bei der Entwicklung eines KI-Tools über Multi-Agent-Systeme gelernt haben#

Wir haben ein Werkzeug entwickelt, das aus hochgeladenen Dokumenten automatisch strukturierte Präsentationen entwickelt. Das Besondere: 2 Stunden Planung führten zu nur 30-60 Minuten Programmierzeit – und dabei haben wir viel über den Einsatz von Sprachmodellen in der Praxis gelernt.

Was war das Ziel?#

Weniger manueller Aufwand bei der Vorbereitung von Vorträgen.

Die meisten Präsentations-Tools erstellen fertige Folien mit vorgefertigten Inhalten. Wir wollten anders vorgehen: Ein System, das vorhandene Informationen nimmt und nach eigenen Vorgaben strukturiert (z. B. Zielgruppe, Vortragszeit, inhaltlicher Fokus).

Was kann das Tool?#

• Dokumente verarbeiten: Man lädt Dateien hoch (PDF, Word, Text, Markdown oder PowerPoint) und das System entwickelt daraus einen ersten Entwurf
• Im Gespräch verfeinern: Man gibt Details an wie “Die Präsentation ist für Laien, 20 Minuten” oder “Fokus auf Ergebnisse, nicht Methodik”
• Automatisch aktualisieren: Nach jedem Gesprächsschritt prüft das System, ob die Struktur angepasst werden muss
• Flexibel exportieren: Das Ergebnis kann als Markdown, PowerPoint oder Word-Datei gespeichert werden

So entsteht eine Präsentationsstruktur, die genau zu den eigenen Anforderungen passt.

Wie wurde es entwickelt?#

Wir sind in drei klaren Schritten vorgegangen:

• Schritt 1 (4-5 Iterationen): Funktionale Planung – Was soll das Tool können? Wie sollen die Komponenten zusammenarbeiten?
• Schritt 2 (2-3 Iterationen): Technische Planung – Welche Datenstrukturen brauchen wir? Wie behandeln wir Fehler?
• Schritt 3 (30-60 Minuten): Programmierung entlang der detaillierten Vorgaben

Gesamtaufwand für Planung: Circa 2 Stunden
Ergebnis: Circa 3.000 Zeilen Code in mehreren Modulen

Warum lief es so gut?#

Weil wir die Vorbereitung ernst genommen haben.

Eine klare Beschreibung der Anforderungen hat später viele Fehler verhindert. In der funktionalen Phase haben wir diskutiert, welche technischen Ansätze überhaupt umsetzbar sind – und uns bewusst für schlanke Lösungen entschieden. Die technische Planung hat dann exakte Schnittstellen definiert. Das Ergebnis: Der Code konnte in einem Durchgang geschrieben werden, ohne größere Änderungen.

Die Zwei-Agenten-Architektur war dabei zentral: Ein Agent führt das Gespräch mit den Nutzenden. Ein zweiter Agent pflegt die Präsentationsstruktur. Diese Trennung hat die Entwicklung vereinfacht.

Wichtige Erkenntnisse#

1. Sprachmodelle brauchen strukturierte Anweisungen

Am Anfang versuchten wir, klare Beschreibungen im Systemprompt auszuformulieren. In der Praxis haben wir gesehen: Das reicht nicht. Die Agenten haben zu ungenau gearbeitet.

Wir haben dann ein strukturiertes Protokoll eingeführt – ein JSON-Format, über das die Agenten miteinander kommunizieren. Der Struktur-Agent kann dem Gesprächs-Agent konkrete Fragen stellen. Das hat die Qualität deutlich verbessert. Freitext-Kommunikation zwischen Agenten war zu fehleranfällig.

2. Gründliche Planung spart Zeit

Die 2 Stunden für funktionale und technische Planung haben sich gelohnt. Wir mussten während der Programmierung kaum etwas überarbeiten.

Besonders wichtig waren die Diskussionen über technische Machbarkeit. Statt komplexe Lösungen zu bauen, haben wir uns auf das Wesentliche konzentriert. Die technische Planung hat dann die exakten Datenstrukturen festgelegt. Diese Klarheit hat die schnelle Umsetzung ermöglicht.

3. Kleine Code-Dateien sind besser wartbar

Dateien mit weniger als 1.000 Zeilen lassen sich mit Sprachmodellen deutlich leichter bearbeiten. Das erfordert konsequente Aufteilung in Module, zahlt sich aber aus.

Unsere größte Komponente – der Struktur-Agent mit etwa 900 Zeilen – war noch gut handhabbar. Die Modulstruktur haben wir iterativ entwickelt, immer mit Blick auf diese Wartbarkeit.

4. Die Wahl des Modells ist wichtig

Wir haben Mistral Small 2506 für die produktiven Agenten eingesetzt. Bei kleineren Modellen sollte man primär prüfen: Befolgen sie Anweisungen zuverlässig? Nicht nur: Wie schneiden sie in allgemeinen Tests ab?

Mistral Small war ausreichend, größere Modelle hätten vermutlich präziser gearbeitet. Die schnellen Antwortzeiten (wenige Sekunden) haben aber für ein gutes Nutzererlebnis gesorgt.

Was können andere davon lernen?#

• Zeit in Planung investieren: Die 2 Stunden für funktionale und technische Vorbereitung ermöglichen sehr schnelle Umsetzung
• Strukturierte Protokolle nutzen: JSON-basierte Schnittstellen zwischen Agenten sind robuster als Freitext
• Kommunikation in beide Richtungen: Ein Rückkanal hilft, wenn Agenten koordiniert arbeiten müssen
• An Wartbarkeit denken: Der Richtwert von unter 1.000 Zeilen pro Datei hat sich bewährt
• Modelle nach Anweisungs-Treue wählen: Nicht nur allgemeine Leistung zählt, sondern wie genau das Modell Vorgaben umsetzt

Praxis-Validierung#

Verschiedene Personen haben das Tool mit echten Dokumenten getestet (Umfang: wenige bis 60 Seiten). Besonders gut funktioniert hat die zeitliche Planung und die Anpassung an unterschiedliche Zielgruppen.

Das Tool liefert strukturierte Vorschläge, die als Ausgangsbasis dienen. Die Strukturierung von Präsentationen basierend auf hochgeladenen Dokumenten hat robust funktioniert.

Fazit#

✔ Strukturierte Vorbereitung mit funktionaler und technischer Planung beschleunigt die Umsetzung deutlich
✔ Klare Protokolle für die Kommunikation zwischen Agenten verbessern die Qualität erheblich
✔ Wartbare Code-Struktur und die richtige Modellwahl nach Anweisungs-Treue sind entscheidend

Dies ist Teil einer Reihe über den praktischen Einsatz von Sprachmodellen. Der Fokus liegt darauf, was man aus solchen Projekten lernen kann – nicht nur auf den Ergebnissen.