Agent- & Prompt-Design-Workshop
Ein praxisnaher Workshop, in dem Teams Prompts und Agent-Konfigurationen an echten Aufgaben bauen, testen und korrigieren – statt KI als Black Box zu behandeln.
Ein praxisnaher Workshop, in dem Teams Prompts und Agent-Konfigurationen an echten Aufgaben bauen, testen und korrigieren – statt KI als Black Box zu behandeln.
Ein Team sitzt vor einem geteilten Bildschirm. Auf der linken Seite läuft ein Agent, der gerade eine Kundenanfrage kategorisieren soll. Auf der rechten Seite sitzen fünf Personen, die dem Output zusehen und merken: Er kategorisiert falsch, aber niemand im Raum kann in diesem Moment sagen, warum. War es die Formulierung der Anweisung? Fehlte Kontext? Hat das Modell eine Regel übergeneralisiert? Genau an diesem Punkt setzt der Agent- & Prompt-Design-Workshop an. Nicht bei der Frage "Was kann KI für uns tun?", sondern bei der viel konkreteren Frage: "Warum tut dieser Agent gerade das, und wie bringen wir ihm bei, es richtig zu tun?"
Innerhalb unserer Workshop-Reihe hat jedes Format eine klar abgegrenzte Aufgabe. Der Executive Alignment Workshop sorgt dafür, dass die Führungsebene eine gemeinsame Sprache und ein gemeinsames Zielbild für den KI-Einsatz hat. Der Use Case Discovery Workshop identifiziert und priorisiert, wo im Unternehmen KI-Einsatz überhaupt sinnvoll ist. Der Team Enablement Workshop baut allgemeine Kompetenz und Akzeptanz in der Breite der Belegschaft auf. Der Agent- & Prompt-Design-Workshop ist der Ort, an dem diese Vorarbeit auf die Werkbank kommt: Hier bauen die Menschen, die einen konkreten Use Case später operativ verantworten, tatsächlich funktionierende Prompts und einfache Agent-Konfigurationen für ihre eigenen, echten Aufgaben und lernen dabei die Handwerkstechnik, die aus einer guten Idee ein verlässliches Werkzeug macht.
Diese Abgrenzung ist wichtig, weil "KI-Training" als Begriff in der Praxis fast alles bedeuten kann, von einer einstündigen ChatGPT-Einführung bis zu einer mehrwöchigen Entwicklerschulung. Unser Format ist bewusst enger gefasst: Es ist ein Werkstatt-Format, kein Vortragsformat. Es endet nicht mit einer Liste von Best Practices, sondern mit getesteten, dokumentierten Prompt- und Agent-Konfigurationen, die die Teilnehmenden am nächsten Arbeitstag tatsächlich verwenden können. Der Unterschied zwischen "wir haben über Prompting gesprochen" und "wir haben unseren Freigabeprozess für Rechnungsprüfung als Agent-Workflow gebaut und dreimal live scheitern und korrigieren sehen" ist der ganze Sinn dieses Formats.
Die Zusammensetzung der Gruppe entscheidet mehr über den Erfolg des Workshops als jedes andere einzelne Element. Wir arbeiten grundsätzlich mit intakten Arbeitsgruppen, nicht mit einer bunt zusammengewürfelten Abteilungsdelegation. Das bedeutet: Menschen, die den Zielprozess tatsächlich ausführen, kennen seine Ausnahmen, seine informellen Regeln und seine Reibungspunkte. Ein Sachbearbeiter aus dem Vertragsmanagement weiß, welche Klauseln in der Praxis Kopfzerbrechen bereiten, lange bevor ein Prompt geschrieben wird, der genau diese Klauseln erkennen soll.
Sinnvolle Teilnehmerzahl liegt bei sechs bis vierzehn Personen, aufgeteilt in zwei bis vier Kleingruppen von je drei bis vier Personen, die jeweils an einem eigenen, klar abgegrenzten Anwendungsfall arbeiten. Größere Gruppen verwässern die Arbeitszeit pro Fall, kleinere Gruppen laufen Gefahr, in eine reine Zweierdiskussion zu kippen, ohne dass jemand die Rolle des kritischen Gegenlesers übernimmt.
Fachlich braucht es keine Programmiererfahrung und auch keine tiefe KI-Vorkenntnis. Was zählt, ist Prozessnähe: Wer den Workflow im Alltag ausführt, bringt automatisch die Randfälle, Ausnahmen und stillschweigenden Qualitätskriterien mit, die ein Prompt später abdecken muss. Idealerweise ist außerdem eine Person aus IT oder Datenschutz zumindest zeitweise im Raum oder erreichbar, weil im Lauf des Tages fast immer Fragen zu Systemzugriff, Datenklassifizierung oder Freigabeprozessen auftauchen, die nicht spekulativ beantwortet werden sollten. Wenn der Workshop aus einem vorangegangenen Use Case Discovery Workshop hervorgeht, kennen die Teilnehmenden ihren Anwendungsfall bereits grob; wenn er eigenständig gebucht wird, klären wir die Fallauswahl in der Vorbereitungsphase.
Eine Rolle, die häufig unterschätzt wird, ist die des Auftraggebers oder der Auftraggeberin auf Fachbereichsleitungsebene. Diese Person muss nicht den ganzen Tag anwesend sein, sollte aber mindestens zur Ergebnispräsentation am Ende erscheinen, weil dort Entscheidungen über Weiterverwendung und Freigabe anstehen, die auf Teamebene nicht getroffen werden können und sollten.
Ein guter Prompt-Design-Workshop beginnt nicht am Morgen des Workshops, sondern zwei bis drei Wochen vorher, mit einem strukturierten Intake. In diesem Schritt sammeln wir für jeden geplanten Anwendungsfall: eine klare Aufgabenbeschreibung, drei bis fünf reale, möglichst anonymisierte Beispiele der Eingabedaten (eine typische Kundenanfrage, ein typisches Dokument, ein typischer Datensatz), die aktuell verwendeten Qualitätskriterien, so informell sie auch sein mögen, und Informationen darüber, welche Systeme und Datenquellen im Ernstfall angebunden werden müssten.
Dieser Vorlauf hat einen einfachen Grund: Prompt- und Agent-Design ist Arbeit an konkretem Material. Ein Workshop, der erst am Tag selbst nach Beispieldaten sucht, verliert wertvolle Zeit mit Beschaffung statt mit Iteration. Wir bitten außerdem darum, dass jede Kleingruppe vorab einen "schlechten ersten Versuch" mitbringt, also einen Prompt, den jemand schon einmal ausprobiert hat und der nicht zufriedenstellend funktioniert hat. Diese gescheiterten ersten Versuche sind didaktisch wertvoller als ein leeres Blatt, weil sie sofort zeigen, wo die Lücke zwischen Anweisung und Ergebnis liegt.
Parallel dazu klären wir technische Rahmenbedingungen: Welches Modell oder welche Plattform steht zur Verfügung, gibt es bereits eine Unternehmenslizenz für ein bestimmtes KI-Tool, gibt es Restriktionen bezüglich der Daten, die überhaupt in ein externes Modell eingegeben werden dürfen. Diese Fragen sollten idealerweise schon im Rahmen der oder eines vorangegangenen beantwortet worden sein; wo das nicht der Fall ist, klären wir sie in der Vorbereitung mit, damit der Workshop-Tag nicht mit einer Grundsatzdiskussion über Datenschutz beginnt, sondern mit Arbeit.
Das Format läuft üblicherweise als eintägiger Präsenz- oder Video-Workshop von sechs bis sieben Stunden, in seltenen Fällen als zwei kürzere Halbtage im Abstand weniger Tage, wenn die Fallauswahl komplexer ist oder mehr Abstimmung mit Fachbereichen dazwischen nötig ist. Die folgende Struktur hat sich bewährt, wobei die genaue Zeitverteilung je nach Gruppengröße und Fallkomplexität variiert.
Die ersten dreißig bis vierzig Minuten dienen der Rahmung. Hier stellen wir kein allgemeines KI-Grundlagenwissen vor, sondern ein sehr konkretes mentales Modell: Ein Sprachmodell reagiert auf Anweisungen wie eine sehr belesene, aber kontextblinde neue Mitarbeiterin, die alles kann, was man ihr präzise erklärt, aber nichts automatisch weiß, was man ihr nicht gesagt hat, und die außerdem dazu neigt, lieber eine plausible Antwort zu liefern als zuzugeben, dass ihr Informationen fehlen. Aus diesem Bild leiten wir die drei Kernprinzipien ab, die den ganzen Tag durchziehen: Instruieren (klare, vollständige Anweisung statt impliziter Erwartung), Verifizieren (systematisch prüfen, nicht dem Ergebnis vertrauen, weil es überzeugend klingt) und Korrigieren (gezielt nachsteuern, statt bei einem Fehlschlag von vorne anzufangen).
Danach folgt die Fallauswahl und Gruppenbildung, meist zwanzig Minuten, in denen jede Kleingruppe ihren mitgebrachten Anwendungsfall kurz vorstellt und wir gemeinsam prüfen, ob der Fall im Rahmen eines Tages bearbeitbar ist. Ein guter Workshop-Fall hat einen klaren Input, ein klares gewünschtes Output-Format und Beispiele, an denen sich richtig und falsch unterscheiden lässt. Fälle, die zu vage sind ("wir wollen KI im Marketing einsetzen") oder zu groß ("wir wollen unseren gesamten Kundenservice automatisieren"), werden in der Vorbereitung oder an dieser Stelle auf eine bearbeitbare Teilaufgabe heruntergebrochen.
Der Hauptteil des Vormittags, etwa neunzig Minuten, ist der ersten Bauphase gewidmet. Jede Gruppe schreibt eine erste Version ihres Prompts oder ihrer Agent-Anweisung und testet sie sofort an den mitgebrachten Beispieldaten, nicht an einem hypothetischen Testfall. Hier arbeiten wir mit einer festen Struktur, die wir "Rolle, Auftrag, Kontext, Format, Grenzen" nennen: Wer soll das Modell in dieser Aufgabe sein, was genau ist der Auftrag, welcher Hintergrund und welche Beispiele sind nötig, in welcher Form soll die Antwort kommen, und was sind die Grenzen, außerhalb derer das Modell lieber nachfragen oder ablehnen soll, statt zu raten. Diese Struktur ist bewusst kein starres Formular, sondern ein Denkgerüst, das verhindert, dass wichtige Elemente vergessen werden.
Nach der Mittagspause, die bei mehrstündigen Workshops immer als echte Pause und nicht als Arbeitszeit eingeplant wird, weil das nachmittägliche Iterieren Konzentration verlangt, folgt die zentrale Übung des Tages: der Verifikations- und Korrekturzyklus. Jede Gruppe präsentiert dem Plenum kurz ihren aktuellen Stand, nicht als fertiges Ergebnis, sondern als Zwischenstand mit offenen Fehlern. Eine andere Gruppe übernimmt die Rolle des "Red Team": Sie versucht gezielt, den Prompt zu brechen, mit Randfällen, mehrdeutigen Eingaben oder Formulierungen, die im echten Betrieb vorkommen könnten. Diese gegenseitige Prüfung ist einer der wirksamsten Bestandteile des Formats, weil Teams ihre eigenen blinden Flecken selten selbst finden, aber sehr gut die blinden Flecken anderer Teams erkennen.
Die letzten zwei bis drei Stunden des Nachmittags sind reine Iterationszeit mit begleiteter Facilitation. Wir moderieren nicht im Sinne von Vorträgen, sondern im Sinne von gezielten Fragen an jede Gruppe: Woran genau ist dieser Versuch gescheitert? War die Anweisung unklar, oder fehlte dem Modell Information, die ein Mensch stillschweigend gehabt hätte? Würde ein zusätzliches Beispiel im Prompt (few-shot) das Problem lösen, oder ist das Problem struktureller Natur und braucht eine Aufteilung in mehrere Schritte statt eines einzigen Prompts? An dieser Stelle führen wir häufig das Konzept der Aufgabenzerlegung ein: Statt eine komplexe Aufgabe in eine einzige monolithische Anweisung zu pressen, wird sie in eine Kette kleinerer, überprüfbarer Schritte zerlegt, bei der jeder Zwischenschritt ein eigenes, kontrollierbares Ergebnis liefert. Das ist der Punkt, an dem aus "einem guten Prompt" tatsächlich eine einfache Agent-Konfiguration wird: eine Abfolge von Schritten mit definierten Übergaben, nicht ein einzelner Zauberspruch.
Der Tag endet mit einer Konsolidierungsrunde von etwa vierzig Minuten, in der jede Gruppe ihre finale Version dokumentiert, die verbleibenden bekannten Schwächen benennt (jeder Prompt hat welche) und eine kurze Übergabe an die anwesende Führungsperson vorbereitet: Was ist einsatzbereit, was braucht noch technische Anbindung, wo ist menschliche Prüfung weiterhin zwingend vorgeschrieben.
Ein Prompt-Design-Workshop lebt oder stirbt an der Qualität der Moderation, weil die Versuchung groß ist, entweder zu schnell zu einer scheinbar funktionierenden Lösung zu springen oder sich in theoretischen Prompting-Tricks zu verlieren, ohne sie an echten Daten zu prüfen. Einige Techniken, die sich in der Praxis bewährt haben:
Die "Drei-Versuche-Regel" verhindert Perfektionismus in der falschen Phase: In der ersten Bauphase muss jede Gruppe innerhalb von zwanzig Minuten einen ersten testbaren Entwurf haben, egal wie unvollständig. Ziel ist ein früher, unfertiger Testlauf, nicht ein durchdachter erster Wurf, weil das Modell die eigentliche Rückmeldung liefert und jede Minute Theoriearbeit vor dem ersten Testlauf oft Annahmen produziert, die sich als falsch herausstellen.
Das "laute Denken beim Verifizieren" ist eine zweite wichtige Technik: Wenn eine Gruppe einen Modell-Output prüft, tut sie das nicht still für sich, sondern spricht ihre Prüfkriterien laut aus, damit die Gruppe (und wir als Facilitator) sehen, ob die Prüfung tatsächlich systematisch ist oder ob sie nur "sieht gut aus" als Kriterium verwendet. Diese Sichtbarkeit ist entscheidend, weil die häufigste stille Fehlerquelle im echten Betrieb genau darin liegt, dass Menschen einem plausibel klingenden KI-Output ohne echte Prüfung vertrauen.
Der bewusste Wechsel der Modellperspektive ist eine dritte Technik: Wir lassen Gruppen zeitweise nicht nur prüfen, ob der Output stimmt, sondern das Modell explizit nach den Gründen für seine Antwort fragen ("Erkläre, welche Textstellen zu dieser Kategorisierung geführt haben") und die Nachvollziehbarkeit dieser Begründung selbst bewerten. Das schult ein Gefühl dafür, wann ein Modell tatsächlich der Anweisung folgt und wann es ein zufällig plausibles Muster reproduziert.
Und schließlich das bewusste Einbauen von Störfällen: Gegen Mitte des Nachmittags geben wir jeder Gruppe bewusst ein unangenehmes Testbeispiel, eine mehrdeutige Anfrage, ein unvollständiges Dokument, einen Fall, der eigentlich eskaliert werden müsste statt automatisch bearbeitet zu werden. Wie ein Prompt oder eine Agent-Konfiguration mit dem Fall umgeht, der nicht ins Schema passt, ist oft aussagekräftiger als hundert Erfolgsfälle im Normalbetrieb.
Ein wesentlicher Teil des Werts dieses Workshops liegt darin, dass er strukturell gegen einige immer wiederkehrende Fehlermuster arbeitet, die wir aus Unternehmen kennen, die KI-Einsatz ohne dieses Zwischenformat versuchen.
Das erste Muster ist der "Ein-Satz-Prompt für eine Fünf-Schritt-Aufgabe": Der Versuch, eine komplexe, mehrstufige Aufgabe in eine einzige, kurze Anweisung zu pressen, meist mit dem Ergebnis, dass das Modell irgendeine Interpretation der Aufgabe liefert, aber nicht zuverlässig dieselbe. Der Workshop begegnet dem direkt über die Übung zur Aufgabenzerlegung.
Das zweite Muster ist blindes Vertrauen in überzeugend klingenden Output. Ein Modell, das flüssig und selbstsicher formuliert, wirkt kompetent, auch wenn der Inhalt falsch ist. Ohne eine trainierte Verifikationsgewohnheit übernehmen Teams solche Ergebnisse ungeprüft, besonders unter Zeitdruck. Der gesamte Nachmittag des Workshops ist explizit darauf ausgelegt, diese Gewohnheit zu brechen, indem Verifikation als eigener, sichtbarer Arbeitsschritt eingeübt wird, nicht als optionale Nachkontrolle.
Das dritte Muster ist die Blackbox-Haltung: die Vorstellung, ein Agent oder ein Modell sei entweder "gut" oder "schlecht" bei einer Aufgabe, statt zu verstehen, dass fast jedes Scheitern auf eine konkrete, behebbare Ursache zurückgeht, ein fehlendes Beispiel, eine mehrdeutige Formulierung, einen fehlenden Kontext, eine Aufgabe, die eigentlich zwei Aufgaben sind. Diese Blackbox-Haltung führt in der Praxis entweder zu vorschneller Ablehnung ("KI kann das einfach nicht") oder zu vorschneller Euphorie ("KI kann das", nach einem einzigen gelungenen Testlauf). Beides ist gefährlich, weil beides eine systematische Prüfung durch einen ersten Eindruck ersetzt.
Das vierte Muster ist das Fehlen jeder Eskalationslogik. Viele erste Prompt-Entwürfe beantworten jede Eingabe, auch solche, bei denen die richtige Antwort eigentlich "Ich bin mir nicht sicher, das braucht menschliche Prüfung" wäre. Ein zentraler Teil der Nachmittagsarbeit besteht deshalb darin, für jeden Anwendungsfall explizite Grenzen und Eskalationsregeln zu formulieren: Wann soll das System aktiv sagen, dass es nicht sicher ist, statt eine geratene Antwort zu liefern.
Das fünfte Muster schließlich ist die fehlende Übergabe: Ein Prompt, der am Ende eines Workshops nur in den Köpfen von drei Teilnehmenden existiert, verschwindet innerhalb weniger Wochen wieder aus dem Arbeitsalltag, sobald der Alltagsdruck zurückkehrt. Deshalb ist die Dokumentation kein administrativer Nachtrag, sondern fester, eingeplanter Bestandteil des Tages.
Der Agent- & Prompt-Design-Workshop steht nicht isoliert. Er ist der Punkt, an dem strategische Vorarbeit auf operative Umsetzung trifft. Wo vorher im Rahmen der ein Zielbild und im Rahmen eines Use Case Discovery Workshops eine priorisierte Fallliste entstanden ist, liefert dieser Workshop die ersten funktionsfähigen Artefakte: getestete Prompts, dokumentierte Agent-Konfigurationen, benannte Grenzen und offene Punkte. Diese Artefakte sind der natürliche Ausgangspunkt für ein anschließendes Pilotprojekt, in dem eine ausgewählte Konfiguration über einen längeren Zeitraum unter echten Betriebsbedingungen läuft, mit sauberer Erfolgsmessung, technischer Anbindung an die relevanten Systeme und einem klaren Entscheidungspunkt am Ende über Ausweitung, Anpassung oder Einstellung.
Der Workshop liefert dabei auch wichtige Rückmeldung in die andere Richtung. Wenn drei Kleingruppen an einem Tag merken, dass ihre Fälle strukturell ähnliche Hürden haben, etwa weil in mehreren Abteilungen dieselbe Art von unstrukturierten Dokumenten verarbeitet werden muss, ist das eine wertvolle Information für die übergeordnete Strategiearbeit, die sonst erst viel später und viel teurer sichtbar geworden wäre. Ebenso liefert der Workshop oft die ersten harten Hinweise darauf, wo tatsächlich Governance-Fragen entstehen, etwa wenn ein Anwendungsfall am Nachmittag zeigt, dass er ohne klare Freigaberegel nicht verantwortbar automatisiert werden kann. Diese Erkenntnis gehört dann zurück in die Strategie- und Governance-Arbeit, nicht in eine improvisierte Ad-hoc-Lösung im Workshop selbst.
Für Unternehmen, die noch unsicher sind, ob ihre Organisation grundsätzlich reif genug für diesen Schritt ist, bietet sich vorab der an, der unter anderem klärt, ob Datenzugriff, Werkzeuglandschaft und Freigabeprozesse so weit stehen, dass ein Prompt-Design-Workshop echte, direkt nutzbare Ergebnisse produzieren kann, statt an technischen Vorbedingungen zu scheitern.
Der Maßstab für einen gelungenen Agent- & Prompt-Design-Workshop ist nicht Begeisterung im Raum, sondern etwas Nüchterneres: Jede Kleingruppe verlässt den Tag mit mindestens einer dokumentierten, an echten Beispielen getesteten Prompt- oder Agent-Konfiguration, die sie selbst erklären und bei Bedarf anpassen kann, ohne dass eine externe Person dafür nötig ist. Diese Konfiguration hat benannte Grenzen: Sie beschreibt nicht nur, was sie kann, sondern auch, in welchen Fällen sie bewusst nicht entscheidet, sondern eskaliert. Es existiert eine kurze, aber ehrliche Liste offener Probleme, keine Behauptung von Perfektion. Und es gibt eine getroffene Anschlussentscheidung: entweder ein klarer nächster Schritt in Richtung Pilotbetrieb, oder eine begründete Entscheidung, den Fall vorerst zurückzustellen, weil zum Beispiel Datenqualität oder Systemanbindung zuerst gelöst werden müssen.
Genauso wichtig wie das fachliche Ergebnis ist ein zweiter, oft unterschätzter Effekt: Die Teilnehmenden verlassen den Raum mit einer veränderten Grundhaltung gegenüber KI-Werkzeugen. Statt eines Systems, dem man entweder vertraut oder das man ablehnt, haben sie ein Werkzeug vor sich, das man instruiert, dessen Ergebnisse man prüft und das man bei Bedarf gezielt korrigiert, so wie man es mit jedem anderen mächtigen, aber fehleranfälligen Werkzeug auch tun würde. Diese Haltung ist es, die einen einzelnen guten Prompt von einer nachhaltigen operativen Fähigkeit unterscheidet, und genau diese Fähigkeit ist der eigentliche Transferwert dieses Workshops.
Wenn Sie einen konkreten Anwendungsfall haben, an dem Ihr Team lernen soll, wie man KI-Agenten präzise instruiert, systematisch prüft und gezielt korrigiert, statt sich auf Zufallstreffer zu verlassen, sprechen Sie uns über an. Wir klären gemeinsam, ob ein eigenständiger Agent- & Prompt-Design-Workshop der richtige nächste Schritt ist oder ob vorher noch eine Runde oder ein sinnvoller ist, damit der Workshop-Tag von der ersten Minute an produktiv genutzt wird. Einen Überblick über alle Formate finden Sie außerdem auf der .