Eine Promptware ist eine in sich geschlossene Agenten-Einheit, die ihre eigenen Instruktionen, ihr Gedächtnis (Memory), Werkzeugberechtigungen (Tools) und die Ausführungshistorie (Logs) als Dateien speichert – und ihre Instruktionen sowie ihr Gedächtnis nach jedem Lauf selbstständig überarbeitet. In Ivy Tendril wird jede Phase des Plan-Lebenszyklus, vom ersten Plan-Entwurf bis zum Eröffnen eines Pull Requests, von einer solchen Einheit ausgeführt. Da die Instruktionen versionierte Dateien im Repository sind, können sie wie jede andere Quelldatei gereviewt, gedifft, zurückgerollt und im gesamten Team geteilt werden. Dieser Artikel erklärt den Aufbau einer solchen Einheit, den Ausführungs-Loop (Run Loop), die sieben mitgelieferten Standard-Promptwares und die beiden typischen Fehlermodi, auf die man achten muss.

Was eine Promptware-Einheit enthält

Eine Promptware-Einheit ist ein Verzeichnis mit vier Komponenten. Jede Komponente hat genau eine Aufgabe.

Bestandteil	Inhalt	Wer schreibt es
`Program.md`	Die Instruktionen, denen der Agent in seiner Phase folgt. Wird nach einem Durchlauf vom Agenten überarbeitet und von Entwicklern überprüft.	Agent und Entwickler
`Memory/`	Persistente Erkenntnisse über die Codebasis und Team-Konventionen. Wird nach jedem Lauf angehängt.	Agent
`Tools/`	Die abgegrenzten Berechtigungen für diese Phase: Welche Befehle, Dateien und Integrationen der Agent nutzen darf.	Entwickler
`Logs/`	Die Ausführungshistorie: Was der Agent gelesen, ausgeführt und geändert hat, und zu welchen Schlüssen er kam.	Agent (Append-only)

Program.md ist Fließtext, kein Code. Ein Abschnitt für eine Plan-Ausführungseinheit könnte beispielsweise so aussehen:

## Vor dem Eröffnen eines Pull Requests

- Führe `pnpm lint` und `pnpm test` im Root-Verzeichnis des Repositorys aus. Erstelle keinen PR, wenn einer der Befehle fehlschlägt.
- Beschränke das Diff streng auf die im Plan genannten Dateien. Falls eine weitere Datei geändert werden muss, begründe dies in der PR-Beschreibung.
- Verwende das Commit-Nachrichtenformat `type(scope): summary`.

Ein Gedächtniseintrag hält eine Erkenntnis fest, die der Agent gelernt hat, die nicht unmittelbar aus dem Code hervorgeht und die zukünftige Durchläufe kennen sollten:

### 2026-08-21, Plan #412

Das Billing-Modul unter `src/billing/` besitzt keine Tests. Vor einem Refactoring müssen Tests ergänzt werden.
`pnpm test` führt zuerst die Datenbankmigrationen aus; ein Durchlauf dauert bei einem frischen Checkout etwa vier Minuten.

Die beiden Dateien unterscheiden sich grundlegend im Wesen. Das Programm beschreibt, was zu tun ist. Das Memory beschreibt, was über dieses Repository wahr ist. Diese Trennung ermöglicht es einem Reviewer, einen neuen Fakt zu akzeptieren, ohne eine Änderung am Ablaufverfahren zuzulassen – und umgekehrt.

Der Ausführungs-Loop

Jeder Promptware-Lauf folgt denselben vier Schritten.

Programm laden. Der Agent liest Program.md und die Berechtigungen in Tools/. Nichts außerhalb dieser Berechtigungen steht ihm zur Verfügung.
Gedächtnis lesen. Der Agent liest Memory/, damit die in früheren Läufen gewonnenen Erkenntnisse im Kontext präsent sind, bevor er mit der Arbeit beginnt.
Aufgabe ausführen. Der Agent führt die Arbeit der jeweiligen Phase aus: einen Plan entwerfen, erweitern, in einem Worktree ausführen oder einen Pull Request eröffnen. Jeder Werkzeugaufruf und dessen Ausgabe wird an Logs/ angehängt.
Reflektieren und zurückschreiben. Der Agent vergleicht den tatsächlichen Ablauf mit den Erwartungen laut Programm. Neue Erkenntnisse wandern nach Memory/. War eine Instruktion falsch, unvollständig oder redundant, überarbeitet der Agent Program.md.

Dieser Kreislauf aus Handeln, Ergebnis beobachten und nächste Instruktion überarbeiten entspricht dem Muster, das das ReAct-Paper für denkende Agenten beschreibt. Eine Promptware unterscheidet sich vor allem dadurch, dass die Überarbeitung in eine Datei geschrieben wird, die den einzelnen Lauf überdauert. Dieser vierte Schritt sorgt dafür, dass Instruktionen mit der Zeit besser werden statt zu degenerieren. Er ist zugleich der Schritt, der die meiste menschliche Aufsicht erfordert – worauf der Abschnitt zu den Risiken näher eingeht.

Die integrierten Promptwares

Ivy Tendril wird mit sieben Promptwares ausgeliefert – jeweils eine für die Phasen des Lebenszyklus, wie in Vom GitHub-Issue zum Pull Request beschrieben. Jede verfügt über ihr eigenes Programm, ihr eigenes Gedächtnis, eigene Berechtigungen und Logs.

CreatePlan wandelt eine Idee, ein GitHub-Issue oder einen Bugreport in einen Plan-Entwurf um: Ziel, Umfang, betroffene Dateien, Verifikationsschritte.
ExpandPlan reichert einen Entwurf mit Details an, wenn für die Ausführung noch Informationen fehlen, etwa Akzeptanzkriterien oder offene Architekturentscheidungen.
UpdatePlan schreibt einen Entwurf anhand von Inline-Kommentaren des Entwicklers um.
SplitPlan teilt einen Plan, dessen Umfang zu groß geworden ist, in mehrere kleinere Pläne auf, die parallel ausgeführt werden können.
ExecutePlan führt den freigegebenen Plan mit dem gewählten Coding-Agenten (Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode oder einem beliebigen CLI-Agenten) in einem isolierten Git-Worktree aus. Anthropic argumentiert in den Claude Code Best Practices mit denselben Gründen für versionierte Instruktionsdateien wie dieser Abschnitt für Program.md.
CreatePr öffnet den Pull Request, sobald das Diff die Verifikation und das menschliche Review bestanden hat.
CreateIssue erstellt ein GitHub-Issue aus einer Empfehlung oder Entdeckung während der Ausführung.

Da jede Einheit strikt getrennt ist, wird das Gedächtnis von CreatePlan (z. B. „Das Team erwartet in Plänen die Nennung aller betroffenen Testdateien“) nicht mit ExecutePlan geteilt – und ExecutePlans Berechtigung zur Ausführung von Shell-Befehlen wird CreatePlan nicht gewährt. Die Promptware-Dokumentation listet die Standardinhalte jeder Einheit detailliert auf.

Versionierte Instruktionen und die zwei Risiken

Warum Dateien im Repository Ad-hoc-Prompts überlegen sind

Ein Ad-hoc-Prompt im Chat-Fenster existiert nur ein einziges Mal, für eine einzige Person, und verschwindet mit dem Sitzungsende. Eine im Repository committete Program.md besitzt vier entscheidende Eigenschaften, die einem Prompt fehlen.

Review. Eine Änderung am Programm ist ein Diff in einem Pull Request. Ein Senior Engineer kann eine Instruktion wie „Tests überspringen, wenn die Änderung klein ist“ ablehnen, bevor sie sich auf künftige Läufe auswirkt.
Diff. Wenn sich die Qualität der Agentenausgaben verändert, zeigt git log im Promptware-Verzeichnis genau, welche Instruktion wann modifiziert wurde.
Rollback. Eine problematische Überarbeitung lässt sich mit einem einzigen Commit rückgängig machen.
Teilbarkeit (Sharing). Jeder Entwickler im Team und jeder Agentenlauf nutzt dieselben standardisierten Anweisungen. Eine Konvention, die ein Lauf am Montag gelernt hat, steht am Dienstag allen zur Verfügung.

Dieselben Argumente führten seinerzeit dazu, Infrastruktur von manuellen Konfigurationen auf versionierten Code umzustellen, und dasselbe Prinzip liegt der Auslagerung von Konfigurationen aus dem Code in der Twelve-Factor-App zugrunde. Weitere Ansätze zur Strukturierung von Agentenarbeit und wie Promptware im Vergleich abschneidet, werden in Muster für die Agenten-Orchestrierung erläutert.

Risiko 1: Instruktions-Drift (Instruction Drift)

Ein Agent, der sein eigenes Programm bearbeiten kann, kann es auch verschlechtern. Schlägt ein Lauf wegen eines unzuverlässigen (flaky) Tests fehl, könnte der Agent die Regel ergänzen: „Fehlschlagende Tests bis zu dreimal wiederholen“ – was beim nächsten Mal ein echtes Problem maskiert. Zwei Schutzmechanismen fangen dies auf: Erstens ist das Programm eine versionierte Datei, jede Änderung ist also ein Diff, das ein Reviewer sieht und verwerfen kann. Zweitens zeichnet Logs/ den Lauf auf, der zu der Änderung geführt hat, sodass der Reviewer die Begründung prüfen kann, bevor er sie akzeptiert.

Risiko 2: Gedächtnis-Aufblähung (Memory Bloat)

Ein Gedächtnis, das nur wächst, verursacht Kosten ohne Nutzen. Eine Datei mit 400 Einträgen, von denen die Hälfte veraltet ist, verbraucht bei jedem Lauf unnötig Tokens und erschwert das Auffinden relevanter Fakten. Zwei Praktiken halten es nutzbar: Versehen Sie jeden Eintrag mit Datum und Gültigkeitsbereich (Scope), wie im obigen Beispiel, damit veraltete Einträge leicht identifizierbar sind. Und pflegen Sie das Memory während des Reviews: Berührt ein Plan einen bestimmten Bereich, prüft der Reviewer die zugehörigen Gedächtniseinträge und entfernt nicht mehr zutreffende Fakten. Kosten- und Token-Tracking pro Plan und Job machen dieses Wachstum transparent – denn eine Einheit mit aufgeblähtem Gedächtnis zeigt steigende Tokenzahlen ohne Zunahme der Plangröße. Aus diesem Grund erfasst Messung des Durchsatzes von KI-Coding-Agenten die Kosten pro gemergtem Pull Request statt pro Lauf.

Wie Sie starten

Installieren Sie Ivy Tendril, öffnen Sie ein Repository und erstellen Sie einen Plan. Die sieben integrierten Promptwares sind ab dem ersten Durchlauf einsatzbereit.

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

Unter Windows verwenden Sie irm https://cdn.ivy.app/install-tendril.ps1 | iex. Lesen Sie die Program.md-Dateien vor der ersten Ausführung und prüfen Sie die ersten Memory-Einträge und Programmanpassungen mit derselben Sorgfalt wie Code-Änderungen. Nach etwa zehn Plänen spiegelt das Memory genau die Bereiche der Codebasis wider, in denen der Agent auf Hürden stieß – meist dieselben Stellen, an denen auch menschliche Entwickler innehalten. Weitere Details zu den integrierten Einheiten finden Sie in den Promptware-Docs.

Häufig gestellte Fragen

Ändert der Agent die Program.md ungefragt?

Der Agent überarbeitet sein Programm nach Abschluss eines Laufs. Da Program.md eine versionierte Datei ist, erscheint diese Änderung als Git-Diff, das Sie einsehen, annehmen oder zurücksetzen können – und das Log des auslösenden Laufs liegt direkt daneben.

Kann ich eigene Promptwares schreiben?

Die sieben Standard-Einheiten decken die typischen Lebenszyklus-Phasen ab. Ihre Programme, Gedächtnisse und Werkzeugberechtigungen sind einfache Textdateien, sodass Sie diese an die Konventionen Ihres Teams anpassen können. Informationen zu den aktuellen Erweiterungsmöglichkeiten finden Sie in der Dokumentation.

Wo werden Memory und Logs gespeichert?

Lokal auf dem Rechner, auf dem Tendril ausgeführt wird. Sie werden nicht zu Ivy hochgeladen. Die einzigen Netzwerkaufrufe, die Tendril tätigt, gehen an die von Ihnen konfigurierte LLM-API und an GitHub.

Erste Schritte mit Ivy Tendril

Sind Sie bereit für parallele Agenten-Orchestrierung auf Entwickler-Niveau?

Code erkunden: Untersuchen Sie Ivy Tendril auf GitHub (Open Source).
Dokumentation lesen: Finden Sie Integrationsanleitungen unter tendril.ivy.app.
Architektur-Sitzung vereinbaren: Kontaktieren Sie renco@ivy.app für eine 30-minütige technische Beratung.

Promptware: Agenten, die ihre eigenen Instruktionen pflegen und verbessern