KI in der Lehre: Von LLMs zu Agentic AI
Ein Erfahrungsbericht aus einer Vorlesung, in der Modellverständnis, Infrastruktur und Governance zusammenkommen.
Warum Agentic AI in der Lehre gerade jetzt wichtig ist
Die Diskussion über generative KI hat sich in kurzer Zeit verschoben. Noch vor nicht allzu langer Zeit stand oft die Frage im Mittelpunkt, ob ein großes Sprachmodell überhaupt brauchbare Antworten liefern kann. Heute ist diese Frage in vielen Kontexten längst entschieden. Die spannendere und anspruchsvollere Frage lautet: Wie werden aus einzelnen Modellaufrufen verlässliche Systeme, die in realen Arbeitsabläufen funktionieren?
Genau an dieser Stelle beginnt das Feld der Agentic AI. Ein LLM ist dann nicht mehr das gesamte Produkt, sondern ein Teil eines größeren Systems aus Werkzeugen/Tools, Speicher/Memory, Routing-Logik, Datenzugriff, Rollenmodell und Sicherheitsregeln. Wer solche Systeme entwirft oder betreibt, braucht deshalb mehr als Prompt-Engineering. Man braucht Architekturverständnis, Fehlertoleranz, Urteilskraft und die Fähigkeit, zwischen Modelllogik und Systemlogik sauber zu unterscheiden.
Für die Lehre folgt daraus eine klare Konsequenz. Wenn wir Studierende auf die Praxis vorbereiten wollen, müssen wir den Fokus verschieben: weg von isolierten Demonstrationen, hin zu vernetzten Systemen unter realen Randbedingungen. Es reicht nicht, ein Modell dazu zu bringen, eine gute Antwort zu generieren. Man muss verstehen, was vor und nach dem Modell passiert. Welche Daten kommen hinein? Welche Regeln begrenzen den Handlungsspielraum? Welche externen Abhängigkeiten können ausfallen? Welche Sicherheitsfragen entstehen, sobald ein Workflow von innen nach außen offen ist?
Mein Kurs zu AI Agents im Wintersemester war genau als solche Lernumgebung angelegt, im Masterstudiengang Digital Business and Innovation Management an der Münster School of Business (MSB) der FH Münster. Rückblickend zeigt sich vor allem eines: Die spannendsten Lerneffekte entstanden dort, wo didaktische Entscheidungen, Infrastruktur und Prüfungsformat konsequent aufeinander abgestimmt waren – getragen von studentischen Projekten.
- Agentic AI bezeichnet den Ansatz / das Paradigma, LLMs als Teil eines Systems zu nutzen, das über Tools, Memory, Orchestrierung und Guardrails Aufgaben in Workflows bearbeiten kann.
- AI Agents sind die konkreten Systeme/Implementierungen dieses Ansatzes – also ein bestimmter Agent (oder ein Agentenverbund) mit definierten Rollen, Fähigkeiten, Schnittstellen und Regeln.
Kurz:
- Agentic AI = Konzept & Designprinzip
- AI Agents = Instanzen/Artefakte, die daraus gebaut werden
Kursziel und didaktischer Anspruch
Der Kurs hatte ein bewusst praktisches Kursziel: Studierende sollen nicht nur mit einem Modell „interagieren“, sondern Agenten als Systeme entwerfen, implementieren und kritisch prüfen können. Didaktisch bedeutete das, dass wir Theorie immer dann vertieft haben, wenn sie in einem realen Workflow unmittelbar gebraucht wurde – und dass wir typische Bruchstellen (Kontextgrenzen, Tool-Fehler, Datenqualität, Sicherheitsanforderungen) nicht wegabstrahiert, sondern absichtlich in die Lernumgebung hineingeholt haben.
Aus dieser Logik ergeben sich die Lernziele: Sie kombinieren (1) LLM-Grundlagen als begriffliches Fundament, (2) agentische Muster wie Loop, Tool-Nutzung, Memory und Routing als Bausteine, und (3) Infrastruktur- und Governance-Fragen als Realitätstest für robuste Prototypen.
Lernziele der Vorlesung
- Verstehen zentraler LLM-Grundlagen: Tokenisierung, Embeddings, Attention, Kontextgrenzen und Halluzinationsrisiken.
- Einordnen, wann und warum Mitigationsansätze wie RAG, Tool-Nutzung und Orchestrierung sinnvoll sind.
- Entwerfen und Umsetzen eines grundlegenden Agenten-Loops (Input, Reasoning, Action/Output).
- Implementieren mindestens einer erweiterten Fähigkeit (Tools, Memory oder Retrieval).
- Modellieren expliziter Orchestrierungslogik (Routing, Planung, Delegation, Sequenzierung).
- Berücksichtigen von Governance und Guardrails (Constraints, Risiko- und Kontrolllogik).
- Arbeiten mit realer technischer Infrastruktur (VM-basiertes Setup, n8n-Workflows, Integrationsgrenzen).
- Kritisches Bewerten von Prototypen und begründetes Kommunizieren von Architekturentscheidungen, Grenzen und nächsten Schritten.
In der Agenten-Praxis taucht „Loop“ in unterschiedlichen Bedeutungen auf:
Agentischer Kontrollzyklus (im Agenten-Design) Das ist das konzeptionelle Muster Observe/Input → Reason/Plan → Act (Tool/Output) → Evaluate/Feedback → Stop.
Entscheidend sind Rückkopplung und Abbruchkriterien (Ziel erreicht, Budget/Timeout, Unsicherheit, Human-in-the-loop, Fehlerfall).Runner-/Orchestrator-Loop (in der Ausführung) Das ist die technische Steuerlogik, die Modellaufrufe, Tool-Calls, Retries, Logging, Rate-Limits und Policies koordiniert.
“Ralph Wiggum Loop”1 (aus dem Agentic-Coding-Umfeld) Eine externe Dauerlauf-/Bash-Loop-Technik, die einen Coding-Agent wiederholt startet bzw. iterativ weiterlaufen lässt, bis ein Completion-Signal erfüllt ist („Ralph is a Bash loop“).
Hier meinen wir mit „Loop“ primär (1) als Designprinzip und (2) als Ausführungslogik – nicht (3) als Autonomie-Harness.
Kursdesign in einem Bild: das AI-Agent-Framework als Leitstruktur
Die Vorlesung war entlang meines AI-Agent-Frameworks strukturiert (vgl. Abbildung 1). Damit war von Beginn an klar: Im Zentrum steht nicht das Modell allein, sondern das System aus Reasoning/Planung, Tools, Memory, Orchestrierung und Governance. Das Framework diente im Semester als gemeinsame Orientierung – für die Themenfolge, die Projektarchitekturen der Teams und die Bewertung der Umsetzung.
Prüfungsformat als Lernarchitektur: vom Verständnis zur Umsetzung
Das Kursziel war zweigleisig: Erstens sollten die Studierenden zentrale Grundlagen zu LLMs und Agentensystemen verstehen. Zweitens sollten sie dieses Verständnis in einem eigenen Projekt anwenden und nachvollziehbar dokumentieren. Entscheidend war dabei nicht ein bestimmtes Tool, sondern die Qualität der Entscheidungen hinter der Umsetzung.
Entsprechend war die Projektarbeit als Lernaufgabe gebaut: Teams sollten nicht nur etwas „zum Laufen“ bringen, sondern ihr System erklären und begründen – inklusive agentischem Kontrollzyklus (Input → Reason/Plan → Action/Tool-Nutzung → Feedback/Evaluation → Stop), mindestens einer erweiterten Fähigkeit (Tools, Memory oder Retrieval), einer nachvollziehbaren Orchestrierungslogik sowie reflektierten Governance- und Guardrail-Entscheidungen.
Rückblickend hat sich dieser Anspruch als richtig erwiesen. Gleichzeitig wurde sichtbar: Nicht der Anspruch an sich entscheidet, sondern die Taktung, in der Theorie und Praxis ineinandergreifen – ob er produktiv wirkt oder als Überforderung wahrgenommen wird.
Theorie als Diagnose- und Designwerkzeug
Theorie wird in KI-Kontexten häufig als Bremse missverstanden. Im Kurs war sie vor allem ein Diagnosewerkzeug: Ohne theoretisches Fundament sieht man im Projekt oft nur Symptome. Mit Fundament erkennt man Ursachen – und kann gezielt nachjustieren. Wer LLMs als probabilistische Textmodelle verstanden hatte, konnte Halluzinationen besser einordnen. Wer Grenzen des Kontextfensters ernst nahm, traf bessere Entscheidungen bei Memory und Prompt-Strategie. Und wer Embeddings und Retrieval als technische Pipeline begriff, baute robustere Lösungen.
Gleichzeitig zeigte sich: Mitigation-Ansätze wie RAG, Tool-Calling oder Memory lösen Probleme nicht automatisch. Sie verschieben Probleme in Designfragen: Welche Quellen werden indexiert? Wie wird gechunkt? Wie werden Treffer bewertet? Wann wird ein Tool aufgerufen – und was ist eine zulässige Antwort, wenn kein belastbarer Kontext gefunden wird? Genau hier entsteht der Lerngewinn: Theorie in kurzen, präzise getakteten Schleifen, die direkt in Entwurfsentscheidungen übersetzt wird.
Technisches Setup in der Praxis
Zwei Umsetzungswege für die Teams
Die Studierenden hatten bewusst die Wahl, ihren Agenten entweder mit Python in Jupyter und passenden Libraries, mit n8n oder als Kombination aus beiden Ansätzen umzusetzen. Diese Wahlfreiheit war didaktisch wichtig, weil sie unterschiedliche technische Vorerfahrungen berücksichtigt und zugleich vergleichbare architektonische Anforderungen an alle Teams stellt.
Für den Python-Weg stand bereits eine zentral von der IT der FH bereitgestellte Jupyter-Plattform zur Verfügung, die direkt genutzt werden konnte. Für den n8n-Weg habe ich gemeinsam mit der IT der FH auf Basis der bereits existierenden zentralen Self-Service-Plattform für Lehr-VMs ein neues n8n-Angebot aufgesetzt.
Infrastruktur über VMware vRA
Die n8n-Lernumgebung lief damit über VMs in der VMware vRA Self-Service Platform. Das war didaktisch sehr wertvoll, weil es den Kurs aus der Komfortzone rein lokaler Einzelumgebungen herausgeführt hat. Studierende arbeiteten in einer Umgebung, die zentrale Eigenschaften realer Systemlandschaften abbildet: Netzgrenzen, Dienstkonfiguration, Zugriffslogik, Abhängigkeiten zwischen Infrastruktur und Anwendung.
n8n-Bereitstellung und externe Erreichbarkeit
Ich habe n8n für den Kurs initial bereitgestellt, um den Teams einen praxisnahen Zugang zu agentischen Workflows zu ermöglichen. In der ersten Phase trat allerdings ein konkretes Problem auf: Die Instanzen waren zunächst nicht extern erreichbar. Seit einem ersten Hackerangriff auf die FH Münster im Jahr 20222 wurden zusätzliche Sicherheitsmaßnahmen etabliert. Zentrale IT Dienste der FH sind seitdem nur noch intern bzw. per VPN erreichbar oder über eine 2FA geschützt. Automatisiert über eine Self-Service-Plattform bereitgestellte VMs von außen erreichbar zu machen, stellte daher eine Herausforderung dar. Für lokale Übungen ist das verkraftbar, für Integrationen mit externen Diensten oder webhook-basierte Abläufe jedoch ein klarer Engpass.
Genau an dieser Stelle war die Zusammenarbeit mit der IT-Abteilung entscheidend. Die nötigen Anpassungen wurden zeitnah umgesetzt, die externe Erreichbarkeit wurde hergestellt und stabilisiert. Das war für den Kursverlauf nicht nur hilfreich, sondern erfolgskritisch. Mehrere Projektideen wären ohne diese Unterstützung in der geplanten Form nicht umsetzbar gewesen.
Ich möchte diesen Punkt bewusst hervorheben, weil er oft unsichtbar bleibt. Gute KI-Lehre entsteht nicht allein aus guten Inhalten, sondern auch aus verlässlicher Infrastrukturarbeit im Hintergrund. Die kollegiale und lösungsorientierte Unterstützung durch die IT hat dies möglich gemacht.
Zum Lizenzrahmen gehört ebenfalls eine realistische Einordnung. Im direkten Austausch mit n8n wurde mir für den Lehrkontext bestätigt: Aktuell liegt der Schwerpunkt auf einem Curriculum-Review mit möglicher Freigabe als „n8n approved curriculum“.3 Ein formales Partnerprogramm mit Education-Lizenzierung ist angekündigt und laut n8n in Vorbereitung.4 Für Hochschulkontexte bleibt damit bis zur vollständigen Programmausrollung die Community Edition ein pragmatischer Weg, weil sich damit eine eigene, lokal oder auf eigener Infrastruktur gehostete Umgebung aufsetzen lässt.5678 Für den produktiven Einsatz mit höheren Anforderungen an Betrieb, Compliance, Support und Auditierbarkeit braucht es anschließend eine entsprechend passende Zielarchitektur und Lizenzierung.
Sicherheitsvorfall und Upgrade als Teil der Lehrrealität
Nach der externen Freischaltung trat ein weiteres Praxisproblem auf: In der im Kurs genutzten n8n-Version wurde eine konkrete Schwachstelle bekannt, CVE-2026-21858.9 Damit war klar, dass ein kurzfristiges Upgrade erforderlich war. Diese Situation kam nicht gelegen, aber sie war lehrreich.
In klassischen Lehrszenarien wird Infrastruktur oft als stabile Bühne behandelt, auf der fachliche Inhalte stattfinden. Im KI-Kontext ist diese Trennung zunehmend künstlich. Versionen ändern sich schnell, Sicherheitslagen können sich kurzfristig verschieben, und operative Entscheidungen wirken direkt auf Lernprozesse zurück.
Für den Kurs bedeutete das konkret: priorisieren, aktualisieren, prüfen, kommunizieren. Gleichzeitig mussten wir sicherstellen, dass der laufende Projektbetrieb möglichst wenig unterbrochen wird. Genau dieser Balanceakt ist Teil der Realität, mit der auch Unternehmen und öffentliche Organisationen umgehen müssen, wenn sie aktuelle AI-Tools einsetzen.
Das Meta-Learning aus diesem Abschnitt ist für mich klar: Wer moderne AI-Systeme in der Lehre nutzt, muss reale Betriebs- und Sicherheitsdynamiken als Bestandteil der didaktischen Planung akzeptieren. Nicht als Ausnahme, sondern als Normalfall.
Der Vorfall blieb kein Einzelfall: Auch nach CVE-2026-21858 wurden weitere n8n-Schwachstellen veröffentlicht (beispielsweise CVE-2026-21877, CVE-2026-21893 und CVE-2026-25052).101112
Kurz zusammengefasst zeigen die CVEs unterschiedliche, aber jeweils betriebsrelevante Angriffsflächen:
- CVE-2026-21858: Unauthentifizierter Dateizugriff über bestimmte Form-/Webhook-Workflows; damit können sensible Systeminformationen offengelegt und weitere Kompromittierungen vorbereitet werden (Fix:
1.121.0). - CVE-2026-21877: Authentifizierte Codeausführung unter bestimmten Bedingungen; in der Folge ist eine vollständige Kompromittierung der Instanz möglich (Fix:
1.121.3). - CVE-2026-21893: Command Injection bei der Installation von Community-Paketen; Angriff setzt administrative Rechte voraus (Fix:
1.120.3). - CVE-2026-25052: Unzureichende Dateizugriffskontrollen; berechtigte Workflow-Editoren können sensible Host-Dateien lesen, was bis zur Kontoübernahme eskalieren kann (Fix:
1.123.18bzw.2.5.0).
Wer Updates zu spät einspielt, geht reale Risiken ein: unautorisierter Zugriff auf Workflows und Zugangsdaten, Manipulation von Automationslogik, Datenabfluss über angebundene Systeme und längere Ausfälle durch Notfallmaßnahmen. Gerade in Agentensystemen mit externen Integrationen kann ein einzelner ungepatchter Dienst schnell zum Einfallstor für größere Folgeschäden werden.
Die Konsequenz für Lehre und Wirtschaft ist daher klar: kontinuierliches Vulnerability-Monitoring, verbindliche Patch-Fenster, testbare Rollback-Strategien und eindeutig zugewiesene Verantwortlichkeiten zwischen Fachseite, IT-Betrieb und Security.
Didaktische Anpassung im Semesterverlauf
Ausgangslage: lineare Sequenz mit Reibung
Ein weiterer wichtiger Lernpunkt betraf die Struktur des Semesters selbst. Der ursprüngliche Ablauf war stark linear geplant: zuerst Grundlagenblöcke, dann zunehmend komplexe Umsetzung. In der Praxis zeigte sich, dass diese Logik für einen Teil der Gruppe zu sprunghaft war. Die Inhalte waren fachlich richtig, aber die Anschlussfähigkeit an den jeweiligen Lernstand war nicht durchgehend optimal.
Die Rückmeldung der Studierenden war hier klar und konstruktiv. Gerade in der frühen Phase wurde teilweise Unsicherheit spürbar, wie die theoretischen Inputs mit der späteren Projektanforderung zusammenhängen. Das war kein Hinweis auf fehlende Lernbereitschaft, sondern primär auf eine Taktungsfrage.
Von linearem Ablauf zu Theorie-Praxis-Loops
Ich habe deshalb im Verlauf auf engere Theorie-Praxis-Loops umgestellt. Das bedeutete: kürzere Konzeptfenster, schnellere praktische Übersetzung, häufigere Rückkopplung in beide Richtungen. Statt längerer Inputphasen folgte auf zentrale Konzepte zeitnah ein konkreter Anwendungsschritt, inklusive gemeinsamer Fehlerdiagnose und Designdiskussion.
Der Effekt war spürbar. Der rote Faden wurde klarer, weil Theorie nicht mehr als vorgeschalteter Block wirkte, sondern als Werkzeug für die jeweils nächste Projektentscheidung. Damit hat sich die Kernthese im Kursverlauf praktisch bestätigt: Es braucht nicht weniger Theorie, sondern eine bessere Sequenzierung mit der Praxis.
Ergebnisse und Beobachtungen aus den Projekten
Ausgangspunkt: Projektauftrag und Mindestanforderungen
Die Teams sollten im Semester in Gruppen einen lauffähigen Agenten-Prototypen entwerfen, umsetzen und nachvollziehbar dokumentieren. Der Anspruch war dabei nicht, ein produktionsreifes System zu liefern, sondern eine fachlich saubere, argumentierte Architekturentscheidung entlang des im Kurs genutzten Frameworks.
Die Mindestanforderungen waren bewusst konkret formuliert: ein erkennbarer Agenten-Loop (Input, LLM-basierte Verarbeitung, Output), mindestens eine erweiterte Fähigkeit (Tools, Memory oder Retrieval), explizite Orchestrierungslogik sowie reflektierte Governance- und Guardrail-Entscheidungen. Ergänzt wurde das durch eine strukturierte Dokumentation und eine kurze Demo, damit nicht nur das Ergebnis, sondern auch die Designlogik sichtbar wird.
Vor diesem Hintergrund lassen sich die fünf von den Studierenden entwickelten Agenten besser einordnen.
Die Projektlandschaft war inhaltlich breit und methodisch interessant. Es entstanden unter anderem persönliche Assistenzagenten, RAG-basierte Wissensassistenten, gruppenorientierte Planungsagenten, ein Bewerbungsagent mit dokumentenbasierten Automatisierungsschritten und ein Agent mit Bildanalyse- und Generierungsanteilen.
Überblick über die fünf entstandenen Agenten
| Agent | Anwendungsfall | Technologie-Stack | Kernfähigkeiten |
|---|---|---|---|
| Daisy’s Tasks | Persönliche Tagesplanung und Selbstorganisation | Python, Azure OpenAI, Telegram, Google Calendar API, Notion API, OpenWeatherMap | Tagesbriefing, priorisierte Aufgabenplanung, kontextbezogene Empfehlungen, Reflexions-Loop mit Memory |
| Arrango | Gruppenplanung von Aktivitäten | n8n, OpenAI GPT-4o, Telegram, Google Sheets, Google Calendar, OpenWeatherMap, Serper, Tavily | Präferenzaggregation im Chat, kontextabhängige Vorschläge, Terminabgleich, Planumsetzung in Kalenderlogik |
| DigiBIM Assistant | Studiengangsbezogener Wissensassistent | n8n (mit LangChain-basierten Agent-/Retriever-Komponenten), Azure OpenAI (GPT-4o + Embeddings), PostgreSQL/PGVector | Dokumenten-Ingestion, semantisches Retrieval, dokumentengebundene Antworten, kontextfähiger Dialog |
| AI Job Application Agent | Unterstützung im Bewerbungsprozess | n8n, OpenAI GPT-4o-mini, Apify, Telegram, Google Docs/Sheets/Drive, Gmail API | Job-Suche und -Scoring, CV-/Anschreiben-Anpassung, agentische Orchestrierung, E-Mail-Draft-Erstellung |
| StyleMyClothes | Outfit-Generierung und Nachhaltigkeitsimpulse | n8n, Telegram, Google Drive/Sheets, Gemini, Nano-Banana (fal.ai) | Bildbasierte Item-Analyse, Prompt-Konstruktion, Outfit-Bildgenerierung, markenbezogene Nachhaltigkeitseinordnung |
Wichtig für die Einordnung: Alle gezeigten Systeme sind Prototypen aus einem Lehrkontext. Einige Teams haben für Memory und Statusverwaltung bewusst pragmatische Lösungen wie Google Sheets eingesetzt, um innerhalb des Semesters schnell testbare End-to-End-Workflows zu bauen. Für einen produktiven Betrieb müssten solche Komponenten in der Regel durch robustere Architekturbausteine ersetzt oder ergänzt werden, etwa hinsichtlich Zugriffsmodell, Datenhaltung, Monitoring, Auditierbarkeit und Ausfallsicherheit.
Einordnung des Leistungsumfangs
In der Gesamtschau war ich mit den Ergebnissen sehr zufrieden: Die Agenten waren überwiegend funktional, in ihrem jeweiligen Anwendungskontext sinnvoll und gut dokumentiert. Architektur und Orchestrierung wurden in den meisten Abgaben klar und nachvollziehbar beschrieben.
Ein quantitativer Blick zeigt zudem, dass der tatsächliche Umsetzungsumfang erheblich war:
- 4 von 5 Abgaben wurden mit n8n umgesetzt, eine mit Python.
- Über diese vier n8n-Projekte hinweg wurden insgesamt 171 Workflow-Nodes und 23 unterschiedliche Service-Integrationen eingesetzt.
- Die Python-basierte Abgabe umfasste rund 1.600 Zeilen Code.
Diese Größenordnung ist nicht als Selbstzweck relevant, sondern als Hinweis auf die praktische Tiefe der Arbeiten: Die Teams haben nicht nur punktuelle Demos gebaut, sondern vollständige, integrierte Agentenabläufe.
Projektsteckbriefe im Detail
Daisy’s Tasks (Personal Assistant)
Dieser Agent adressiert ein klassisches Planungsproblem im Studienalltag: Kalender, Aufgaben und Belastung laufen in getrennten Systemen. Technisch wurde ein Python-Ansatz mit Azure-LLM, Telegram sowie Kalender- und Notion-Anbindung umgesetzt. Agentisch wird die Lösung durch tägliche Priorisierung plus strukturierte Abendreflexion, die als Kontext in die nächste Planung zurückfließt. Für einen produktiven Einsatz wären vor allem robustere Nutzer-, Rechte- und Sicherheitsmodelle nötig.
Arrango (Group Planning Agent)
Arrango fokussiert auf koordinative Reibung in Gruppen: viele Chat-Nachrichten, aber wenig belastbare Entscheidungen. In n8n kombiniert der Agent Chat-Interaktion, Präferenzspeicher, Wetter-/Websuche und Kalenderlogik. Besonders hilfreich war die Trennung zwischen passivem Präferenzsammeln und aktivem Planungsmodus bei explizitem Trigger durch die Gruppe. Für den Dauerbetrieb müsste die aktuell pragmatische Speicher- und Rechtearchitektur ausgebaut werden.
DigiBIM Assistant (RAG Knowledge Agent)
Der DigiBIM Assistant adressiert Informationssuche im Studiengangsumfeld, bei der Inhalte über viele Dokumente verteilt sind. Das Team hat eine n8n-basierte RAG-Architektur mit Embeddings und PGVector umgesetzt, inklusive Ingestion und Retriever-Logik (vgl. Abbildung 2). Besonders überzeugend war die konsequent dokumentengebundene Antwortstrategie, die Halluzinationsrisiken sichtbar reduziert. Nächste Schritte Richtung Produktion wären vor allem Versionierung, Datenpflege und Monitoring der Retrieval-Qualität.
AI Job Application Agent (Search + Document Automation)
Dieser Agent bildet eine komplette Bewerbungsprozesskette ab: Suche, Matching, Auswahl, CV-/Anschreiben-Anpassung und E-Mail-Draft-Erstellung. Die n8n-Umsetzung mit klar getrennten Teilschritten (Scraping, Matching, Dokumentgenerierung, Versandvorbereitung) zeigt sehr anschaulich agentische Orchestrierung in der Praxis (Abbildung 3, Abbildung 4). Aus Lehrsicht war vor allem die Aufteilung in dedizierte Rollen für Routing, Matching und Textgenerierung stark. Für den produktiven Einsatz wären Datenqualität, rechtliche Einordnung und robustes Fehlerhandling die zentralen Punkte.
StyleMyClothes (Vision + Generative Output)
StyleMyClothes kombiniert Bildanalyse, Prompt-Konstruktion und generative Ausgabe in einem n8n-Workflow. Der alltagsnahe Use Case: Kleidungsstücke hochladen, kombinieren, visualisieren und um Nachhaltigkeitsinformationen ergänzen. Didaktisch wertvoll war die klare modulare Trennung zwischen Datenspeicherung, visueller Interpretation, Prompt-Bau und Ausgabesynthese. Gleichzeitig wurden typische multimodale Grenzen sichtbar, etwa bei Datenqualität und Konsistenz zwischen den Schritten. Die drei Ansichten in Abbildung 5 zeigen exemplarisch den Ablauf von Item-Erfassung, Workflow-Verarbeitung und generiertem Ergebnis.
Learnings aus dem studentischen Feedback
Was gut funktioniert hat
Das qualitative Feedback der Studierenden war für die Nachjustierung des Kurses sehr hilfreich. Positiv hervorgehoben wurden insbesondere die Praxisnähe der Projekte, der Zukunftsbezug der Inhalte, die gute Erreichbarkeit bei Fragen und die sichtbare Bereitschaft zur Anpassung im Semesterverlauf.
Mehrere Rückmeldungen betonten ausdrücklich, dass die Umstellung auf n8n als praktischer Zugang geholfen hat, weil damit schneller sichtbare Ergebnisse erzielt und theoretische Konzepte besser greifbar wurden. Ebenso wurde die Projektarbeit als motivierend beschrieben, gerade weil sie über den Kurs hinaus anschlussfähig an reale Anwendungskontexte ist.
Wo nachgeschärft werden muss
Gleichzeitig enthielt das Feedback wichtige Hinweise auf Verbesserungsbedarf. Gewünscht wurde unter anderem, die erste Kursphase stärker entlang des späteren Assignments zu strukturieren, den Übergang von Grundlagen zu Umsetzung früher zu begleiten und Theorie- und Übungsanteile noch klarer zu segmentieren.
Ein wiederkehrender Punkt war außerdem die Frage nach belastbarer Evidenz für Robustheit und Performance: Viele Teams haben schlüssig beschrieben, was ihr System tun soll, aber deutlich seltener systematisch nachgewiesen, wie zuverlässig es unter Last, bei Fehlerfällen oder bei variierenden Eingaben tatsächlich arbeitet. Genau hier liegt der nächste Reifegrad zwischen funktionsfähigem Prototyp und belastbarer Lösung.
Learnings für die Umsetzung in Unternehmen
Die Erfahrungen aus dem Kurs lassen sich auch jenseits der Hochschule nutzen. Gerade weil die Teams prototypisch gearbeitet haben, wurden Muster sichtbar, die in Unternehmen sehr ähnlich auftreten:
Prototypen entstehen schnell, belastbare Systeme deutlich langsamer.
Mit aktuellen Tools lassen sich in kurzer Zeit überzeugende Demos bauen. Der Aufwand steigt aber stark, sobald Verlässlichkeit, Wiederholbarkeit und Verantwortung dazukommen. Der Übergang von einer funktionierenden Demo zu einem belastbaren System ist kein Feinschliff, sondern ein eigener Entwicklungsschritt.Der Engpass liegt selten im Modell, sondern in Daten und Prozesslogik.
In fast allen Projekten war nicht das LLM selbst der limitierende Faktor, sondern die Qualität der Datenflüsse, die Definition von Zuständigkeiten zwischen Komponenten und die Robustheit der Schnittstellen. Unternehmenskontexte verstärken genau diese Punkte: heterogene Daten, historisch gewachsene Prozesse und Integrationsabhängigkeiten.Governance ist kein Abschlusskapitel, sondern die eigentliche Kernarbeit.
Das technische Bauen ist oft der schnellere Teil, Governance der schwierigere. Sobald Agenten auf produktionsnahe Daten, externe Tools oder Kommunikationskanäle zugreifen, müssen Rollen, Freigaben, Protokollierung, Eskalationspfade und Grenzen des autonomen Handelns präzise definiert sein. Wer das erst am Ende ergänzt, baut teuer um.Orchestrierung entscheidet über Robustheit und Kosten.
Die Qualität eines Agentensystems hängt stark an der Steuerlogik: Wann wird welches Tool genutzt, welche Prüfungen passieren vor und nach dem Modellaufruf, wann wird auf den Menschen zurückgeroutet? Gute Orchestrierung erhöht nicht nur Stabilität, sondern reduziert auch unnötige Modellaufrufe und damit Betriebskosten.Betrieb und Sicherheit sind Teil des Produkts.
Der Umgang mit externer Erreichbarkeit, Versionierung und kurzfristigen Sicherheitsupdates hat gezeigt: Ein Agentensystem ist nie nur eine Modellintegration. Es ist immer auch Betrieb. Unternehmen brauchen deshalb früh ein Betriebsmodell für Patches, Monitoring, Fehlerbehandlung und Verantwortlichkeiten zwischen Fachseite, IT und Security.Pragmatismus ist sinnvoll, wenn die Zielarchitektur klar bleibt.
Im Prototyping sind pragmatische Bausteine legitim, etwa einfache Speicherlösungen für schnellen Lernfortschritt. Entscheidend ist, dass diese Entscheidungen als temporär markiert und mit einem klaren Migrationspfad hinterlegt werden. Sonst wird aus einem guten Prototyp schnell technischer Ballast.
Was sich bewährt hat – und warum
Für mich ist nach diesem Semester vor allem eines klar geworden: Der Kurs darf theoretisch anspruchsvoll bleiben – aber Theorie muss noch stärker als Taktgeber funktionieren. Nicht als Block am Anfang und nicht als Hintergrundfolie, sondern als präzise platzierte Erklärung genau dann, wenn sie den nächsten Praxisschritt ermöglicht.
Im Rückblick waren es weniger einzelne Tools oder Frameworks, die über Lernerfolg entschieden haben, sondern die Qualität der Lernarchitektur: ein stabiler technischer Startpunkt, frühe kleine Bausteine mit klarer Verbindung zur späteren Projektlogik, und eine Transparenz der Bewertung, die nicht erst am Ende relevant wird. Ebenso wichtig: Betrieb, Sicherheit und externe Abhängigkeiten sind kein „Add-on“, sondern Teil der eigentlichen Systemkompetenz. Sobald ein Workflow nach außen offen ist, wird genau dort sichtbar, ob ein Agentensystem robust gedacht ist oder nur lokal funktioniert.
Der zentrale Punkt bleibt dabei unverändert: Gute Lehre zu Agentic AI entsteht nicht durch den Verzicht auf Theorie, sondern durch die richtige Reihenfolge. Theorie wirkt dann nicht bremsend, sondern wie ein Werkzeugkasten zur Diagnose und zum Entwurf – sie erklärt, warum ein System scheitert, und zeigt, wo man es gezielt stabilisieren kann.
Wenn ich das Semester in einem Satz verdichten soll, dann so: Die besten Lernmomente entstanden dort, wo Modellverständnis, Systemdesign, Betrieb und Sicherheit gleichzeitig sichtbar wurden.
Fußnoten
https://www.heise.de/news/Cyberangriff-auf-Fachhochschule-Muenster-gefaehrdet-anstehende-Pruefungsphase-7149323.html↩︎
n8n Curriculum Review Form („n8n approved curriculum“): https://forms.n8n.io/edu-partner-curriculum-form↩︎
Persönliche E-Mail-Kommunikation mit n8n (März 2026).↩︎
n8n Docs, Self-Hosting: https://docs.n8n.io/hosting/↩︎
n8n Docs, Sustainable Use License: https://docs.n8n.io/reference/license/↩︎
n8n Pricing (Hinweis auf Community Edition / self-hosted): https://n8n.io/pricing/↩︎
n8n Community, Hinweise auf Self-Hosting im Ausbildungskontext: https://community.n8n.io/t/n8n-cloud-student-plan/16041, https://community.n8n.io/t/extended-student-access-inquiry/153785↩︎
CVE-Record zu CVE-2026-21858 (cve.org), NVD-Eintrag und n8n Advisory (GHSA-v4pr-fm98-w9pg): https://www.cve.org/CVERecord?id=CVE-2026-21858, https://nvd.nist.gov/vuln/detail/CVE-2026-21858, https://github.com/n8n-io/n8n/security/advisories/GHSA-v4pr-fm98-w9pg↩︎
NVD-Eintrag zu CVE-2026-21877 und n8n Advisory (GHSA-v364-rw7m-3263): https://nvd.nist.gov/vuln/detail/CVE-2026-21877, https://github.com/n8n-io/n8n/security/advisories/GHSA-v364-rw7m-3263↩︎
NVD-Eintrag zu CVE-2026-21893 und n8n Advisory (GHSA-7c4h-vh2m-743m): https://nvd.nist.gov/vuln/detail/CVE-2026-21893, https://github.com/n8n-io/n8n/security/advisories/GHSA-7c4h-vh2m-743m↩︎
NVD-Eintrag zu CVE-2026-25052 und n8n Advisory (GHSA-gfvg-qv54-r4pc): https://nvd.nist.gov/vuln/detail/CVE-2026-25052, https://github.com/n8n-io/n8n/security/advisories/GHSA-gfvg-qv54-r4pc↩︎