Agentic Loops: vom Prompten zum Multiplayer-Team aus Agents

Warum die Engineers Loops haben und Product nicht

Das Muster taucht in fast jedem Discovery-Gespräch auf, das wir dieses Jahr mit Product-Leuten geführt haben. Die Engineers haben Coding-Agents und liefern ein Ticket an einem Nachmittag. Die Produktentscheide brauchen weiterhin dieselben drei Meetings, und ein guter Teil davon erreicht das Ticket nie in einer Form, mit der ein Agent arbeiten könnte.

Agentic Loops sind die Antwort, die die Engineering-Seite für ihre Hälfte des Problems gefunden hat. Statt einen Agent zu prompten und den ersten Entwurf zu nehmen, gibst du ihm ein konkretes Ziel und lässt ihn planen, handeln, prüfen und nachjustieren, bis das Ziel erreicht ist. Die Idee war diesen Sommer auf der Engineering-Seite des Internets überall, und der Witz, der sie beerdigte, auch: «Wir reden nicht mehr über Loops. Wir reden über Graphs.»¹

Hinter dem Witz steckt eine echte Entwicklung. Jede Stufe seit 2023 hat dem Modell etwas mehr Unabhängigkeit gegeben. Dieser Beitrag geht die Stufen durch, zeigt, was sich ändert, wenn die Aufgabe keinen Compiler hat, der sie beurteilt, und argumentiert, dass die Stufe, die jetzt kommt, anders ist: Die Arbeit wandert von einer Person mit einem Agent zu einem Team.

Ich bin Mitgründer von Teklens. Davor habe ich Aioma aufgebaut und Localinas CRM an Swisscom verkauft, und ich habe an der ZHAW unterrichtet. Bei Teklens haben wir 24 Discovery-Gespräche mit Product-Leuten darüber geführt, wie ihre Teams mit KI arbeiten; das Muster im ersten Absatz stammt daraus. Die Engineering-Praxis in diesem Beitrag kommt aus den Quellen am Ende: vor allem aus einem Webinar von Nufar Gaspar im AI Daily Brief vom September 2026, einer Folge von Lenny's Podcast mit Tara Seshan, die bei OpenAI das Produkt für Codex und ChatGPT Work leitet, und den Release Notes von OpenClaw 2.0, wie sie im selben Podcast besprochen wurden.^1,2,4

Die These. Jede Stufe im Arbeiten mit KI hat Unabhängigkeit vom Menschen zum Modell verschoben. Die nächste Stufe verschiebt die Arbeit vom Einzelnen zum Team, und sie zahlt sich nur aus, wenn zwei Dinge entworfen statt vorausgesetzt werden: die Ziellinie und der geteilte Kontext.

Warum hat sich das Vokabular jedes Quartal geändert?

Weil der Gegenstand der Aufmerksamkeit gewandert ist. Prompt Engineering drehte sich darum, was du sagst. Context Engineering darum, was das Modell weiss. Harness Engineering darum, wo es läuft und welche Werkzeuge es anfassen darf. Loop Engineering darum, wie lange es allein laufen kann. Graph Engineering darum, wie viele Agents zusammenarbeiten. Gaspars Zusammenfassung der Richtung gilt für alle fünf: Jeder Schritt gibt der KI mehr Unabhängigkeit in grösserem Massstab.¹

1. Prompt Engineering. Was du sagst. Das Modell ist ein Assistent. Die Fähigkeit ist das Formulieren. Die meisten Teams haben aus dieser Zeit noch ein Dokument namens «gute Prompts».

2. Context Engineering. Was das Modell weiss. Die Fähigkeit wird, den richtigen Hintergrund zu liefern: das Repository, das Ticket, die Architekturnotizen, die Coding-Konventionen. Hier haben Produktteams die Lücke zum ersten Mal gespürt, weil der Kontext im Kopf eines Engineers nirgends stand, wo ein Agent ihn hätte lesen können.

3. Harness Engineering. Wo es läuft. Das Modell bekommt Werkzeuge, ein Dateisystem, ein Terminal, Berechtigungen. Ein Agent kann jetzt handeln, nicht nur schreiben. Jedes agentische Werkzeug, das du heute nutzt, von Claude Code über Codex bis Cursor, ist ein Harness um ein Modell.

4. Coding-Agents. Die erste agentische Loop im grossen Stil. Software war die erste Domäne, in der Loops normal wurden, aus einem Grund: Die Prüfung ist gratis. Code kompiliert oder nicht. Tests bestehen oder scheitern. Der Agent kann seine Arbeit ohne Menschen prüfen, also kann er planen, Werkzeuge nutzen, das Ergebnis anschauen, testen und überarbeiten, bis die Tests grün sind.¹

5. Loop Engineering. Wie lange es allein arbeiten kann. Der Harness fährt unter der Haube schon eine kleine Loop. Loop Engineering verlängert sie: Du definierst eine messbare Ziellinie und sagst dem Agent, er soll weitermachen, bis sie erreicht ist. In Claude Code ist das der Goal-Befehl, in Cursor der Loop-Befehl.¹

6. Graph Engineering. Wie viele zusammenarbeiten. Wenn eine Loop nicht reicht, teilst du den Job auf Agents auf, die sich Arbeit weiterreichen. Die Mechanik habe ich in Graph Engineering: Multi-Agenten-Workflows statt Chat-Ketten beschrieben; dieser Beitrag bleibt beim Warum und Wann.

Unter dem Vokabular hat sich noch etwas verändert, und es gehört zu Stufe zwei. Kontext ist nicht mehr etwas, das ein Agent bei jeder Anfrage neu zusammensetzt, sondern ein Asset, das einmal kuratiert, versioniert, mit Berechtigungen versehen und geteilt wird. Jörg Schad, VP of Engineering bei Pinecone, beschreibt ihr System Nexus als materialisierte Sicht für Kontext: ein vorberechnetes Artefakt mit eigenem Schema, Metadaten und Herkunft, sodass ein Agent auf dieselbe Frage zweimal dieselbe Antwort bekommt und ein Auditor sieht, welche Daten sie erzeugt haben. Behalte die Idee im Kopf. Sie kommt zurück, sobald das Team ins Bild tritt.³

Warum hatte Coding die Loops zuerst?

Weil eine Coding-Aufgabe ihren Schiedsrichter mitbringt. Eine Testsuite ist eine Ziellinie, die langweilig, objektiv und maschinell prüfbar ist, und langweilig ist hier ein Kompliment. Wenn der Agent fragt «bin ich fertig?», antwortet der Test-Runner.

Gaspar bringt den Punkt für alle ausserhalb des Engineerings scharf auf den Tisch: «When someone tells you, just put it on a loop, they're forgetting that they, as coders, had free verification and you don't.» Niemandes Compiler entscheidet, ob eine Spec vollständig ist, ob eine Roadmap vertretbar ist oder ob eine Release Note klar ist. Deshalb haben sich Loops im Engineering in Monaten verbreitet und erreichen die Produktarbeit erst jetzt.¹

Die praktische Konsequenz für einen Product Leader ist unbequem, aber nützlich. Die Teile der Teamarbeit, die schon einen Schiedsrichter haben, kannst du heute loopen. Die Teile ohne brauchen zuerst den Schiedsrichter, und einige davon sollten nie geloopt werden.

Wie entwirfst du eine Loop, wenn es keinen Compiler gibt?

Du erfindest den Schiedsrichter. Gaspars Methode ist eine Goal Card: ein Ziel, das verlangte Artefakt, Beurteilungs- und Stoppkriterien, die der Agent messen kann, optionale Stufen, eine Zyklen-Kappe und Grenzen für Zeit, Werkzeuge oder Sandbox. Wenn du keine überprüfbare Ziellinie schreiben kannst, ist die Aufgabe kein Loop-Kandidat.¹

Eine Aufgabe ist loop-tauglich, wenn das meiste davon zutrifft: Ein Prompt hat es nicht geschafft, obwohl du das stärkste Modell in einem Durchgang probiert hast. Der Fortschritt lässt sich prüfen, jemand oder etwas kann sagen, ob Entwurf drei besser ist als Entwurf zwei. Sie kann ohne dich laufen, über Mittag oder über Nacht, und du willst ein fertiges Ergebnis statt eines Entwurfs. Sie soll weiterlaufen, bis eine bestimmte Latte erreicht ist, nicht bis der Agent sich höflich genug fühlt aufzuhören. Und sie wird durch Wiederholung besser: mehr Quellen, weniger Lücken, mehr Testfälle, strafferer Text.

Eine Aufgabe sollte nicht geloopt werden, wenn ein Durchgang reicht, wenn dein Urteil die eigentliche Arbeit ist, wenn das Ergebnis von Geschmack oder der Freigabe einer Geschäftsleitung abhängt oder wenn es keine stabile Definition von «fertig» gibt. Gaspars Beispiele für die zweite Sorte: Kommunikation an die Geschäftsleitung, Hiring-Entscheide, Strategie. Autonomie hat keinen eigenen Geschmack.¹

Schritt 1. Das Ziel in einem maschinenlesbaren Satz. Nicht «die Spec verbessern». Sondern: «Erstelle eine Spec für den Rechnungsexport, die ein Engineer umsetzen kann, ohne eine Rückfrage zu stellen.»

Schritt 2. Das Artefakt benennen. Eine Datei, ein Ticket, eine Tabelle. «Eine Markdown-Datei am vereinbarten Pfad.»

Schritt 3. Langweilige, prüfbare Kriterien schreiben. Jedes Akzeptanzkriterium ist mindestens einem bestehenden Code-Modul zugeordnet oder als neu markiert. Jede offene Frage steht mit Owner in der Liste. Keine zwei Kriterien überlappen. Lesezeit unter sechs Minuten. Gaspars Research-Beispiel hat dieselbe Form: mehr als 200 eindeutige Datenpunkte, jeder mit URL und Datum, ein fixer Quellenmix, null Duplikate.¹

Schritt 4. Gates nur dort, wo du Kontrolle brauchst. Zum Beispiel: Stopp und Bericht nach dem ersten Entwurf, wenn mehr als drei Code-Module betroffen sind.

Schritt 5. Kappen. Maximale Zyklen, maximale Tokens oder Zeit, und eine Sandbox, in der Fehler nichts kosten. Eine Loop, die gegen dein produktives Jira läuft, ist keine Sandbox.

Schritt 6. Ein Log verlangen. Eine Zeile pro Zyklus: was geprüft, was geändert, wie weit von der Ziellinie entfernt. Wenn Loops neu für dich sind, lernst du an diesem Log, was deine Kriterien tatsächlich verlangt haben.

Loops scheitern auf vier erkennbare Arten. Die Kosten laufen davon, was die Kappe verhindert. Die Zyklen stapeln sich ohne Fortschritt, was heisst, dass die Ziellinie nicht konvergiert und du manuell stoppst. Die Loop ist fertig und das Ergebnis mittelmässig, das ist die hinterhältige Variante: Der Agent hat den Wortlaut deiner Kriterien erfüllt und deine Kriterien waren das Problem. Und die vierte: Die Aufgabe hätte nie geloopt werden sollen, weil das Urteil die Arbeit war.¹

Beachte, was der dritte Fehler lehrt. Wenn das Ergebnis deine Definition von «fertig» erfüllt und du trotzdem unzufrieden bist, schreib die Definition um, nicht die Loop. Der grösste Teil der Fähigkeit steckt in diesem Umschreiben.

Wann reicht eine Loop nicht mehr?

Wenn die Selbstprüfung zum Gummistempel wird. Gaspars fünf Signale für den Wechsel von einem Agent zu mehreren: Der Agent sagt «fertig» und du findest weiter Dinge, die er hätte sehen müssen; ein Agent trägt zu viele Hüte und der objektive Rechercheur wird zu früh kreativ; unabhängige Arbeit läuft nacheinander, obwohl sie parallel laufen könnte; die Ziellinie ändert sich mitten im Lauf, weil sie zwei Jobs versteckt; und die Qualität stagniert, egal wie du die Goal Card justierst.¹

Zwei davon verdienen die Aufmerksamkeit eines Product Leaders. Hinter dem Gummistempel-Signal steckt Evidenz: Modelle neigen dazu, sich selbst zuzustimmen, also sollte ein Prüfer idealerweise ein anderes Modell mit frischem Kontext sein, das nichts darüber weiss, wie der Entwurf entstanden ist. Und das Signal «zwei Jobs auf einer Karte» ist das, das Produktteams am häufigsten trifft, weil eine Spec mindestens zwei Jobs ist: entscheiden, was gebaut wird, und es so beschreiben, dass es gebaut werden kann.¹

Eine Loop ist bereits der kleinste Graph, ein Knoten mit einem Pfeil auf sich selbst. Ein Prüfer mit frischem Kontext macht daraus einen Graph mit zwei Knoten. Ein Research-Fan-out mit Synthesizer, Zitat-Prüfer und menschlichem Gate ist ein Graph mit sechs Knoten. Nichts davon braucht neue Werkzeuge. Du kannst es auf ein Whiteboard zeichnen, und wenn du es zeichnen kannst, kann ein agentisches Werkzeug es bauen. Gaspars Regel für alles davon: Wenn ein Agent gut arbeitet, bleib bei einem Agent. Graphs kosten Tokens und Aufmerksamkeit, und ein schöner Graph verbraucht Millionen Tokens, ohne mit der Wimper zu zucken.¹

Auf dem Weg zum Graph liegt eine Falle. Die meisten zeichnen den Graph so, wie Menschen die Arbeit heute machen, mit den Übergaben, Freigaben und Rollentrennungen, die es gibt, weil Menschen müde werden, Kontext verlieren und nicht in sechs Dingen Experten sein können. Agents haben andere Grenzen. Entwirf für den Job, der erledigt werden muss, nicht für den heutigen Prozess.¹

Warum ist die nächste Stufe Multiplayer und nicht eine grössere Loop?

Weil Loops und Graphs, wie sie bisher praktiziert werden, Single Player sind. Eine Person, ein Terminal, ein privates Gespräch mit einem Agent. Der Code, der herauskommt, wird geteilt. Der Weg dorthin bleibt in einer Session verborgen. OpenClaw-Maintainer Colin hat die Annahme in den Notizen zum 2.0-Release klar benannt: «Most developer agent workflows still assume one developer, one terminal, and one private conversation.»⁴

OpenClaw 2.0, ein Neubau von Grund auf durch 933 Beitragende in 16'000 Pull Requests, hat die geteilte Session zur wichtigsten Änderung gemacht. Teammitglieder öffnen denselben Agent-Thread, während die Arbeit läuft. Braucht der Agent eine Information, die eine Person hat, ergänzt sie diese direkt. Braucht ein Entscheid eine zweite Meinung, schauen beide auf denselben Kontext. Übergibt jemand ein halbfertiges Server-Setup, heisst die Übergabe, den Thread zu öffnen, nicht ein Dokument zu schreiben, warum welche Entscheide gefallen sind und welche Ansätze schon gescheitert waren. Die Session wird zum Protokoll der Arbeit.⁴

Tara Seshan beschreibt dieselbe Verschiebung aus Sicht der Werkzeugbauer. Arbeit wandert vom Rudern zum Steuern, und das Steuern klettert die Abstraktionsleiter hoch: vom Akzeptieren einer Codezeile über das Anleiten einer Aufgabe bis zum Setzen eines Ziels. Die Agents, die sie erwartet, sind persistente Mitarbeitende, mit denen du und deine Kolleginnen euch abstimmt, deren laufende Arbeit ihr prüft und die ihr auf Zielebene steuert. Ihr Vorbehalt ist der, den Product Leader unterstreichen sollten: Ein Agent ohne Zugang zu den Systemen, in denen eure Daten liegen, ist wie eine Kollegin, die du in einen Raum sperrst, ohne Google Docs, Slack oder die Firmendatenbank. Nicht sehr nützlich.²

Persistent statt wegwerfbar. Agents, die Kontext über Sessions und Sprints behalten, wie ein Teammitglied. Gaspar nennt die stehende Variante Org-Graph statt Work-Graph.¹

Geteilt statt privat. Sessions, die mehrere Personen einsehen, steuern und übernehmen können. Das Übergabedokument verschwindet, weil der Thread die Übergabe ist.

Verankert statt isoliert. Zugang zu Tickets, Dokumenten und Code, mit einmal kuratiertem und versioniertem Kontext, sodass zwei Menschen und drei Agents, die denselben Entscheid lesen, dieselbe Antwort bekommen.³

Whittemores Fazit in derselben Folge: Bisher wurden Agents für Arbeit entworfen, die man allein macht, und ein grosser Teil der Arbeit ist Arbeit, die man zusammen macht. Das sei die nächste grosse Entwicklung bei Agents.⁴

Für ein Produktteam ist das kein Tooling-Upgrade. Es ist der Moment, in dem der Schiedsrichter der Loop aufhört, eine Testsuite zu sein, und anfängt, die geteilte Definition des Teams davon zu sein, was entschieden wurde. Ein Coding-Agent kann Code gegen Tests prüfen. Nichts prüft ein Ticket gegen einen Entscheid, der in einem Meeting gefallen ist und nie aufgeschrieben wurde. Multiplayer funktioniert nur, wenn der Entscheid irgendwo steht, wo alle Spieler und alle Agents ihn lesen können.

Was überlebt die nächste Umbenennung?

Loops zahlen sich überall dort aus, wo sich eine Ziellinie aufschreiben und prüfen lässt: Research-Sweeps, Vollständigkeitsprüfungen von Specs, Entwürfe für Teststrategien, Release Notes, Kampagnenoptimierung mit echten Metriken. Sie zahlen sich nicht bei Urteilsfragen aus, und die Versuchung, diese zu loopen, ist gross, weil das Werkzeug es leicht macht. Cal Newports Argument zu Aufwand und Ertrag ist ein nützliches Gegengewicht: Der Ertrag ist nichtlinear, also schlägt eine Sache mit Tiefe fünf Sachen, die man anschubst. Eine Loop ist ein Weg, einer Aufgabe diese Tiefe zu geben. Zehn Loops gleichzeitig sind zehn flache Dinge mit einer Token-Rechnung.⁵

Graphs zahlen sich aus, wenn die Prüfung Unabhängigkeit braucht oder Arbeit parallel laufen kann, und sie kosten Tokens, Aufmerksamkeit und Entwurfszeit. Fang mit einem Agent an, füge eine Loop hinzu, wenn ein Durchgang scheitert, füge einen zweiten Knoten hinzu, wenn die Selbstprüfung keine Fehler mehr findet.

Multiplayer ist früh. OpenClaws Umsetzung ist das Experiment eines Teams, ChatGPT Work und Codex werden für die Modellfähigkeiten in zwei bis drei Monaten gebaut, nicht für die heutigen, und die Befehle für Loops und Sub-Agents ändern sich zwischen Releases, manchmal zwischen CLI und Desktop-App desselben Werkzeugs. Prüfe die aktuelle Dokumentation, bevor du etwas standardisierst.^1,2,4

Die Stufen werden weiter umbenannt. Die Fähigkeit darunter ändert sich nicht: die Arbeit definieren, den Grad der Autonomie wählen, die Prüfung bauen, die Agents koordinieren. Das ist Gaspars Schlusspunkt, und es ist auch die Stellenbeschreibung eines Product Leaders im Jahr 2026.¹

Womit der Beitrag zum Muster im ersten Absatz zurückkommt. Die Engineers hatten Loops mit einem Schiedsrichter. Die Produktentscheide hatten weder eine Ziellinie noch einen Ort, an dem die Agents sie lesen konnten. Coden ist schnell geworden. Wissen, was zu bauen ist, nicht, weil das Wissen nie dort stand, wo die Spieler es sehen konnten.

Wo Teklens in diesem Bild sitzt

Das ist die eine Stelle, an die Teklens in diesem Beitrag gehört. Alles oben beschreibt die Engineering-Hälfte der Loop: Agents, die bauen, bis die Tests grün sind. Die Produkt-Hälfte ist der Entscheid, die Spec und das Ticket, und diese Hälfte hat keinen Compiler. Teklens ist als geteilter Kontext für genau diese Hälfte gebaut. Es liest Jira, die Docs und das Repository, hält eine Living Spec pro Vorhaben, und ändert sich ein Entscheid, weiss es jedes Ticket und jede Datei, die davon abhängt. Product entscheidet, Engineering sieht den Code-Impact, der Coding-Agent bekommt seinen Kontext aus derselben Quelle. Im Vokabular dieses Beitrags: der Schiedsrichter für die Produktseite und die geteilte Session für das ganze Team.

Namen und Zahlen veröffentlichen wir nur mit Freigabe, deshalb steht hier keine Metrik. Wenn du den Mechanismus auf deinem eigenen Repository sehen willst: Buch einen Call mit einem Founder. Ein Call, und Jira und euer Repo sind in unter einer Stunde verbunden.

Häufige Fragen

Empfehlungen

• Wähle eine wiederkehrende Aufgabe mit natürlicher Ziellinie. Schreib die Goal Card und lass sie diese Woche mit einer Zyklen-Kappe als Loop laufen. Das Log des ersten Durchlaufs ist die Lektion.
• Repariere die Definition, nicht die Loop. Wenn das Ergebnis die Kriterien erfüllt und dich trotzdem enttäuscht, schreib die Kriterien um, bevor du irgendetwas anderes anfasst.
• Füge zuerst einen unabhängigen Prüfer hinzu. Ein anderes Modell mit frischem Kontext, das nichts über die Entstehung des Entwurfs weiss, ist der erste Knoten, der sich lohnt.
• Zeichne den Graph für den Job, nicht für die Meeting-Struktur. Übergaben, Freigaben und Rollentrennungen existieren wegen menschlicher Grenzen. Agents haben andere. Beginne beim Ergebnis, nicht beim heutigen Prozess.
• Prüfe, ob eure Entscheide lesbar sind. Bevor du in Multiplayer-Tooling investierst, prüfe, wo eure Produktentscheide aufgeschrieben sind und ob ein Agent sie lesen könnte. Wenn nicht, ist das der erste Schritt.

Einordnung & Grenzen

• Das Stufenmodell stammt aus Nufar Gaspars Webinar im AI Daily Brief (3. September 2026) und gibt den Sprachgebrauch von Praktikern zu diesem Datum wieder, keine wissenschaftliche Taxonomie; sie sagt selbst, dass die Begriffe bis zum Winter umbenannt sein werden.
• Die OpenClaw-Zahlen (933 Beitragende, 16'000 Pull Requests) sind die Release-Angaben des Projekts, wie sie im Podcast wiedergegeben wurden, nicht unabhängig geprüft. Tara Seshans Aussagen beschreiben interne Praxis und Produktrichtung von OpenAI, also die Sicht eines Anbieters. Die Beschreibung von Pinecone Nexus ist die Darstellung des Anbieters seines eigenen Produkts.
• Die 24 Discovery-Gespräche sind Gespräche von Teklens mit Product-Leuten, keine Studie; das Muster im Einstieg ist, was sich über die Gespräche hinweg wiederholt hat, kein Einzelzitat.
• Die Teklens-Aussagen beschreiben Fähigkeiten des Produkts, keine gemessenen Kundenresultate; Namen und Zahlen erst mit Freigabe.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Nufar Gaspar und Nathaniel Whittemore, «Agentic Loops for Knowledge Workers», The AI Daily Brief, 3. September 2026 ↗ – Das Rückgrat dieses Beitrags: die fünf Stufen ab 06:44, die Goal-Card-Demo ab 23:03, die Fehlerarten ab 26:52, Loops zu Graphs ab 33:19.
2. 2.Tara Seshan mit Lenny Rachitsky, «AI's third era: the rise of persistent AI coworkers», Lenny's Podcast, 30. August 2026 ↗ – Rudern versus Steuern und persistente Mitarbeitende ab 11:25; die Regel, zwei bis drei Monate vor den Modellen zu bauen, ab 28:01.
3. 3.Jörg Schad mit Kevin Ball, «Moving Beyond RAG with Precomputed Context», Software Engineering Daily, 3. September 2026 ↗ – Kontext als vorberechnetes, versioniertes Artefakt mit Berechtigungen ab 07:04 und 09:58.
4. 4.Nathaniel Whittemore, «OpenClaw 2.0 Shows Where AI Agents Are Going Next», The AI Daily Brief, 1. September 2026, mit Zitaten von Peter Steinberger und OpenClaw-Maintainer Colin ↗ – Die geteilte Session ab 24:11; «Arbeit, die man allein macht, versus Arbeit, die man zusammen macht» ab 25:33.
5. 5.Cal Newport, «Ep. 209: Email and Living with Purpose», Deep Questions, 15. August 2022, Segment «You need to do less» (57:21) ↗ – Nicht über KI, und die richtige Warnung, bevor du zehn Loops gleichzeitig startest.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.