Loop Engineering in MCPlato: Von Prompts zu Workflows, die Artifacts hinterlassen

Kurzantwort: Beim Loop Engineering geht es nicht darum, einen längeren Prompt zu schreiben. Es geht darum, einen Arbeitsloop zu entwerfen, der seine Eingaben beobachten, Zustand halten, an Checkpoints pausieren, sich von Fehlern erholen, menschliche Genehmigung einholen und ein prüfbares Artifact hinterlassen kann. In MCPlato kann dieser Loop zu einem Wand, einem Skill, einer Scheduled Task, einem Channel-Workflow oder einer Sprite-koordinierten Gruppe von Sitzungen werden.

Titelillustration zu Loop Engineering in MCPlato

Abbildung 1: Loop Engineering verwandelt einmalige KI-Anfragen in Arbeitszyklen, die dauerhafte Artifacts erzeugen.

Prompt Engineering fragt: Wie soll ich fragen? Loop Engineering fragt: Wie soll KI sicher weiterarbeiten, bis das Artifact fertig ist?

Dieser Unterschied ist wichtig, weil echte Arbeit selten in einer einzigen Antwort abgeschlossen ist. Maintainer brauchen Korrekturen mit Testnachweisen; Produktverantwortliche brauchen Briefings mit Quellen und Zeitstempeln; Operations-Teams brauchen Berichtspakete mit Audit-Trails; Geschäftsverantwortliche brauchen Genehmigungen vor externen oder destruktiven Aktionen.

Die richtige Designeinheit ist daher der Loop.

Die MCPlato-Methode für Loop-Design

Ein guter Loop hat drei Eigenschaften:

1. Beobachtbar: Der Nutzer kann Quellen, Zustand, Aktionen und Ergebnisse sehen.
2. Wiederherstellbar: Die Arbeit kann von einem Checkpoint fortgesetzt werden, statt von vorn zu beginnen oder sich zu wiederholen.
3. Artifact-zentriert: Der Loop endet in etwas Prüfbarem: einem Bericht, Diff, Spreadsheet, Paket, Entscheidungslog, Briefing, Entwurf oder Review-Protokoll.

MCPlato passt natürlich zu diesem Modell:

• Wand: ein verpackter Workflow für eine wiederholbare Aufgabe, mit Phasen, Anleitung und einer sichtbaren, Artifact-orientierten Laufzeit.
• Artifact: die dauerhafte Ausgabe, die belegt, dass der Loop nützliche Arbeit geleistet hat.
• Sprite: der Koordinator, der Arbeit auf Sitzungen verteilen und Ergebnisse wieder zusammenführen kann.
• Skill und Distill Skill: wiederverwendbares Know-how, das erneut aufgerufen werden kann, nachdem ein Loop sich bewährt hat.
• ClawMode: eine Möglichkeit, Arbeit über Zeit, Kanäle und Hintergrundkontexte hinweg fortzusetzen.
• Scheduled Tasks und Channels: Auslöser und Lieferwege für wiederkehrende Loops.
• Berechtigungen und Checkpoints: Grenzen, die nützliche Autonomie kontrolliert halten.

Ein praktischer MCPlato-Loop folgt in der Regel neun Schritten:

Der Rest dieses Artikels wendet die Methode auf vier reale Bedarfsszenarien an, die in öffentlichen Diskussionen und Dokumentationen auftauchen.

Szenario 1: GitHub issue -> Fix-PR -> evidenzgestützter QA-Bericht

Open-Source-Maintainer experimentieren bereits mit Agents, die GitHub issues übernehmen und begrenzte Fixes versuchen können. OpenHands beschreibt einen GitHub Resolver für Repository issues, und die QA-Dokumentation konzentriert sich darauf, Änderungen zu validieren, statt nur Code zu produzieren.¹² Maintainer brauchen einen Patch, Tests und Nachweise, dass die Änderung sicher genug für ein Review ist.

Ein verwandtes Risiko zeigt sich in echtem Entwicklerfeedback. Ein GitHub issue von Continue berichtet, dass ein Agent wiederholt über denselben Code loopt, statt sauber zu stoppen.³ Genau diesen Fehlermodus muss Loop Engineering adressieren: unkontrollierte Iteration ohne Stoppbedingung.

GitHub issue zu QA-Evidenz-Loop

Abbildung 2: Ein begrenzter Engineering-Loop sollte einen Diff, Validierungslogs und ein QA-Evidence-Artifact erzeugen, nicht nur die Behauptung, dass das Issue behoben ist.

Das Loop-Design

In MCPlato sollte der Loop beim Artifact beginnen, nicht bei der Modellausgabe:

1. Issue-Aufnahme: Issue, verlinkte Dateien, Reproduktionsnotizen und Repository-Einschränkungen sammeln.
2. Plan-Checkpoint: Nutzer oder Maintainer bitten, den vorgesehenen Umfang vor dem Editieren zu genehmigen.
3. Patch-Phase: Die kleinste sinnvolle Änderung innerhalb eines begrenzten Arbeitsbereichs vornehmen.
4. Validierungsphase: Die vereinbarten Checks ausführen, Fehler protokollieren und nur innerhalb des genehmigten Umfangs erneut versuchen.
5. Evidence Artifact: Einen QA-Bericht mit geänderten Dateien, Testlogs, bei Bedarf Screenshots und verbleibenden Risiken erstellen.
6. Review-Gate: Einen Entwurf für eine PR- oder MR-Beschreibung vorbereiten, die Arbeit aber nicht als gemerged oder akzeptiert darstellen.
7. Distill: Wenn das Muster funktioniert, daraus einen wiederverwendbaren Repository-QA-Skill oder einen Wand für das Team machen.

MCPlato-Implementierungsmuster

Ein Sprite-koordiniertes Setup ist hier nützlich. Eine Sitzung kann das Issue lesen und den Plan entwerfen, eine andere kann das Repository prüfen, eine weitere kann validieren, und die finale Sitzung kann das QA-Evidence-Artifact zusammensetzen. Ein Wand kann die Phasen verpacken, damit das Team den Loop nicht für jedes Issue neu erfinden muss.

Die wichtige Leitplanke ist die Stoppbedingung: Der Loop sollte stoppen, wenn das Validierungsbudget erschöpft ist, wenn derselbe Fehler erneut auftritt oder wenn die Änderung den genehmigten Umfang überschreiten würde. Das Artifact sollte exakt sagen, was passiert ist, statt Unsicherheit zu verbergen.

Artifact: Diff-Zusammenfassung, Testlogs, QA-Evidence-Bericht, Entwurf für PR/MR-Beschreibung und Risikoliste.

Szenario 2: Geplantes Research-Briefing, das das vollständige Ergebnis liefert

Wiederkehrende Recherche ist ein weiterer Bereich, in dem „einmal prompten“ zu schwach ist. Nutzer, die über geplante KI-Aufgaben diskutieren, haben gefordert, vollständige Ergebnisse per E-Mail zu erhalten, nicht nur Abschlussbenachrichtigungen.⁴ Zapiers Überblick über ChatGPT scheduled tasks beschreibt das Muster, ChatGPT zu bitten, Prompts in der Zukunft oder in einem wiederkehrenden Rhythmus auszuführen.⁵ Die praktische Lücke liegt in der Lieferqualität: Ein nützlicher geplanter Loop sollte ein Briefing mit Links, Zeitstempeln, Deltas und Aktionspunkten erzeugen.

Liefer-Loop für geplante Briefings

Abbildung 3: Ein geplanter Loop sollte Quellen sammeln, deduplizieren, synthetisieren, Zitate prüfen und das vollständige Briefing-Artifact an den richtigen Kanal liefern.

Das Loop-Design

Ein MCPlato-Briefing-Loop kann so aussehen:

1. Geplanter Auslöser: täglich, wöchentlich oder vor einem festen Meeting laufen.
2. Quellensammlung: Genehmigte Quellen wie gespeicherte URLs, RSS-ähnliche Feeds, Dokumentationsseiten oder Workspace-Materialien sammeln.
3. Relevanz und Deduplizierung: Wiederholte Ankündigungen und Elemente mit geringem Signal entfernen.
4. Synthese: Das Briefing in einem stabilen Format schreiben.
5. Zitationsprüfung: Sicherstellen, dass jede konkrete Behauptung auf eine Quell-URL zurückverweist.
6. Artifact-Ausgabe: Ein datiertes Briefing mit Quellenliste und Tabelle der Aktionspunkte erstellen.
7. Channel-Lieferung: Das vollständige Artifact oder eine knappe Zusammenfassung mit Link zum Artifact senden.
8. Follow-up: Dem Nutzer ermöglichen, tiefere Analyse anzufordern, nächste Aktionen zuzuweisen oder den Briefing-Loop zu distillieren.

MCPlato-Implementierungsmuster

Hier arbeiten Scheduled Tasks, ClawMode und Kanäle zusammen. Die Scheduled Task löst den Loop aus; MCPlato sammelt genehmigten Kontext, erzeugt das Artifact und liefert es an den Workspace oder Kanal. Sprite kann separate Workers für Quellensammlung, Synthese und Zitationsreview koordinieren, wenn das Briefing hohe Bedeutung hat.

Ein Briefing-Loop sollte niemals vortäuschen, Quellen gelesen zu haben, auf die er nicht tatsächlich zugegriffen hat. Das Artifact sollte „nicht gefunden“ oder „nicht geprüft“ enthalten, wenn Informationen nicht verfügbar sind. Dieser ehrliche Zustand ist nützlicher als ein polierter, aber nicht überprüfbarer Absatz.

Artifact: tägliches oder wöchentliches Briefing, Quellenliste, Tabelle der Aktionspunkte, Delta zum vorherigen Run und Zitationsnotizen.

Szenario 3: Browser-Login, Parameterbefüllung, Berichtdownload und lokale Organisation

Viele Geschäftsworkflows liegen weiterhin hinter Webseiten statt hinter sauberen APIs. Eine Stack Overflow-Frage fragt, wie man das Login auf einer Webseite und den Download eines Berichts automatisieren kann.⁶ In einer Python.org-Diskussion beschreibt ein Nutzer, Berichte für etwa 50 Kunden mit jeweils 3 bis 4 Berichten herunterzuladen, was jede Woche von Hand 3 bis 4 Stunden dauert.⁷ Das ist ein realer operativer Schmerzpunkt: repetitiv, browsergebunden und leicht fehleranfällig.

Browser-Berichtdownload-Loop

Abbildung 4: Browser-Automatisierung sollte menschliche Login-Grenzen von wiederholten Parameter-, Download-, Validierungs- und Organisationsschritten trennen.

Das Loop-Design

Ein sicherer Browser-Berichtsloop sollte Zugriffsgrenzen explizit machen:

1. Anforderungsaufnahme: Kundennamen, Berichtstypen, Datumsbereiche und erwartete Dateien auflisten.
2. Zugriffsgrenze: Entscheiden, was der Nutzer manuell tun muss, etwa Login, MFA oder CAPTCHA.
3. Discovery und API-Prüfung: Prüfen, ob ein dokumentierter Export oder eine API existiert, bevor Browser-Automatisierung genutzt wird.
4. Browser-Automatisierung: Parameter ausfüllen, Downloads starten und jeden Schritt protokollieren.
5. Validierung: Dateinamen, Zeitstempel, erwartete Anzahl und offensichtlich leere Dateien prüfen.
6. Transformation: Ordner normalisieren, Formate bei Bedarf konvertieren und Zusammenfassungen erstellen.
7. Ausnahmebericht: Fehlende Downloads, fehlgeschlagene Kunden oder geänderte Seiten auflisten.
8. Geplante Wiederholung: Nur den wiederholbaren Teil in einem Rhythmus ausführen, mit menschlichem Checkpoint, wenn sich Zugangsdaten oder Seitenstruktur ändern.

MCPlato-Implementierungsmuster

MCPlato sollte nicht als „kann jede Website bewältigen“ gerahmt werden. Websites unterscheiden sich, Logins ändern sich, Richtlinien zählen, und manche Flows sind absichtlich resistent gegen Automatisierung. Die bessere Rahmung lautet: MCPlato kann helfen, einen kontrollierten Loop um die erlaubten, wiederholbaren Teile zu entwerfen.

Der Nutzer kann den Login-Checkpoint übernehmen. Der KI-Loop kann dann innerhalb der genehmigten Browsersitzung arbeiten, Berichte herunterladen, lokale Dateien organisieren und ein Ausnahme-Artifact erzeugen. Wenn sich die Website ändert, sollte der Loop stoppen und die Abweichung melden, statt zu raten.

Diese Art von Loop lohnt sich nach einigen erfolgreichen Runs oft als Wand. Der Wand wird zum wiederholbaren „monatlichen Berichtspaket“-Prozess des Teams, mit klaren Phasen und Ausgabeordner statt eines fragilen Transkripts.

Artifact: heruntergeladenes Berichtspaket, Erfolgs-/Fehlerliste, normalisierte Ordnerstruktur, Zusammenfassungs-Spreadsheet und Ausnahmebericht.

Szenario 4: Menschliche Genehmigung für riskante Tool-Aufrufe

Loop Engineering bedeutet nicht nur, mehr zu tun. Es bedeutet auch, zu wissen, wann man stoppen muss. Ein LangGraph issue fragt nach einem Approval-Node-Muster, bei dem Nutzer Aktionen vor der Ausführung genehmigen, ablehnen oder ändern können.⁸ Die Human-in-the-loop-Dokumentation von LangChain beschreibt Pausen zur Prüfung rund um Tool-Aufrufe.⁹

Die Risikobeispiele sind vertraut: Dateien schreiben, SQL ausführen, Daten löschen, Inhalte veröffentlichen oder E-Mails senden. Das sind nicht nur „Agent-Schritte“. Es sind Geschäftsaktionen.

Loop mit menschlichem Genehmigungstor

Abbildung 5: Ein guter Loop pausiert vor riskanten Aktionen, protokolliert die Entscheidung und hinterlässt nach der Ausführung Nachweise.

Das Loop-Design

Ein Loop für riskante Aktionen sollte so aussehen:

1. Risikoklassifikation: Entscheiden, ob die nächste Aktion nur lesend, reversibel, extern sichtbar, destruktiv oder finanziell ist.
2. Aktion entwerfen: Dateiänderung, SQL-Anweisung, E-Mail, Post oder Befehl vorbereiten, ohne ihn auszuführen.
3. Genehmigungs-Checkpoint: Dem Nutzer die beabsichtigte Aktion, den Grund, die erwartete Wirkung und den Rollback-Plan zeigen.
4. Nutzerentscheidung: Genehmigen, bearbeiten, ablehnen oder mehr Kontext anfordern.
5. Ausführung: Nur die genehmigte Aktion ausführen.
6. Evidence Artifact: Entscheidung, Vorher-nachher-Diff, Ausführungsergebnis und verbleibendes Risiko protokollieren.

MCPlato-Implementierungsmuster

MCPlatos Loop-Vokabular macht dies unkompliziert. Ein Wand kann Entwurf und Ausführung trennen. Berechtigungen können vor der Genehmigung enger und erst nach Bestätigung breiter sein. Sprite kann eine andere Sitzung bitten, die vorgeschlagene Aktion zu prüfen, bevor der Nutzer sie sieht. ClawMode und Kanäle können die Genehmigungsanfrage dorthin bringen, wo der Nutzer arbeitet.

Der Loop sollte gefährliche Defaults niemals normalisieren. Daten löschen, externe Nachrichten senden, Abrechnung ändern oder Inhalte veröffentlichen sollte ein Gate erfordern, sofern der Nutzer für diese Aktion nicht ausdrücklich einen vertrauenswürdigen, begrenzten Workflow entworfen hat.

Artifact: Genehmigungsprotokoll, Änderungsplan, Vorher-nachher-Diff, Nachrichten- oder E-Mail-Entwurf, Ausführungsnachweis und Risikoliste.

Wie man einen erfolgreichen Loop in wiederverwendbare MCPlato-Fähigkeit verwandelt

Nachdem ein Loop einmal erfolgreich war, sollte nicht sofort alles automatisiert werden. Zuerst fragen:

1. War das Artifact nützlich? Wenn die Ausgabe dem Nutzer nicht half, eine Entscheidung zu treffen oder Arbeit abzuschließen, ist der Loop noch nicht bereit.
2. Lagen die Checkpoints an der richtigen Stelle? Zu viele Checkpoints machen den Loop lästig; zu wenige machen ihn unsicher.
3. Könnte ein anderer Nutzer dies ohne versteckten Kontext ausführen? Wenn die Antwort nein lautet, dokumentiere die erforderlichen Eingaben und Annahmen.

Dann den richtigen MCPlato-Verpackungspfad wählen:

Die jüngste Richtung im main branch von MCPlato stärkt diesen Wandel von Chat zu verpackter, beobachtbarer Arbeit. Wands machen Workflows explizit. Artifact-orientierte Laufzeitansichten halten das Ergebnis sichtbar. Anleitung für Wand-Autoring und Iteration erleichtert es, einen erfolgreichen Loop in eine wiederverwendbare Fähigkeit zu verwandeln. Skills und Distill Skill bewahren die wiederholbaren Teile der Methode.

Das Prinzip ist einfach: Speichere nicht nur die Antwort; speichere den Arbeitsloop, der die Antwort erzeugt hat.

Risiken und Leitplanken

Loop Engineering ist mächtig, kann aber auf vorhersehbare Weise scheitern:

• Ausufernde Iteration: Budgets, Erkennung wiederholter Fehler und explizite Exit-Zustände hinzufügen.
• Falsche Fertigstellung: Ein Artifact mit Logs, Quellen oder Vorher-nachher-Nachweis verlangen.
• Berechtigungsdrift: Berechtigungen nach Phase zuweisen.
• Versteckter Kontext: Annahmen im Artifact protokollieren.
• Überautomatisierung: Genehmigungs-Checkpoints für riskante Schritte hinzufügen.
• Fragile Browser-Flows: Validierung und Ausnahmeberichte statt stiller Vermutungen nutzen.
• Zitationsdrift: Quellenzeitstempel und Zitationsreview verlangen.

Ein guter Loop ist nicht der mit der meisten Autonomie. Ein guter Loop ist der, der das Artifact fertigstellt und seine Arbeit dabei sichtbar genug macht, um Vertrauen zu verdienen.

Häufige Fragen

Was ist Loop Engineering?

Loop Engineering ist die Praxis, KI-Arbeit als zustandsbehafteten Prozess statt als einzelne Antwort zu entwerfen. Der Loop definiert Ziel, Eingaben, Phasen, Berechtigungen, Checkpoints, Wiederherstellungspfad und finales Artifact.

Wie unterscheidet es sich von Prompt Engineering?

Prompt Engineering verbessert die Anweisung. Loop Engineering verbessert das Arbeitssystem rund um die Anweisung. Ein besserer Prompt kann eine bessere erste Antwort erzeugen. Ein besserer Loop kann fortfahren, validieren, pausieren, wiederherstellen und liefern.

Wo passt MCPlato hinein?

MCPlato ist nützlich, wenn Arbeit Sitzungen, Dateien, Browserkontext, Zeitpläne, Kanäle und dauerhafte Ausgaben umfasst. Sein Loop-Vokabular aus Wand, Artifact, Sprite, Skill, ClawMode, Scheduled Tasks, Kanälen, Berechtigungen und Checkpoints hilft, nützliche einmalige Arbeit in wiederholbare Fähigkeit zu verwandeln.

Sollte jede KI-Aufgabe zu einem Loop werden?

Nein. Einfache Fragen können einfache Fragen bleiben. Nutze Loop Engineering, wenn die Aufgabe langlaufend, wiederholt, riskant, evidenzlastig oder Artifact-zentriert ist.

Garantiert Loop Engineering Korrektheit?

Nein. Es verbessert Beobachtbarkeit, Wiederherstellung und Review. Der Loop kann weiterhin schlechte Quellen nutzen, falsche Annahmen treffen oder an geänderten Tools scheitern. Deshalb sind Zitate, Checkpoints und Ausnahmeberichte wichtig.

Referenzen

Footnotes

1. OpenHands: Open-source coding agents in your GitHub, fixing your issues ↩

2. OpenHands-Dokumentation: QA changes ↩

3. Continue issue #8062 ↩

4. OpenAI Community: Send full ChatGPT task results via email, not only notifications ↩

5. Zapier: How to use ChatGPT scheduled tasks ↩

6. Stack Overflow: Is there a way to automate webpage login and download report? ↩

7. Python.org-Diskussion: Use Selenium to automatically download reports from website ↩

8. LangGraph issue #8026: ApprovalNode ↩

9. LangChain-Dokumentation: Human-in-the-loop ↩