AI in Teaching: From LLMs to Agentic AI
An experience report from a lecture where model understanding, infrastructure, and governance come together.
Why Agentic AI Matters in Teaching Right Now
The conversation around generative AI has shifted quickly. Not long ago, the central question was whether a large language model could produce useful responses at all. In many contexts, that question has already been settled. The more relevant and more demanding question now is: How do individual model calls become reliable systems that hold up in real workflows?
That is exactly where Agentic AI begins. An LLM is no longer the whole product, but one component in a broader system of tools, memory, routing logic, data access, role models, and security constraints. Designing and operating such systems requires more than prompt engineering. It requires architectural thinking, fault tolerance, judgment, and the ability to distinguish model logic from system logic.
For teaching, the implication is straightforward. If we want to prepare students for practice, we need to shift the focus: away from isolated demonstrations and toward connected systems under real constraints. It is not enough to produce a good model response. We need to understand what happens before and after the model call. Which data enters the system? Which rules constrain behavior? Which dependencies can fail? Which security issues appear once a workflow becomes externally reachable?
My AI Agents course in the winter semester was designed as exactly this kind of learning environment, in the Master’s program Digital Business and Innovation Management at the Münster School of Business (MSB) at FH Münster. In hindsight, one thing stands out: the strongest learning effects happened where didactic decisions, infrastructure, and assessment design were tightly aligned and tested in student projects.
- Agentic AI refers to the approach / paradigm of using LLMs as part of systems that combine tools, memory, orchestration, and guardrails to solve tasks in workflows.
- AI Agents are the concrete implementations of that approach, i.e. specific agent systems with defined roles, capabilities, interfaces, and rules.
In short:
- Agentic AI = concept and design principle
- AI Agents = concrete system instances built from that principle
Course Goals and Didactic Intent
The course had a deliberately practical goal: students should not only “interact” with a model, but design, implement, and critically assess agents as systems. Didactically, that meant theory was deepened exactly when it was needed in a real workflow, and typical breakpoints (context limits, tool errors, data quality issues, security requirements) were not abstracted away but intentionally included in the learning environment.
This logic shaped the learning goals: (1) LLM fundamentals as conceptual grounding, (2) agentic patterns such as loops, tool use, memory, and routing as building blocks, and (3) infrastructure and governance topics as a reality check for robust prototypes.
Lecture Learning Objectives
- Understand core LLM foundations: tokenization, embeddings, attention, context limits, and hallucination risks.
- Assess when and why mitigation patterns such as RAG, tool usage, and orchestration are needed.
- Design and implement a basic agent loop (input, reasoning, action/output).
- Implement at least one advanced capability (tools, memory, or retrieval).
- Model explicit orchestration logic (routing, planning, delegation, sequencing).
- Account for governance and guardrails (constraints, risk and control logic).
- Work with real technical infrastructure (VM-based setup, n8n workflows, integration boundaries).
- Critically evaluate prototypes and justify architectural decisions, limits, and next steps.
In agent practice, “loop” can mean different things:
Agent control cycle (agent design level) The conceptual pattern Observe/Input → Reason/Plan → Act (Tool/Output) → Evaluate/Feedback → Stop. The key elements are feedback and stop criteria (goal reached, budget/timeout, uncertainty, human-in-the-loop, error case).
Runner/orchestrator loop (execution level) The technical control logic coordinating model calls, tool calls, retries, logging, rate limits, and policies.
“Ralph Wiggum Loop”1 (from agentic coding practice) An external bash loop harness that repeatedly starts a coding agent until a completion condition is met (“Ralph is a Bash loop”).
In this course, “loop” primarily means (1) as design principle and (2) as execution logic, not (3) as an autonomy harness.
Course Design in One Figure: The AI Agent Framework as Guiding Structure
The lecture was structured around my AI Agent Framework (see Figure 1). From the start, this made one point explicit: the center is not the model alone, but the system of reasoning/planning, tools, memory, orchestration, and governance. The framework served as a shared reference for topic sequencing, team architectures, and assessment.
Assessment Design as Learning Architecture: From Understanding to Implementation
The course goal was dual. First, students should understand core LLM and agent-system concepts. Second, they should apply and document that understanding in a team project. The decisive criterion was never a specific tool, but the quality of decisions behind the implementation.
Accordingly, the project task was designed as a learning architecture: teams were expected not only to make something run, but to explain and justify their system, including a recognizable control loop (Input → Reason/Plan → Action/Tool Use → Feedback/Evaluation → Stop), at least one advanced capability (tools, memory, or retrieval), explicit orchestration logic, and reflected governance and guardrail decisions.
In hindsight, this expectation was right. At the same time, one thing became clear: success depends less on ambition itself than on sequencing, i.e. whether theory and practice are paced in a way that is productive rather than overwhelming.
Theory as a Diagnostic and Design Tool
Theory is often misunderstood as a brake in AI teaching. In this course, it functioned primarily as a diagnostic tool: without theory, teams mostly saw symptoms; with theory, they could identify causes and adjust deliberately. Students who understood LLMs as probabilistic text models could classify hallucinations better. Students who took context limits seriously made better memory and prompt decisions. Students who treated embeddings and retrieval as pipelines, not magic, built more robust systems.
At the same time, mitigation patterns such as RAG, tool calling, or memory do not solve problems automatically. They move problems into design questions: Which sources are indexed? How is chunking done? How are hits evaluated? When is a tool called, and when not? What is an acceptable answer if no reliable context is available? That is where the learning gain happens: theory in short, tightly sequenced loops directly translated into design decisions.
Technical Setup in Practice
Two Implementation Paths for Teams
Students had a deliberate choice: build their agent with Python in Jupyter and libraries, with n8n, or with a hybrid approach. This flexibility was didactically important because it accommodated different technical backgrounds while keeping architectural expectations comparable across teams.
For the Python path, a centrally provided FH IT Jupyter platform was already available and could be used immediately. For the n8n path, I set up a new offering together with FH IT on top of the existing self-service VM platform for teaching.
Infrastructure via VMware vRA
The n8n environment ran on VMs via the VMware vRA self-service platform. Didactically, this was valuable because it moved teams beyond purely local setups. Students worked in an environment reflecting key properties of real system landscapes: network boundaries, service configuration, access logic, and infrastructure-application dependencies.
n8n Provisioning and External Reachability
I initially provisioned n8n for the course to provide hands-on access to agentic workflows. In the first phase, however, instances were not externally reachable. Since the first major cyberattack on FH Münster in 2022, additional security measures have been in place.2 Core IT services are therefore generally internal-only, VPN-based, or protected with additional controls. Making automatically provisioned self-service VMs reachable from outside was therefore challenging. For local exercises this is manageable; for webhook and external API integrations it is a critical bottleneck.
This is where collaboration with IT was decisive. The required adjustments were implemented quickly, external reachability was established and stabilized, and project continuity was preserved. Several project ideas would not have been feasible in their final form without this support.
I want to highlight this explicitly because it often remains invisible. High-quality AI teaching depends not only on content quality but also on reliable infrastructure work in the background. The collegial, solution-oriented IT support made that possible.
Licensing also required realistic framing. In direct exchange with n8n, I received confirmation that the current focus for education is curriculum review with possible recognition as “n8n approved curriculum”.3 A formal partner program with education licensing has been announced and is in preparation.4 Until that program is fully available, the community edition remains a pragmatic path in higher education, since it can be self-hosted in local or institution-managed infrastructure.5678 For production use with stronger requirements around operations, compliance, support, and auditability, a corresponding target architecture and licensing model are required.
Security Incident and Upgrade as Part of Teaching Reality
After external reachability was established, another practical issue emerged: the n8n version used in the course was affected by CVE-2026-21858.9 A short-notice upgrade was therefore necessary. The timing was inconvenient, but the experience was instructive.
In traditional teaching settings, infrastructure is often treated as a stable stage on which content happens. In AI contexts, that separation is increasingly artificial. Versions change quickly, security situations shift, and operational decisions directly affect learning processes.
For the course, this meant prioritizing, updating, checking, and communicating while minimizing disruption to running projects. That balancing act is exactly what organizations also face when using current AI tooling.
The meta-learning is clear: if you teach with modern AI systems, real operational and security dynamics are not exceptions; they are part of the normal planning baseline.
After CVE-2026-21858, additional n8n vulnerabilities were published (including CVE-2026-21877, CVE-2026-21893, and CVE-2026-25052).101112
In short, these CVEs point to different but operationally relevant attack surfaces:
- CVE-2026-21858: Unauthenticated file access in specific form/webhook constellations, potentially exposing sensitive system information (fix:
1.121.0). - CVE-2026-21877: Authenticated code execution under certain conditions, with potential full instance compromise (fix:
1.121.3). - CVE-2026-21893: Command injection during community package installation, requiring administrative rights (fix:
1.120.3). - CVE-2026-25052: Insufficient file-access controls, potentially enabling escalation up to account takeover (fix:
1.123.18or2.5.0).
Delayed updates increase real risks: unauthorized workflow/data access, manipulation of automation logic, data leakage through connected systems, and outages due to emergency response.
The practical consequence is clear: continuous vulnerability monitoring, fixed patch windows, testable rollback strategies, and explicit ownership across domain teams, IT operations, and security.
Didactic Adjustments During the Semester
Initial Situation: Linear Sequence with Friction
Another key learning concerned the course structure itself. The initial plan was strongly linear: first fundamentals, then increasingly complex implementation. In practice, this pacing was too abrupt for part of the cohort. Content quality was not the issue; sequencing and transfer were.
Student feedback here was clear and constructive. Especially in the early phase, uncertainty appeared around how theoretical input mapped to later project requirements. This was not a motivation issue, but mostly a pacing issue.
From Linear Sequence to Theory-Practice Loops
During the semester, I shifted to tighter theory-practice loops: shorter concept windows, faster practical translation, and more frequent feedback in both directions. Instead of long input blocks, key concepts were followed quickly by targeted application steps, including joint error diagnosis and design discussion.
The effect was visible. The narrative became clearer because theory no longer felt like a front-loaded block, but like a tool for the next project decision. This confirmed the core thesis in practice: not less theory, but better sequencing of theory and practice.
Results and Observations from Student Projects
Starting Point: Assignment and Minimum Requirements
Teams were asked to design, implement, and document a working agent prototype in groups. The goal was not production readiness, but a coherent, argued architecture aligned with the framework used in class.
Minimum requirements were explicit: a recognizable agent loop (input, LLM-based processing, output), at least one advanced capability (tools, memory, or retrieval), explicit orchestration logic, and reflected governance/guardrail decisions. Structured documentation and a short demo ensured that both outcomes and design reasoning were visible.
Against this backdrop, the five resulting agents can be assessed more clearly.
The project landscape was broad and methodologically interesting: personal assistance, RAG-based knowledge assistance, group planning, application workflow automation, and multimodal outfit generation.
Overview of the Five Student Agents
| Agent | Use Case | Technology Stack | Core Capabilities |
|---|---|---|---|
| Daisy’s Tasks | Personal daily planning and self-organization | Python, Azure OpenAI, Telegram, Google Calendar API, Notion API, OpenWeatherMap | Daily briefing, prioritized task planning, contextual recommendations, reflection loop with memory |
| Arrango | Group activity planning | n8n, OpenAI GPT-4o, Telegram, Google Sheets, Google Calendar, OpenWeatherMap, Serper, Tavily | Preference aggregation in chat, context-based suggestions, scheduling logic |
| DigiBIM Assistant | Study-program knowledge assistant | n8n (with LangChain-based agent/retriever components), Azure OpenAI (GPT-4o + embeddings), PostgreSQL/PGVector | Document ingestion, semantic retrieval, document-grounded responses, contextual dialog |
| AI Job Application Agent | Application process support | n8n, OpenAI GPT-4o-mini, Apify, Telegram, Google Docs/Sheets/Drive, Gmail API | Job search/scoring, CV/cover-letter adaptation, agentic orchestration, email draft generation |
| StyleMyClothes | Outfit generation and sustainability cues | n8n, Telegram, Google Drive/Sheets, Gemini, Nano-Banana (fal.ai) | Image-based item analysis, prompt construction, outfit image generation, brand-related sustainability context |
Important context: all systems are prototypes in a teaching setting. Some teams intentionally used pragmatic components such as Google Sheets for state/memory to build testable end-to-end workflows within the semester. For production use, these parts would typically need stronger architecture regarding access models, data handling, monitoring, auditability, and reliability.
Scope of Implementation Work
Overall, I was very satisfied with the outcomes: most agents were functional, useful in their context, and well documented. In most submissions, architecture and orchestration were explained clearly.
A quantitative view also shows that implementation depth was substantial:
- 4 of 5 submissions were implemented with n8n, one with Python.
- Across the four n8n projects, teams implemented a combined total of 171 workflow nodes and 23 distinct service integrations.
- The Python-based submission included roughly 1,600 lines of code.
These numbers are not relevant as metrics for their own sake, but as indicators of practical depth: teams built integrated agent workflows, not isolated demos.
Project Profiles in More Detail
Daisy’s Tasks (Personal Assistant)
This agent addresses a common student planning problem: calendar events, tasks, and workload live in separate systems. Technically, the team used Python with Azure LLM, Telegram, and calendar/Notion integration. The core agentic element is a daily prioritization cycle with structured evening reflection that feeds context into the next planning step. For production, stronger user, rights, and security models would be required.
Arrango (Group Planning Agent)
Arrango targets coordination friction in groups: many chat messages, few robust decisions. In n8n, the agent combines chat interaction, preference storage, weather/web search, and calendar logic. A particularly strong design choice was separating passive preference collection from active planning mode triggered explicitly by the group. For sustained operation, storage and rights architecture would need hardening.
DigiBIM Assistant (RAG Knowledge Agent)
DigiBIM Assistant addresses distributed information retrieval in the study-program context. The team implemented an n8n-based RAG architecture with embeddings and PGVector, including ingestion and retriever logic (see Figure 2). Particularly convincing was the strict document-grounded response strategy, which visibly reduced hallucination risk. Production next steps would focus on versioning, knowledge maintenance, and retrieval-quality monitoring.
AI Job Application Agent (Search + Document Automation)
This agent implements an end-to-end application pipeline: search, matching, selection, CV/cover-letter adaptation, and email draft generation. The n8n implementation with clearly separated stages (scraping, matching, document generation, send preparation) demonstrates agentic orchestration in practice (Figure 3, Figure 4). From a teaching perspective, role separation across routing, matching, and text generation was especially strong. For production use, data quality, legal framing, and robust error handling are key.
StyleMyClothes (Vision + Generative Output)
StyleMyClothes combines image analysis, prompt construction, and generative output in an n8n workflow. The user-facing case is straightforward: upload clothing items, combine and visualize looks, and add sustainability context. Didactically, the modular split between data storage, visual interpretation, prompt-building, and output synthesis was valuable. At the same time, typical multimodal limits became visible, especially around data quality and consistency across steps. The three views in Figure 5 show the flow from item capture to workflow processing and generated result.
Learnings from Student Feedback
What Worked Well
The qualitative student feedback was highly useful for iterative course improvement. Positive points included practical relevance of projects, future relevance of topics, good accessibility for questions, and visible willingness to adjust during the semester.
Several comments explicitly emphasized that the move to n8n as a practical path helped because it enabled faster visible outcomes and made theoretical concepts more tangible. Project work was also described as motivating because it connected well to real application settings beyond the course.
Where We Need to Improve
At the same time, feedback included important improvement signals. Students asked for stronger early alignment between course start and later assignment requirements, smoother transition from fundamentals to implementation, and clearer separation of theory and hands-on segments.
Another recurring point was evidence for robustness and performance: many teams explained convincingly what their system should do, but provided less systematic validation of how reliably it actually behaves under load, failure modes, or varying inputs. This is exactly the next maturity step between a functioning prototype and a robust solution.
Learnings for Organizational Implementation
The course experience also translates beyond higher education. Precisely because teams worked with prototypes, patterns emerged that closely resemble what organizations face in practice:
Prototypes are fast to build; robust systems take much longer. Current tools enable convincing demos in short time. Effort increases sharply once reliability, repeatability, and accountability matter. The step from “works once” to “works reliably” is not polishing; it is a separate phase.
Bottlenecks are rarely in the model itself, but in data and process logic. Across projects, core limits were usually data flow quality, component responsibilities, and interface robustness. Organizational contexts amplify these issues through heterogeneous data, legacy processes, and integration dependencies.
Governance is not a final chapter; it is core implementation work. Building is often faster than governing. Once agents touch production-relevant data, external tools, or communication channels, roles, approvals, logging, escalation paths, and boundaries of autonomy must be explicit. If added late, this becomes expensive rework.
Orchestration determines robustness and cost. System quality depends heavily on control logic: when tools are called, what checks happen before/after model calls, and when control routes back to a human. Good orchestration improves stability and reduces unnecessary model calls.
Operations and security are part of the product. External reachability, versioning, and short-notice security updates made one thing obvious: an agent system is never just a model integration; it is operational infrastructure.
Pragmatism is useful if target architecture remains explicit. Pragmatic choices are valid in prototyping, for example simple storage layers to accelerate iteration. What matters is to mark them as temporary and define migration paths, otherwise prototypes turn into technical debt.
What Proved Effective and Why
After this semester, one conclusion is clear to me: the course can remain theoretically demanding, but theory must act more consistently as a pacing instrument. Not as a block at the beginning and not as background framing, but as a targeted explanation exactly when it enables the next practical step.
In hindsight, success depended less on specific tools and more on learning architecture quality: a stable technical starting point, early building blocks with clear links to later project logic, and transparent assessment criteria that matter throughout the semester, not only at the end. Equally important, operations, security, and external dependencies are not add-ons; they are core system competence. As soon as workflows open outward, system robustness is tested immediately.
The central point remains unchanged: high-quality teaching for Agentic AI does not require less theory, but better sequencing of theory and practice. Then theory is not a brake, but a diagnostic and design toolkit.
If I had to summarize the semester in one sentence: the strongest learning moments happened where model understanding, system design, operations, and security became visible at the same time.
Footnotes
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↩︎
Personal email communication with n8n (March 2026).↩︎
n8n docs, self-hosting: https://docs.n8n.io/hosting/↩︎
n8n docs, sustainable use license: https://docs.n8n.io/reference/license/↩︎
n8n pricing (community/self-hosted context): https://n8n.io/pricing/↩︎
n8n community discussions on self-hosting in education context: https://community.n8n.io/t/n8n-cloud-student-plan/16041, https://community.n8n.io/t/extended-student-access-inquiry/153785↩︎
CVE record for CVE-2026-21858 (cve.org), NVD entry, and 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 entry for CVE-2026-21877 and 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 entry for CVE-2026-21893 and 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 entry for CVE-2026-25052 and 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↩︎