Praxisübung: eigener No-Code-Agent

Lernziele

Sie können einen vollständigen No-Code-KI-Agenten für einen selbst gewählten Unternehmensprozess eigenständig konfigurieren — von der Systemanweisung bis zur ersten Testausführung.

Sie sind in der Lage, den Agent-Canvas vollständig auszufüllen (Prozessbeschreibung, Architekturmuster, Systemanweisung, Tool-Stack, Freigabe-Klassifikation, ROI-Schätzung, Monitoring-Plan) und diesen als Architekturdokumentation zu nutzen.

Sie können Ihren Prototyp nach strukturierten Qualitätskriterien selbst bewerten und systematisch verbessern.

Sie sind in der Lage, Ihren Agenten-Prototyp in zwei Minuten verständlich zu präsentieren — für ein Fachpublikum ohne tiefe KI-Kenntnisse.

Sie können die häufigsten technischen und konzeptionellen Herausforderungen beim Agenten-Bau identifizieren und angemessene Lösungsansätze anwenden.

Sie können die Gesamtarchitektur Ihres Agenten in das Rahmenwerk aus Modul 7 einordnen: Prozessauswahl (UE 80), Architekturmuster (UE 79), Human-in-the-Loop (UE 81), Monitoring (UE 82) und ROI (UE 83).

Sie können aus der Erfahrung dieser Praxisübung konkrete nächste Schritte für den Einsatz in Ihrer Organisation ableiten.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Theorie ist der erste Schritt — Praxis ist der entscheidende. In UE 73 bis 83 haben Sie die konzeptionellen Grundlagen gelegt: Wie Agenten funktionieren, wie Sie den richtigen Prozess auswählen, wie Sie menschliche Kontrolle einbauen, wie Sie Agenten überwachen und wie Sie den wirtschaftlichen Nutzen berechnen. All das bleibt abstrakt, bis Sie es einmal selbst gebaut haben.

In dieser Abschluss-UE bauen Sie Ihren ersten eigenen No-Code-Agenten für einen realen oder realistisch modellierten Unternehmensprozess. Das Ziel ist kein perfekter Produktionsagent — das Ziel ist ein lauffähiger Prototyp, der die konzeptionellen Entscheidungen aus Modul 7 greifbar macht und zeigt, was in kurzer Zeit mit No-Code-Werkzeugen möglich ist.

Die Praxisübung ist als Einzelarbeit konzipiert — mit der Option, in Tandems zu arbeiten, wenn der gewählte Prozess von beiden Teilnehmenden geteilt wird. Das Ergebnis wird in einer zweiminütigen Peer-Präsentation vorgestellt: Was haben Sie gebaut? Welche Entscheidungen haben Sie getroffen — und warum? Was hat überrascht?

Der Abschluss dieser UE ist auch der Abschluss von Modul 7. Sie gehen mit einem konkreten Artefakt: einem konfigurierten Prototyp, einem ausgefüllten Agent-Canvas und einem persönlichen nächsten Schritt für die KI-Automatisierung in Ihrer Organisation.

Lerntext — Theorie und Konzepte

Die Lab-Struktur: Fünf Phasen in 45 Minuten

Das Lab folgt einer klar strukturierten Zeitplanung:

Phase 1 — Entscheidung und Planung (5 Minuten):

Wählen Sie Ihren Prozess. Nutzen Sie Ihren Top-1-Kandidaten aus UE 80 oder einen der Galerie-Prozesse. Füllen Sie die ersten vier Felder des Agent-Canvas aus: Prozessbeschreibung, Architekturmuster (OS / Pipeline / Standalone), Freigabe-Klassifikation (Grün / Gelb / Rot), Tool-Stack-Wahl. Diese fünf Minuten sind Investition — wer hier planlos startet, verliert Zeit in Phase 2.

Phase 2 — Systemanweisung schreiben (15 Minuten):

Das ist das Herzstück des Labs. Schreiben Sie die Systemanweisung für Ihren Agenten nach der 6-teiligen Prompt-Struktur (Rolle · Aufgabe · Ziel · Kontext · Output · Beispiele). Beginnen Sie mit dem Mindestentwurf — eine Systemanweisung, die den Agenten in die Lage versetzt, seine Kernaufgabe zu erledigen. Perfektionieren können Sie nach dem ersten Test. Schreiben Sie explizite Regeln für: Was der Agent tun soll (Hauptaufgabe), was er nicht tun soll (Scope-Grenzen), in welchem Tonfall er kommuniziert, wie der Output strukturiert sein soll (Format, Länge, Gliederung), was er tun soll, wenn er unsicher ist.

Phase 3 — Test und Iteration (15 Minuten):

Führen Sie mindestens drei Testausführungen durch — mit unterschiedlichen Inputs. Erster Test: Standardfall — funktioniert die Grundaufgabe? Zweiter Test: Grenzfall — was passiert bei unvollständigen Inputs oder Ausnahmen? Dritter Test: Kritischer Fall — was passiert, wenn der Input außerhalb des definierten Scope liegt? Notieren Sie für jeden Test: Was hat gut funktioniert? Was muss angepasst werden? Dann: eine Iteration der Systemanweisung auf Basis der Testergebnisse.

Phase 4 — Canvas vervollständigen (5 Minuten):

Füllen Sie die verbleibenden Canvas-Felder aus: Monitoring-Plan (welche drei Kennzahlen messen Sie?), ROI-Schätzung (Break-Even auf der Serviette — konservativ), Sieben Architektur-Kontrollen (welche vier implementieren Sie?), nächster Schritt für den Produktionseinsatz.

Phase 5 — Peer-Präsentation (5 Minuten, aufgeteilt auf alle Teilnehmenden):

Jede Teilnehmerin und jeder Teilnehmende hat zwei Minuten: Was haben Sie gebaut? Welche überraschende Erfahrung gab es? Welchen konkreten nächsten Schritt nehmen Sie mit?

Zwei Wege — abhängig von Vorkenntnissen und verfügbaren Tools

Weg A — Custom GPT oder Claude Project (empfohlen für Einstieg):

Dieser Weg erfordert keinen technischen Hintergrund und kann ohne Programmierkenntnisse durchgeführt werden.

Custom GPT (ChatGPT Teams oder Plus): Systemanweisung über das GPT-Editor-Interface eingeben; Dokumente für die Wissensbasis hochladen; Tools konfigurieren (Websuche, Code Interpreter, DALL-E); mit dem GPT-Builder testen.

Claude Project (Anthropic): Neues Project anlegen; Systemanweisung im Project-Instructions-Feld hinterlegen; Dokumente als Project Knowledge hochladen; im Chat testen.

Für beide Wege: Die Systemanweisung ist der zentrale Hebel. Investieren Sie die meiste Zeit in Phase 2.

Weg B — n8n oder Power Automate Workflow (empfohlen für Power-User):

Dieser Weg erzeugt einen echten Standalone- oder Pipeline-Agenten-Workflow.

n8n (No-Code): Trigger-Node (zeitbasiert oder event-basiert) → LLM-Node (OpenAI oder Anthropic API) mit Systemanweisung → Output-Node (HTTP-Request, E-Mail, Google Sheets, etc.). Für erfahrene n8n-Nutzende in 15 Minuten realisierbar.

Power Automate: Trigger (Termin in Outlook / Formular-Eingang) → AI Builder-Action mit Custom Prompt → E-Mail oder Teams-Nachricht als Output. Für Microsoft-365-Umgebungen ohne zusätzliche Kosten.

Merksatz

Beginnen Sie mit dem einfachsten Tool, das die Aufgabe erledigt. Ein gut konfigurierter Custom GPT, der zuverlässig die Kernaufgabe erfüllt, ist wertvoller als ein komplexer n8n-Workflow, der beim ersten unerwarteten Input fehlschlägt. Komplexität später hinzufügen — wenn die Grundfunktion stabil und von den Nutzenden akzeptiert ist.

Der Agent-Canvas — Pflichtdokumentation

Der Agent-Canvas ist das zentrale Dokumentationsartefakt dieser Praxisübung. Er umfasst acht Felder:

Feld 1 — Prozessbeschreibung: Was macht der Agent? In zwei Sätzen: Auslöser → Aktion → Output. Für wen? Wann?

Feld 2 — Architekturmuster (UE 79): OS-Agent / Pipeline-Agent / Standalone-Agent — mit Begründung in einem Satz.

Feld 3 — Systemanweisung: Die vollständige Systemanweisung nach der 6-teiligen Prompt-Struktur. Kein Entwurf — die finale Version nach mindestens einer Iteration.

Feld 4 — Tool-Stack: Welche Tools verwendet der Agent? Welche externen Systeme werden angebunden? Welche Datenquellen?

Feld 5 — Freigabe-Klassifikation (UE 81): Grün / Gelb / Rot — mit Begründung und, wenn Gelb: Definition des Review-Prozesses.

Feld 6 — Monitoring-Plan (UE 82): Drei Kennzahlen, die monatlich überwacht werden. Wer ist verantwortlich?

Feld 7 — ROI-Schätzung (UE 83): Break-Even in Monaten (konservativ), jährliche Zeitersparnis in Euro, kritische Annahme.

Feld 8 — Nächster Schritt: Was ist der konkrete nächste Schritt für den Produktionseinsatz? In einer Formulierung: Was genau, bis wann, wer ist verantwortlich?

Qualitätskriterien für den Prototypen

Ein vollständiger Prototyp erfüllt mindestens vier der folgenden sieben Qualitätskriterien:

Präzision der Systemanweisung: Klare Rolle, konkrete Aufgabe, definierter Output — kein „mach alles irgendwie gut”

Scope-Klarheit: Der Agent weiß explizit, was er nicht tun soll — Scope-Grenzen sind in der Systemanweisung definiert

Fehlerverhalten: Der Agent hat explizite Anweisungen für den Fall, dass der Input unvollständig, mehrdeutig oder außerhalb seines Scope ist

Output-Format: Die Ausgabe hat ein konsistentes, verwendbares Format — nicht jedes Mal anders strukturiert

Tonalität und Sprache: Die Ausgabe passt zum Unternehmenskontext — nicht zu formell, nicht zu leger, korrekte Sprache

Test-Robustheit: Der Agent produziert bei mindestens drei verschiedenen Inputs brauchbare Ausgaben

Canvas-Vollständigkeit: Alle acht Canvas-Felder sind ausgefüllt

Peer-Präsentation — Struktur für zwei Minuten

Jede Präsentation folgt einer klar vorgegebenen Struktur:

Was: Ein Satz — was macht der Agent, für wen?

Warum dieser Prozess: Ein Satz — warum war das der richtige Kandidat? (Score aus UE 80)

Wie: Architekturmuster + Tool-Stack in einem Satz

Überraschung: Was hat Sie überrascht beim Bauen — positiv oder negativ?

Nächster Schritt: Was ist der konkrete nächste Schritt — bis wann?

Diese Struktur verhindert, dass Präsentationen zu technisch oder zu allgemein werden — und fokussiert auf das, was andere Teilnehmende tatsächlich interessiert.

Vertiefung — Häufige Lab-Herausforderungen und Lösungsansätze

Herausforderung 1 — Systemanweisung zu vage:

Symptom: Der Agent antwortet sehr variabel, manchmal gut, manchmal schlecht — ohne erkennbares Muster.

Ursache: Die Systemanweisung beschreibt die Aufgabe, aber nicht das gewünschte Output-Format und nicht die Regeln für Ausnahmen.

Lösung: Drei spezifische Ergänzungen zur Systemanweisung: 1. Output-Format explizit definieren (z. B. „Antworte immer mit einer nummerierten Liste, maximal 5 Punkte, jeder Punkt maximal 2 Sätze”) 2. Beispiel-Output beifügen (Few-Shot-Prompting: zeige dem Modell, wie eine ideale Antwort aussieht) 3. Explizite Anweisung für Unsicherheit: „Wenn du dir nicht sicher bist, sage: ‚Ich bin unsicher über [spezifischer Aspekt]. Könnten Sie mir mehr Kontext geben?’”

Herausforderung 2 — Agent antwortet außerhalb seines Scope:

Symptom: Der Agent beantwortet Fragen oder erfüllt Aufgaben, die nicht zu seinem definierten Bereich gehören.

Ursache: Die Systemanweisung definiert, was der Agent tun soll, aber nicht explizit, was er nicht tun soll.

Lösung: Explizite Negativdefinition in der Systemanweisung: „Du bist ausschließlich zuständig für [Aufgabe]. Wenn du Anfragen erhältst, die außerhalb dieses Bereichs liegen, antworte mit: ‚Das liegt außerhalb meines Zuständigkeitsbereichs. Für [andere Aufgabe] wenden Sie sich bitte an [Ansprechpartner].’”

Herausforderung 3 — Output-Qualität schwankt stark je nach Input-Qualität:

Symptom: Bei gut strukturierten Inputs ist die Ausgabe ausgezeichnet; bei schlechter strukturierten Inputs ist sie schwach.

Ursache: Der Agent ist stark von der Input-Qualität abhängig — er kann aus schlechten Inputs keine guten Outputs erzeugen.

Lösung: Input-Validierung einbauen: Die Systemanweisung definiert, welche Mindest-Informationen für eine vollständige Ausgabe erforderlich sind. Wenn ein Input unvollständig ist, fragt der Agent gezielt nach, bevor er antwortet. Alternativ: Strukturiertes Input-Template für die Nutzenden (Formular statt Freitext).

Herausforderung 4 — Wissensbasis-Inhalte werden nicht konsistent genutzt:

Symptom: Der Agent nutzt manchmal Informationen aus der hochgeladenen Wissensbasis, manchmal ignoriert er sie und halluziniert eigene Informationen.

Ursache: Retrieval-Qualität ist von der Formulierung der Anfrage abhängig; die Wissensbasis ist möglicherweise nicht gut strukturiert.

Lösung: Explizite Anweisung in der Systemanweisung: „Verwende ausschließlich Informationen aus deiner Wissensbasis. Wenn die benötigte Information nicht in der Wissensbasis vorhanden ist, sage explizit: ‚Diese Information liegt mir nicht vor.’” Außerdem: Wissensbasis-Dokumente mit klaren Überschriften und Schlüsselbegriffen versehen, die gut abrufbar sind.

Herausforderung 5 — Zu lange, unübersichtliche Outputs:

Symptom: Der Agent antwortet immer sehr ausführlich — viel mehr als nötig.

Ursache: Sprachmodelle neigen dazu, ausführlich zu sein, wenn keine expliziten Längenbeschränkungen vorgegeben sind.

Lösung: Explizite Längenbeschränkung in der Systemanweisung: „Antworte immer so kurz wie möglich — maximal 200 Wörter, wenn nicht anders gefordert. Bevorzuge Aufzählungspunkte gegenüber Fließtext. Verzichte auf Einleitungen und Zusammenfassungen.”

Modul-7-Abschluss: Was Sie jetzt können

Mit dem Abschluss dieser Praxisübung haben Sie das vollständige Kompetenzprofil von Modul 7 erarbeitet:

Automatisierungs-Architektur: Sie verstehen No-Code-Werkzeuge (Zapier, Make, n8n, Power Automate), KI-Agenten-Paradigmen und Orchestrierungsmuster. Sie können für einen gegebenen Prozess das passende Architekturmuster auswählen und begründen.

Strategische Prozessauswahl: Sie können Prozesse systematisch nach Automatisierungseignung bewerten und priorisieren. Sie kennen die klaren Nein-Kriterien und können diese konsequent anwenden.

Governance und Kontrolle: Sie verstehen das Drei-Stufen-Freigabemodell und die Sieben Architektur-Kontrollen. Sie können für jeden Agenten die angemessene Stufe menschlicher Kontrolle definieren und technisch implementieren.

Monitoring und Betrieb: Sie können ein Monitoring-Konzept für einen produktiven Agenten erstellen — mit Kennzahlen, Schwellenwerten, Alerts und Feedback-Layer. Sie kennen die Logging-Anforderungen des EU AI Act.

ROI und Entscheidungsvorlagen: Sie können die wirtschaftliche Attraktivität einer Automatisierung kalkulieren — ehrlich, mit Sensitivitätsanalyse, für Führungskräfte verständlich aufbereitet.

Praktische Umsetzung: Sie haben einen No-Code-Agenten selbst gebaut, getestet und dokumentiert. Das ist die Grundlage für alle weiteren Agenten-Projekte in Ihrer Organisation.

Vertiefung II — Von der Praxisübung zur produktionsreifen Implementierung

Der Lab-Prototyp aus dieser Übung ist ein Lernprototyp — kein Produktionssystem. Der Weg vom Prototyp zur produktionsreifen Implementierung erfordert weitere Schritte, die über den Lab-Rahmen hinausgehen.

Sechs Schritte zur Produktionsreife:

Schritt 1 — Stakeholder-Freigabe: Bevor ein Agenten-Prototyp aus dem Lab in einen realen Prozess übergeht, braucht er Freigaben: IT-Sicherheits-Prüfung (welche Systeme verbindet er? welche APIs nutzt er?), Datenschutz-Prüfung (welche personenbezogenen Daten verarbeitet er?), fachliche Freigabe durch den Prozess-Owner (stimmt die Systemanweisung mit den Prozessanforderungen überein?), Compliance-Prüfung (AI Act Klassifikation, ggf. DSGVO Folgenabschätzung).

Diese Freigaben dauern typischerweise zwei bis sechs Wochen — eine Zeitplanung, die beim „nächsten Schritt” im Agent-Canvas realistisch berücksichtigt werden muss.

Schritt 2 — Produktions-Infrastruktur: Der Lab-Prototyp läuft oft in einer persönlichen Entwicklungsumgebung. Die Produktionsversion braucht eine robuste Infrastruktur: Ein Unternehmens-Zugang zu den verwendeten Tools (Custom GPT Teams-Konto, n8n Cloud oder Self-Hosted, Power Automate Premium), definierte Backup- und Failover-Mechanismen, Logging-Infrastruktur (Schicht 1 mindestens), Zugriffskontrollen (wer darf den Agenten nutzen? wer darf ihn konfigurieren?).

Schritt 3 — Erweiterter Testbetrieb (Pilotphase): Vor dem Breit-Rollout wird der Agent in einem kontrollierten Piloten getestet: eine Nutzergruppe, ein definierter Zeitraum (typisch: zwei bis vier Wochen), vollständige Monitoring-Aktivierung von Tag eins, täglicher Monitoring-Check durch den Agent-Owner, strukturiertes Feedback von den Pilot-Nutzenden nach der ersten Woche.

Wenn die Pilotphase die Qualitätskriterien erfüllt (Akzeptanzrate > 70 %, Fehlerrate < 5 %, keine kritischen Sicherheitsvorfälle), wird der Agent für den Breit-Rollout freigegeben.

Schritt 4 — Schulung und Onboarding der Nutzenden: Jeder neue Nutzer des Agenten erhält ein kurzes Onboarding: Was macht der Agent? Was macht er nicht? Wie erkenne ich Fehler? Was tue ich bei Unsicherheit? Wie gebe ich Feedback?

Die Onboarding-Dokumentation wird aus den Lab-Erfahrungen und der Pilotphase erarbeitet — konkrete Beispiele aus der Praxis sind wirkungsvoller als abstrakte Erklärungen.

Schritt 5 — Übergabe an den Agent-Owner: Nach dem Breit-Rollout übergibt das Projekt-Team den Agenten an den dauerhaften Agent-Owner. Dieser übernimmt: monatliche Monitoring-Reviews, Systemanweisungs-Pflege, Wissensbasis-Aktualisierungen, Kommunikation mit Nutzenden bei Änderungen.

Die Übergabe beinhaltet eine vollständige Architekturdokumentation (Agent-Canvas + Monitoring-Konzept + Escalation-Runbook), einen Übergabe-Workshop (eine Stunde) und einen 30-tägigen Onboarding-Support durch das Projekt-Team.

Schritt 6 — Quartalsmäßige Bewertung: Alle drei Monate wird der Agent gegen die ursprüngliche ROI-Kalkulation verglichen: Stimmen Zeitersparnis, Kosten und Qualitätskennzahlen mit den Erwartungen überein? Sind neue Use Cases entstanden? Muss die Architektur angepasst werden? Ist die Freigabe-Klassifikation noch korrekt?

Merksatz

Der Lab-Prototyp ist der Beweis, dass die Idee funktioniert. Die produktionsreife Implementierung ist der Beweis, dass die Organisation bereit ist, Verantwortung für einen KI-Agenten zu übernehmen. Beide Schritte sind notwendig — aber sie sind fundamental verschieden. Wer den Prototyp als Produktionssystem behandelt, riskiert Qualitätsprobleme, Compliance-Verstöße und Vertrauensverlust.

Fehler beim Übergang vom Prototyp zur Produktion — und wie man sie vermeidet

Fehler 1 — Prototyp direkt in Produktion übernehmen: Der Lab-Prototyp wurde für acht Inputs getestet. In der Produktion kommen täglich 200 verschiedene Inputs — darunter viele, die im Lab nicht getestet wurden. Die Fehlerrate steigt, Nutzende werden frustriert, Vertrauen schwindet.

Lösung: Strukturierte Pilotphase mit erweiterten Testfällen bevor Breit-Rollout.

Fehler 2 — Wissensbasis nicht aktuell halten: Der Agent wurde mit der Preisliste vom Januar 2024 konfiguriert. Im April 2024 ändert sich die Preisliste. Niemand aktualisiert die Wissensbasis. Der Agent gibt falsche Preise aus — und der erste Kunde beschwert sich.

Lösung: Wissensbasis-Aktualisierungs-Prozess als Teil des Agenten-Lifecycle definieren. Trigger: Jede inhaltlich relevante Änderung (Preislisten, Produktkatalog, Richtlinien) → automatische Aufgabe für den Agent-Owner.

Fehler 3 — Systemanweisung nie anpassen: Die Systemanweisung wurde beim Lab geschrieben und nie verändert. Die Monitoring-Daten zeigen seit Monaten, dass 40 % der Ausgaben manuelle Korrekturen erfordern — aber niemand liest die Monitoring-Daten. Die Systemanweisung bleibt so wie sie ist.

Lösung: Monatlicher Monitoring-Review als Pflichttermin mit explizitem Output: Liste der Systemanweisungs-Anpassungen für diesen Monat.

Fehler 4 — Agenten-Expansion ohne neue Prüfung: Der Angebots-Agent funktioniert gut. Jemand hat eine gute Idee: „Lass uns den Agenten auch für Rechnungen nutzen!” Die Systemanweisung wird schnell erweitert. Aber: Rechnungen sind rechtlich abschlusswirksame Dokumente — der Agent ist jetzt Rot-klassifiziert, nicht mehr Gelb. Ohne neue Freigabe-Klassifikation und ohne HitL-Mechanismus für Rechnungen ist das eine Compliance-Verletzung.

Lösung: Jede Scope-Erweiterung eines Agenten durchläuft denselben Freigabe-Prozess wie ein neuer Agent.

Die organisatorische Lernkurve nach der Praxisübung

Die wertvollsten Lernerfahrungen aus einer Praxisübung wie dieser UE entstehen nicht immer im direkten Prozess, sondern in der Reflexion danach.

Drei Erkenntnisse, die fast alle Teilnehmenden teilen:

Erstens — Die Systemanweisung ist schwieriger als erwartet: Das Formulieren einer präzisen, vollständigen Systemanweisung ist eine eigene Kompetenz, die Übung erfordert. Der erste Entwurf ist selten der beste. Iteration ist kein Zeichen von Schwäche — sie ist der normale Weg zu einer guten Systemanweisung.

Zweitens — Die Testphase deckt immer Überraschungen auf: Kein Prototyp übersteht drei strukturierte Testfälle ohne mindestens eine Anpassung. Die Überraschungen im Test sind nicht Fehler des Ansatzes — sie sind der Wert des Tests. Was im Lab nicht getestet wird, scheitert in der Produktion.

Drittens — Der Zeitaufwand liegt in der Vorbereitung, nicht im Bauen: Wer den Prozess sorgfältig aufgenommen, die Systemanweisung durchdacht und den Canvas ausgefüllt hat, baut den Agenten schneller und stabiler als jemand, der sofort mit dem Bauen beginnt. Die Investition in Planung zahlt sich immer aus.

Diese drei Erkenntnisse sind der eigentliche Kompetenzaufbau dieser Praxisübung — nicht die technische Konfiguration des Custom GPT, sondern das tiefere Verständnis dafür, was einen guten KI-Agenten ausmacht.

Der Weg zur nächsten Ebene:

Wer nach dieser Praxisübung weitermachen möchte, findet den nächsten sinnvollen Schritt auf drei Ebenen:

Ebene 1 — Vertiefung No-Code: Weiteres Lab mit n8n oder Power Automate, wenn in dieser UE Weg A verwendet wurde. Ziel: einen echten Standalone-Agenten mit automatischem Trigger bauen.

Ebene 2 — Wissensbasis und RAG: Den Agenten mit einer strukturierten Wissensbasis ausstatten (UE 77). Wie verbessert eine gut kuratierte Wissensbasis die Ausgabe-Qualität gegenüber der reinen Systemanweisung?

Ebene 3 — Monitoring aktivieren: Das Minimal-Monitoring-Setup aus UE 82 für den eigenen Agenten implementieren. Zwei Wochen Betrieb mit Monitoring — und dann die Daten analysieren.

Jede dieser drei Ebenen kann in einer halben bis ganzen Arbeitswoche erreicht werden — vorausgesetzt, der organisatorische Kontext stimmt und die nötigen Tool-Zugänge sind vorhanden.

Vertiefung II — Strategische Ebene — Vom Modul-Abschluss zur dauerhaften KI-Praxis: Transfer und Verankerung

Die Praxisübung am Ende von Modul 7 ist kein Schlusspunkt — sie ist ein Übergangsritual. Sie markiert den Moment, in dem das Lernen im geschützten Kursraum übergeht in die Anwendung in der realen Arbeitswelt, mit echten Daten, echten Nutzern und echten Konsequenzen. Dieser Übergang gelingt nicht automatisch. Er erfordert Transferplanung, Unterstützungsstrukturen und ein realistisches Bild davon, was die ersten Wochen und Monate nach dem Kurs typischerweise bereithält — einschließlich der Hindernisse, die den Transfer erfahrungsgemäß bremsen.

Die Transferlücke — und warum sie so häufig entsteht

Bildungsforschung zeigt konsistent, dass zwischen 50 und 80 Prozent des in Schulungen und Trainings Gelernten innerhalb weniger Wochen ohne aktive praktische Anwendung verblasst. Bei technischen Fähigkeiten — insbesondere im KI-Bereich, wo die Werkzeuge sich schnell weiterentwickeln und Interfaces sich verändern — ist dieser Verfall besonders ausgeprägt. Das Erlernte bleibt abstrakt, wenn kein konkreter Anwendungsfall existiert, der es erdet.

Die Transferlücke entsteht dabei selten durch fehlende Motivation der Teilnehmenden. Sie entsteht durch strukturelle Hindernisse: Der Arbeitsalltag lässt keine geschützte Zeit für Experimente. Kollegen befinden sich nicht auf demselben Wissensstand und können nicht als Sparringspartner dienen. Die ersten Eigenversuche scheitern an Details, die im Kurs nicht aufgetreten sind — und ohne unmittelbar verfügbare Hilfe bleibt man stecken, erlebt Frustration, und kehrt zu gewohnten, bewährten Methoden zurück. Dieser Kreislauf ist so häufig, dass er nicht als individuelles Versagen interpretiert werden sollte, sondern als strukturelles Problem, das strukturelle Lösungen erfordert.

Merksatz

Transfer sichern heißt, die ersten 30 Tage nach dem Kurs strukturieren — nicht den Kurs selbst. Konkrete Transferaufgaben, Peer-Tandems und ein fester wöchentlicher KI-Anwendungsblock im Kalender erhöhen die Transferrate nachweislich erheblich. Ohne diese Strukturen verpufft ein Großteil des Lerneffekts innerhalb von vier bis sechs Wochen — unabhängig davon, wie gut der Kurs war.

Das 30-60-90-Tage-Modell für nachhaltigen Transfer

Eine bewährte Transferstruktur gliedert die ersten drei Monate nach dem Kurs in drei Phasen mit je unterschiedlichem Fokus.

Erste 30 Tage — Fundament legen: Ein konkreter Anwendungsfall aus dem eigenen Arbeitsalltag wird mit den im Kurs erlernten Methoden umgesetzt — sei es ein einfacher KI-Assistent mit einer No-Code-Plattform, sei es eine automatisierte Zusammenfassung von Besprechungsprotokollen, sei es ein strukturierter Prompt-Workflow für wiederkehrende Rechercheaufgaben oder Angebotserstellungen. Das Ziel dieser ersten Phase ist nicht Perfektion, sondern ein erstes funktionierendes Artefakt, das im eigenen Kontext nachweisbaren Nutzen stiftet — auch wenn dieser Nutzen zunächst klein ist. Dieses erste Artefakt ist der Beweis gegenüber sich selbst, dass das Gelernte anwendbar ist.

Tage 31 bis 60 — Vertiefen und erweitern: Das erste Artefakt wird auf Basis der gesammelten Praxiserfahrung iterativ verbessert. Eine zweite Anwendung wird identifiziert, geplant und entwickelt. Ein Peer-Tandem — idealerweise mit einer weiteren Kursteilnehmerin oder einem weiteren Kursteilnehmer — trifft sich in dieser Phase zweiwöchentlich für 30 bis 45 Minuten in einem strukturierten Format: Was hat funktioniert? Wo ist man nicht weitergekommen? Was hat man dabei gelernt? Diese regelmäßigen Gespräche halten den Entwicklungsimpuls aufrecht, wenn der Alltag ihn zu überdecken droht.

Tage 61 bis 90 — Multiplizieren: Die entwickelten Lösungen werden im eigenen Team vorgestellt. Mindestens eine Kollegin oder ein Kollege wird aktiv als Nutzerin oder Nutzer gewonnen und beginnt, die Lösung in der eigenen Arbeit einzusetzen. Ein erster interner Bericht — auch eine kurze E-Mail oder ein Foliensatz mit drei Slides ist ausreichend — dokumentiert den messbaren Nutzen: eingesparte Zeit, verbesserte Qualität, reduzierte Fehlerrate. Dieser Bericht hat zwei Funktionen: Er schafft Rechenschaftspflicht, und er erzeugt organisationale Sichtbarkeit für die Transferleistung.

Peer-Learning nach dem Kurs — Informelle Wissensgemeinschaft

Eine der wirksamsten und gleichzeitig ressourcenschonendsten Transferstrategien ist die Bildung einer kleinen informellen Wissensgemeinschaft unter den Kursteilnehmenden: Eine gemeinsame Kommunikationsgruppe — in welchem Medium auch immer im Unternehmen üblich — in der Entdeckungen, nützliche Prompt-Strukturen, Fehlschläge und die daraus gezogenen Schlüsse geteilt werden. Diese Gruppe hat keine formale Agenda, keine Hierarchie und keinen Bewertungsrahmen — ihr einziger Zweck ist gegenseitige Unterstützung zwischen Personen, die denselben Lernhintergrund teilen.

Erfahrungen aus der betrieblichen Weiterbildung im KI-Bereich zeigen, dass solche Gruppen besonders dann über Monate aktiv bleiben, wenn sie eine niedrigschwellige, explizite Norm entwickeln: Es ist ausdrücklich erwünscht, halbfertige Gedanken, gescheiterte Versuche und unbeantwortete Fragen zu teilen. Perfektion ist kein Zugangskriterium. Eine „das hat nicht funktioniert, weiß jemand warum?“-Nachricht ist genauso wertvoll wie eine „das hat perfekt funktioniert”-Nachricht. Diese psychologische Sicherheit senkt die Hemmschwelle und hält den Austausch am Leben, weil er nicht zur Selbstdarstellungsfläche wird, sondern zur echten Arbeitsgemeinschaft.

Die Rolle der Führungskraft im Transfer

Führungskräfte, die aktiv und sichtbar in den Transferprozess eingebunden sind, erhöhen die Transferrate ihrer Teams messbar. Dabei erfordern die wirksamen Maßnahmen keine erhebliche Zeitinvestition — aber sie erfordern Regelmäßigkeit und Aufrichtigkeit.

Konkret bedeutet das: Die Führungskraft stellt in monatlichen Team-Meetings explizit die Frage, welche KI-Anwendungen im Team aktiv genutzt werden und welche Erfahrungen dabei gemacht wurden — nicht als Kontrolle, sondern als echtes Interesse. Sie schützt Zeit für Experimente in Phasen, in denen der Workload Druck aufbaut — auch dann, wenn der kurzfristige Effizienzgewinn durch Experimente zunächst negativ ist. Sie erkennt Transferleistungen sichtbar an, auch wenn die Ergebnisse noch nicht ausgereift sind: „Du hast in den letzten vier Wochen diesen Agenten gebaut — das ist wertvolle Arbeit, auch wenn wir ihn noch weiterentwickeln müssen.”

Führungskräfte, die nach dem Kursabschluss keinen weiteren Impuls setzen, senden — unbeabsichtigt — ein sehr klares Signal: Das Gelernte ist im Tagesgeschäft nicht wirklich relevant; es war eine Pflichtschulung, die abgehakt wurde. Dieses Signal ist stärker als jede noch so gut gestaltete Trainingsmaßnahme. Die Transferrate reagiert auf dieses Signal entsprechend.

Was Modul 7 bewirkt haben soll — Rückblick und Ausblick

Modul 7 hat die Teilnehmenden von passiven Beobachtenden des KI-Trends zu aktiven Gestalterinnen und Gestaltern gemacht. Sie können KI-Agenten nicht nur theoretisch einordnen, sondern praktisch aufbauen, bewerten und ihren Kolleginnen und Kollegen erklären. Sie wissen, welche Prozesse sich für Automatisierung eignen und welche nicht — und sie haben die Bewertungslogik dafür internalisiert, nicht nur auswendig gelernt. Sie kennen die rechtlichen Leitplanken des EU AI Act und der DSGVO, die wirtschaftliche Kalkulation über die ROI-Grundformel und die Nachkalkulation, und das Prinzip der menschlichen Aufsicht, das verantwortungsvolle KI-Systeme zwingend erfordert. Und sie haben in der Praxisübung bewiesen, dass sie dieses Wissen in einem realen Prototypen anwenden können — unter Zeitdruck, mit echten Entscheidungen und mit einem Ergebnis, das sie ihren Peers präsentiert haben.

Das ist kein kleiner Lernfortschritt. Es ist der Unterschied zwischen dem Verstehen von KI als externer Technologie und dem Erleben von KI als eigener Handlungsmöglichkeit. Dieser Unterschied ist der Ausgangspunkt für das, was jetzt beginnt: die kontinuierliche, lernende, kritische und verantwortungsvolle Anwendung von KI in der täglichen Arbeit — im eigenen Bereich, im eigenen Team und in der eigenen Organisation.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

In der Abschluss-Praxis-UE eines Trainings für ein IT-Beratungsunternehmen wählen die meisten Teilnehmenden Agenten, die ihren Arbeitsalltag direkt betreffen: Ein Teilnehmer aus dem Vertrieb baut einen Meeting-Vorbereiter (Standalone-Agent mit Weg A/Custom GPT): Trigger ist eine E-Mail-Zusammenfassung des Kalendereintrags, die Systemanweisung definiert Unternehmensrecherche + Gesprächspartner-Profile + aktuelle News in einem 1-seitigen Briefing-Format. Nach zwei Testläufen ist der Prototyp einsatzbereit. Eine Teilnehmerin aus dem Projektmanagement baut einen Sprint-Review-Bericht-Agenten (Pipeline-Agent mit Weg B/n8n): Input ist das strukturierte Jira-Export-CSV, Output ist ein formatierter Sprint-Review-Report mit Fortschritts-Kennzahlen und offenen Risiken. Beide präsentieren Ergebnisse in der Gruppe oder allein — die Diskussion über die unterschiedlichen Architekturentscheidungen (Custom GPT vs. n8n; interaktiv vs. automatisch) ist das lehrreichste Moment der gesamten UE.

Industrie & Fertigung

Teilnehmende aus einem Fertigungsunternehmen bauen Agenten, die eng an ihre MES-Prozesse anknüpfen. Da direkter API-Zugriff auf Produktionssysteme im Lab nicht möglich ist, arbeiten sie mit simulierten Eingabedaten (CSV-Exports aus dem MES). Ein Teilnehmer aus der Qualitätssicherung baut einen Störungsmeldungs-Klassifikations-Agenten: Input ist der Störungstext aus dem Wartungsprotokoll, Output ist eine strukturierte Klassifikation nach Anlagentyp, Dringlichkeit und empfohlener Maßnahme. Die Systemanweisung enthält eine eingebettete Klassifikationsmatrix aus dem internen QS-Handbuch — das Dokument wird als Wissensbasis-Datei hochgeladen. Nach dem Lab: Der Teilnehmer spricht noch am selben Abend mit der IT-Abteilung über den nächsten Schritt — API-Anbindung an das MES für den Produktivbetrieb. Diese Konkretheit ist das Ziel der Praxisübung.

Finanzdienstleistung & Versicherung

In einem Finanzdienstleistungs-Training bauen Teilnehmende Agenten mit besonderer Sorgfalt bei der Freigabe-Klassifikation. Eine Teilnehmerin aus dem Schadenbereich baut einen Schaden-Erstauskunft-Agenten (Pipeline-Agent): Input ist eine strukturierte Schaden-Erstmeldung, Output ist eine Zusammenfassung der Deckungsprüfung nach standardisierter Vorlage — immer mit dem Hinweis „Dieser Entwurf muss von einem Sachbearbeiter geprüft und freigegeben werden.” (Gelb-klassifiziert). Die Systemanweisung enthält eine explizite Anweisung: „Du triffst keine Leistungsentscheidungen. Wenn ein Fall Leistungsentscheidungen erfordert, markiere das explizit für die menschliche Prüfung.” Im Canvas-Feld „Nächster Schritt” steht: Compliance-Prüfung und Datenschutz-Folgenabschätzung als vorgelagerter Schritt vor der Pilotierung. Das ist die richtige Reihenfolge — und das Bewusstsein dafür ist das wichtigste Lernziel des Labs für diese Gruppe.

Öffentliche Verwaltung

Teilnehmende aus der öffentlichen Verwaltung wählen Agenten für die Bürger-Standardkommunikation — mit besonderer Sorgfalt bei Datenschutz und Tonalität. Eine Teilnehmerin aus dem Bürgerbüro baut einen FAQ-Antwort-Agenten (Pipeline-Agent): Input ist eine Bürgeranfrage zu Standardthemen (Öffnungszeiten, Formulare, Zuständigkeiten), Output ist ein Antwort-Entwurf auf Basis eines hochgeladenen FAQ-Dokuments — immer zur manuellen Freigabe vorgelegt (Gelb). Die Systemanweisung enthält explizite Tonalitätsvorgaben: „Antworte stets respektvoll, bürgerfreundlich und in einfacher Sprache (Leseniveau: Klasse 10). Vermeide Amtsdeutsch. Wenn du die Antwort nicht kennst, sage: ‚Für diese Anfrage empfehle ich Ihnen, direkt in der Abteilung [X] anzurufen.’” Ein Teilnehmer aus dem Standesamt ergänzt: „Das hätten wir vor zwei Jahren gebraucht — wir haben damals noch dieselbe E-Mail 30 Mal täglich manuell beantwortet.”

Übung 1 — Agent-Canvas ausfüllen

Aufgabe: Bevor Sie mit dem Bauen beginnen, füllen Sie die ersten fünf Felder des Agent-Canvas aus. Das ist die Planungsphase des Labs (Phase 1 + Vorbereitung Phase 2).

Schritt-für-Schritt: 1. Prozessbeschreibung: Beschreiben Sie Ihren Prozess in zwei Sätzen nach dem Muster: „[Auslöser] → [Agent führt X aus] → [Output Y wird erzeugt und an Z übergeben].” 2. Architekturmuster: Welches der drei Muster (OS / Pipeline / Standalone) passt? Begründung in einem Satz. 3. Tool-Stack-Wahl: Custom GPT (Weg A) oder n8n / Power Automate (Weg B)? Begründung. 4. Freigabe-Klassifikation: Grün / Gelb / Rot mit Begründung. Wenn Gelb: Wie sieht der Review-Prozess aus? 5. Systemanweisung-Entwurf (6-teilige Prompt-Struktur):

ROLLE: Du bist [BESCHREIBUNG der Rolle des Agenten]



AUFGABE: Deine Aufgabe ist es, [KONKRETE AUFGABE].



ZIEL: Das Ziel ist [GEWÜNSCHTES ERGEBNIS].



KONTEXT: [UNTERNEHMENSKONTEXT, relevante Hintergrundinformationen]



OUTPUT: Antworte immer mit [FORMAT-BESCHREIBUNG].

Maximal [WÖRTER/LÄNGE]. Struktur: [GLIEDERUNGSVORGABE].



BEISPIELE: [OPTIONAL: EIN BEISPIEL-INPUT und BEISPIEL-OUTPUT]



REGELN:

- Du tust ausschließlich [HAUPTAUFGABE]

- Du tust NICHT: [EXPLIZITE AUSSCHLÜSSE]

- Bei Unsicherheit: [ANWEISUNG FÜR UNSICHERE FÄLLE]

Musterlösung — Meeting-Vorbereiter:

Prozessbeschreibung: „Sobald ein neuer Kundentermin im Kalender erscheint, erstellt der Agent automatisch ein strukturiertes 1-seitiges Briefing über das Unternehmen und die Gesprächspartner und legt es im Teams-Kanal des zuständigen Beraters ab.”

Architekturmuster: Standalone-Agent — ereignisgetriggert (neuer Kalendereintrag), vollautomatisch, kein Nutzer-Input während der Ausführung.

Tool-Stack: Custom GPT (Weg A) mit Websuche aktiviert — für die Pilotphase ausreichend; spätere Integration via n8n für automatische Kalendererkennung.

Freigabe-Klassifikation: Grün — interne Informationsbereitstellung ohne externe Kommunikation, keine personenbezogenen Daten gehen nach außen, Fehler (falsche Unternehmensinfo) sind sofort erkennbar.

Systemanweisung:

ROLLE: Du bist ein Recherche-Assistent für Vorbereitung von Kundengesprächen.



AUFGABE: Erstelle ein strukturiertes Meeting-Briefing für das folgende Kundengespräch.



ZIEL: Der Gesprächspartner soll gut vorbereitet ins Meeting gehen können —

mit relevantem Kontext über das Unternehmen und die Gesprächspartner.



KONTEXT: Das Briefing wird von Unternehmensberatern genutzt,

die Erstgespräche und laufende Kundenmeetings führen.



OUTPUT: Strukturiertes Briefing in folgendem Format:

1. Unternehmens-Steckbrief (5–7 Punkte: Branche, Größe, Standorte,

Kernprodukte, aktuelle News der letzten 30 Tage)

2. Gesprächspartner-Profile (je Person: Funktion, Hintergrund, LinkedIn-Highlights)

3. Gesprächskontext (3 relevante Branchenentwicklungen für das Meeting)

4. Empfohlene Einstiegsfragen (3 Fragen)

Maximal 1 A4-Seite Äquivalent. Verwendete Sprache: Deutsch.



REGELN:

- Nur öffentlich verfügbare Informationen verwenden

- Keine nicht verifizierbaren Behauptungen

- Wenn eine Information nicht verfügbar ist: „Information nicht verfügbar"

statt Halluzination

- Du erstellst ausschließlich Briefings, keine anderen Dokumente

Übung 2 — Bauen, Testen, Dokumentieren

Aufgabe: Sie bauen Ihren Agenten nach dem Canvas aus Übung 1, führen drei Testdurchläufe durch, iterieren die Systemanweisung und füllen den Canvas vollständig aus.

Schritt-für-Schritt (Phase 2–4 des Labs):

Phase 2 — Systemanweisung implementieren (15 Minuten): 1. Custom GPT: Neues GPT erstellen, Systemanweisung einfügen, ggf. Dokumente hochladen, relevante Tools aktivieren (Websuche, Code Interpreter). Oder: n8n-Workflow mit LLM-Node und Systemanweisung konfigurieren. 2. Erste kurze Testausführung mit Standard-Input. 3. Systemanweisung anpassen wenn nötig — dann Schritt 2 wiederholen.

Phase 3 — Drei strukturierte Testdurchläufe (15 Minuten): - Test 1 — Standardfall: Typischer Input aus dem realen Prozess. Bewertung: Ist die Ausgabe verwendbar? Entspricht sie dem definierten Output-Format? - Test 2 — Grenzfall: Unvollständiger Input, mehrdeutige Formulierung, oder Input am Rand des Scope. Bewertung: Fragt der Agent nach? Oder produziert er eine schlechte Ausgabe ohne Hinweis? - Test 3 — Out-of-Scope-Input: Input, der explizit nicht in den Scope fällt. Bewertung: Lehnt der Agent korrekt ab und gibt eine hilfreiche Weiterleitung?

Phase 4 — Canvas vervollständigen (5 Minuten): - Monitoring-Plan: Drei Kennzahlen + Schwellenwert + Verantwortlicher - ROI-Schätzung (Servietten-Version): Monatliche Zeitersparnis in Stunden × 75 €/h − HitL-Kosten − 50 € laufende Kosten = Nettonutzen. Break-Even = Einmalaufwand ÷ Nettonutzen. - Nächster Schritt: Konkret — was genau, bis wann, wer.

Bewertung des eigenen Prototyps (Selbstbewertung nach den sieben Qualitätskriterien): Bewerten Sie Ihren Prototyp für jedes der sieben Kriterien mit erfüllt / teilweise erfüllt / nicht erfüllt. Ziel: mindestens vier von sieben als „erfüllt” markieren.

Peer-Präsentation (2 Minuten): - Was: Ein Satz - Warum dieser Prozess: Score oder strategische Bedeutung - Wie: Architekturmuster + Tool in einem Satz - Überraschung: Was hat Sie überrascht? - Nächster Schritt: Konkret und datiert

PromptBox — Systemanweisung generieren und verbessern

Prompt: Vollständige Systemanweisung nach der 6-teiligen Prompt-Struktur erstellen

Ich möchte eine vollständige Systemanweisung für einen KI-Agenten erstellen.

Nutze die 6-teilige Prompt-Struktur (Rolle · Aufgabe · Ziel · Kontext · Output · Beispiele).



Mein Agent soll folgendes tun:

[BESCHREIBUNG: Was soll der Agent konkret tun? Für wen? In welchem Kontext?]



Architekturmuster: [OS-Agent / Pipeline-Agent / Standalone-Agent]

Freigabe-Klassifikation: [Grün / Gelb / Rot]

Zielgruppe der Ausgabe: [Intern / Kunden / Behörden]

Gewünschtes Output-Format: [z. B. strukturierte Liste / Fließtext-Absätze / Tabelle]

Maximale Output-Länge: [z. B. 1 A4-Seite / 200 Wörter / 5 Punkte]



Erstelle bitte:

1. Vollständige Systemanweisung nach der 6-teiligen Struktur

2. Drei explizite Regeln für „Was der Agent NICHT tun soll" (Scope-Grenzen)

3. Eine explizite Anweisung für den Fall, dass der Input unvollständig oder unklar ist

4. Ein konkretes Beispiel-Input und Beispiel-Output (Few-Shot), das in die Systemanweisung integriert werden kann

5. Drei Testfälle (Standardfall, Grenzfall, Out-of-Scope), mit denen ich die Systemanweisung validieren kann



Antworte auf Deutsch. Halte die Systemanweisung präzise und konkret —

keine allgemeinen Platzhalter, sondern spezifische Anweisungen.

Erwartetes Ergebnis: Eine vollständige, direkt einsetzbare Systemanweisung für Custom GPT, Claude Project oder als n8n LLM-Node-Konfiguration.

Zweiter Prompt: Systemanweisung nach dem ersten Testlauf verbessern

Ich habe die folgende Systemanweisung für meinen KI-Agenten:



[SYSTEMANWEISUNG EINFÜGEN]



Bei einem Testdurchlauf habe ich folgende Probleme festgestellt:



Test-Input: [INPUT]

Tatsächlicher Output: [OUTPUT]

Was war das Problem: [BESCHREIBUNG DES PROBLEMS — z. B. zu vage, falsches Format,

außerhalb Scope, halluziniert, zu lang]



Bitte:

1. Identifiziere die wahrscheinliche Ursache des Problems in der Systemanweisung

2. Schlage eine konkrete Anpassung der Systemanweisung vor (nur die betroffene Stelle)

3. Beschreibe, wie der Output nach der Anpassung aussehen sollte



Ändere nur, was nötig ist. Verändere keine Teile der Systemanweisung,

die bereits gut funktionieren.

Cheat-Sheet — Lab-Kurzreferenz

6-teilige Prompt-Struktur: Rolle | Aufgabe | Ziel | Kontext | Output | Beispiele

Kritischste Systemanweisungs-Elemente: - Output-Format explizit: Format + Länge + Gliederung - Scope-Grenzen explizit: Was der Agent NICHT tut - Unsicherheits-Anweisung: „Wenn du unsicher bist, sage…”

Weg A (Custom GPT / Claude): Systemanweisung + Wissensbasis-Dokumente + Tools aktivieren + Chat-Test

Weg B (n8n / Power Automate): Trigger-Node + LLM-Node mit Systemanweisung + Output-Node

Drei Pflicht-Testfälle: Standardfall ✓ | Grenzfall (unvollständiger Input) ✓ | Out-of-Scope-Input ✓

Agent-Canvas Felder: Prozess | Architekturmuster | Systemanweisung | Tool-Stack | HitL-Klassifikation | Monitoring | ROI | Nächster Schritt

Sieben Qualitätskriterien: Präzision | Scope-Klarheit | Fehlerverhalten | Output-Format | Tonalität | Test-Robustheit | Canvas-Vollständigkeit

Peer-Präsentation: Was | Warum | Wie | Überraschung | Nächster Schritt — je ein Satz, 2 Minuten total

Erste Regel für Iteration: Nur ein Problem auf einmal lösen — nie die gesamte Systemanweisung gleichzeitig ändern

Reflexionsfragen

Was war das überraschendste an der Erfahrung, Ihren eigenen Agenten zu bauen — und was hat sich dadurch in Ihrem Verständnis von KI-Agenten verändert?

Welche der fünf Herausforderungen aus der Vertiefung sind Ihnen im Lab begegnet — und wie haben Sie sie gelöst?

Was sind die drei wichtigsten Qualitätskriterien für Ihren spezifischen Agenten-Prototyp — und warum genau diese drei?

Der Agent-Canvas fordert einen „konkreten nächsten Schritt”. Was ist realistischerweise in den nächsten 30 Tagen erreichbar — und was brauchen Sie dafür von Ihrer Organisation?

Wenn Sie jetzt in einem Jahr zurückblicken und sagen können „das war der wichtigste Schritt” — welcher Agent-Prototyp oder welche Implementierung wäre das?

Was müsste sich in Ihrer Organisation ändern, damit KI-Agenten systematisch eingeführt werden können — nicht als Einzelprojekte, sondern als strukturierter Prozess?

Modul 7 ist abgeschlossen. Welche der 12 Einheiten war am relevantesten für Ihren Arbeitskontext — und welches Konzept werden Sie morgen in der Praxis einsetzen?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema

Timing (45 Min): 3 Min Einführung (Überblick Lab-Struktur, fünf Phasen erklären, Tool-Zugang sicherstellen), 2 Min Planung selbständig (Phase 1: Prozess wählen + erste vier Canvas-Felder), 15 Min Bauen (Phase 2: Systemanweisung schreiben und erste Testausführung), 13 Min Testen und Iterieren (Phase 3: drei Testfälle, eine Systemanweisungs-Iteration, Phase 4: Canvas vervollständigen), 12 Min Peer-Präsentation (5–6 Teilnehmende × 2 Minuten) und Abschluss-Reflexion.

Methodische Empfehlung: Die 15-minütige Bauphase darf nicht durch Zwischeneinführungen unterbrochen werden. Der Trainer ist während dieser Phase als Coach präsent — geht von Person zu Person, stellt Fragen, hilft bei Blockaden — aber hält keine weiteren Input-Einheiten. Wer fertig ist, startet mit den Testfällen. Wer noch am Schreiben ist, bekommt einen Impuls: „Was ist das spezifischste Output-Format, das Sie sich vorstellen können? Schreiben Sie das als Anweisung.”

Häufige Stolperstellen:

(a) Systemanweisung zu abstrakt / vage: Gegensteuern: „Beschreiben Sie die Ausgabe, als würden Sie sie einer Kollegin erklären, die den Kontext nicht kennt. Was steht in Abschnitt 1? Was steht in Abschnitt 2? Wie lang ist jeder Abschnitt?” — Konkretheit erzwingt.

(b) Unsicherheit über Prozess-Wahl: Wenn noch kein Top-Kandidat aus UE 80 identifiziert wurde: schnelle 5-Minuten-Entscheidung nach dem Copy-Paste-Test oder den Wiederkehrende-E-Mail-Test anregen. Noch besser: Vorab in UE 80 explizit für UE 84 vorbereiten.

(c) Technische Probleme bei Tool-Zugang: Immer Weg A als Fallback sicherstellen (Custom GPT oder Claude — nur Browser und Zugang nötig). Weg B (n8n, Power Automate) nur wenn der Tool-Zugang im Voraus gesichert ist.

(d) Peer-Präsentation wird zu technisch: Erinnerung vor Beginn: „Stellen Sie sich vor, Sie präsentieren einem Vorgesetzten, der kein KI-Experte ist. Was ist das Erste, was er wissen will?” Das fokussiert auf Nutzen statt Technik.

(e) Zeitdruck führt zu halb-fertigem Canvas: Canvas-Vollständigkeit ist ein Qualitätskriterium. Wenn die Zeit zu knapp ist: Peer-Präsentation um fünf Minuten verkürzen und diese Zeit für Canvas-Vervollständigung nutzen.

Diskussionsfragen für Peer-Präsentations-Phase:

„Welcher der präsentierten Agenten hätte in Ihrer Organisation den höchsten sofortigen Impact?”

„Was war die häufigste Herausforderung beim Bauen in diesem Raum — und was sagt das über unsere Lernkurve aus?”

„Wer hat entschieden, Weg A zu nehmen, obwohl Weg B technisch möglich gewesen wäre — und warum war das die richtige Entscheidung?”

Abschluss-Reflexion (5 Minuten nach den Peer-Präsentationen):

Das Modul schließt mit drei Fragen in der Gruppe oder allein: 1. „Was nehmen Sie als konkreten nächsten Schritt aus diesem Modul mit?” 2. „Was war das wichtigste konzeptionelle Aha-Erlebnis aus Modul 7?” 3. „Was fehlt Ihnen noch — was brauchen Sie, um den nächsten Schritt tatsächlich zu gehen?”

Die Antworten auf Frage 3 sind wertvoll für Folge-Trainingsplanung und für die Vorbereitung auf organisatorische Anforderungen nach dem Training.

Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Weg A (Custom GPT / Claude Project). Fokus auf Phase 2 (Systemanweisung). Canvas bis Feld 5 (Freigabe-Klassifikation) — der Rest als Hausaufgabe. - Power-User: Weg B (n8n oder Power Automate). Vollständiger Canvas. Zusatzaufgabe: Bauen Sie den Agenten so, dass er nach dem Lab in der Praxis einsetzbar ist — mit einer realen Wissensbasis und echten Datenquellen.

Trainer-Rollenwechsel in der Lab-Phase: Während der 28-minütigen Bau-/Testphase wechselt der Trainer von der Frontal-Trainerrolle in die Coach-Rolle. Ziel: Jeden Teilnehmenden einmal individuell besuchen, eine gezielte Frage stellen oder einen konkreten Impuls geben. Häufig reicht ein Satz: „Haben Sie schon getestet, was passiert, wenn der Input unvollständig ist?” Das reicht aus, um die Testphase anzustoßen.

Materialliste: Agent-Canvas-Template ausgedruckt (A4 oder A3, Felder 1–8 als Formular); Tool-Zugangs-Check im Voraus (Custom GPT / Claude / n8n / Power Automate); Qualitätskriterien-Checkliste als Referenz für Selbstbewertung; Peer-Präsentations-Uhr (Timer sichtbar im Raum).

Modul-Abschluss-Statement (optionaler Schlusspunkt für den Trainer):

„Modul 7 hat Ihnen die Sprache, die Konzepte und — durch die Praxis heute — das erste eigene Artefakt gegeben. KI-Agenten sind kein Hype und keine Zukunftsmusik — sie sind werkzeugfähige Technologie, die mit den richtigen Designentscheidungen heute zuverlässig, nachvollziehbar und wirtschaftlich eingesetzt werden kann. Das, was Sie in den letzten zwölf Einheiten erarbeitet haben, ist keine theoretische Grundlage — es ist ein anwendbares Kompetenzprofil. Was Sie damit machen, entscheidet sich jetzt.”

Ende Modul 7 — Automatisierung und KI-Agenten (UE 73–84)

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.