Die Werkstatt für eure Arbeitsweise.
In Forge beschreibt ein Team einmal sauber, wie eine wiederkehrende Aufgabe richtig erledigt wird — und macht daraus etwas, das ein KI-Agent tatsächlich ausführen kann. Ohne Programmieren, aber innerhalb der Grenzen, die die IT gesetzt hat.
Welche Probleme Forge löst
Die meisten Unternehmen scheitern nicht am Modell. Sie scheitern an vier sehr konkreten Stellen.
-
Pain 1
Prozesswissen lebt in Köpfen
„Für diese Kampagne musst du zuerst die Produktfreigabe prüfen.“ „Die Zielgruppendaten aus dem alten Dashboard sind nicht mehr verbindlich.“ Solche Sätze stehen nirgends. Neue Mitarbeitende lernen sie durch Nachfragen und Fehler.
Mit Forge
Diese Regeln werden einmal als Skill hinterlegt — inklusive „warum“ und „welche Quelle gilt“.
-
Pain 2
Prompt-Sammlungen greifen zu kurz
Ein Prompt sagt, wie formuliert werden soll. Er sagt nicht, welche Quellen verbindlich sind, wie aktuell sie sein müssen, welche Aktionen erlaubt sind und wer freigeben muss.
Mit Forge
Der Prompt ist nur ein Bestandteil. Quellen, Rechte, Output und Tests gehören zum selben Objekt.
-
Pain 3
Einzelne Skills sind unterkomplex
„Dokument suchen“ oder „Datensatz lesen“ sind Funktionen, keine Arbeit. Eine echte Aufgabe braucht ein Dutzend Schritte, mehrere Systeme, Zwischenprüfungen und eine Freigabe.
Mit Forge
Mehrere Skills werden zu einem Playbook verwoben — mit Reihenfolge, Bedingungen und Freigabepunkten.
-
Pain 4
Fachbereich wartet, IT wird zum Nadelöhr
Jede Prozessvariante als Ticket an die IT zu geben, skaliert nicht. Unkontrollierte Low-Code-Automatisierung mit vollen Systemrechten ist aber auch keine Lösung.
Mit Forge
Die IT definiert Systeme, Capabilities und Sicherheitsgrenzen. Das Fachteam baut frei — aber nur darin.
Die Arbeitsteilung, die Forge möglich macht
Der Sandkasten wird von der IT gebaut. Was darin entsteht, entscheidet das Fachteam.
IT & Plattformteam legt fest
- Welche Systeme angebunden sind
- Welche Capabilities es überhaupt gibt
- Welche Datenklassen wie behandelt werden
- Wo Zugangsdaten liegen
- Welche Aktionen nie erlaubt sind
Fach- & Prozessteam baut
- Welche Aufgabe gelöst wird
- Welche Quellen verbindlich sind
- Wie der Agent vorgehen soll
- Welche Rolle was darf
- Wie ein gutes Ergebnis aussieht
Sieben Dinge, die ihr in Forge definiert
Forge stellt euch Fragen. Ihr beantwortet sie in normaler Sprache. Daraus entsteht ein Skill, den ein Agent ausführen kann.
-
Die Aufgabe
Zuerst wird benannt, worum es überhaupt geht — und ebenso wichtig: wann der Skill nicht verwendet werden soll. Das verhindert, dass ein Agent eine Aufgabe übernimmt, für die er nie gedacht war.
- Was soll erreicht werden?
- Für wen ist der Skill gedacht?
- Wann soll er vorgeschlagen werden?
- Wann darf er nicht verwendet werden?
-
Der strukturierte Kontext
Hier entsteht das Context Recipe: die Liste der Informationen, die zu dieser Aufgabe gehören. Der wichtigste Teil ist die Unterscheidung zwischen „verbindlich“ und „nur informativ“ — genau daran scheitern KI-Ergebnisse sonst.
- Welche Quellen sind verpflichtend?
- Welche sind optional?
- Welche Datenfelder werden gebraucht?
- Wie aktuell müssen sie sein?
- Welche Quelle gilt als autoritativ?
-
Skills und Instruktionen
Das Vorgehen selbst. Wichtig: Teilaufgaben werden bewusst klein geschnitten, damit sie in anderen Playbooks wiederverwendet werden können — „Zielgruppe strukturieren“ braucht nicht jedes Team neu.
- Wie soll der Agent vorgehen?
- Welche Teilaufgaben sind wiederverwendbar?
- Welche Beispiele zeigen das gewünschte Verhalten?
-
Die Capabilities
Was der Agent tun darf. Texenda trennt konsequent zwischen Lesen, Entwerfen und Ausführen — und markiert, welche Aktionen eine ausdrückliche Bestätigung brauchen.
- Welche Informationen darf er lesen?
- Welche Entwürfe darf er erstellen?
- Welche Aktionen darf er ausführen?
- Was braucht eine Bestätigung?
-
Die Rollen
Derselbe Skill verhält sich für unterschiedliche Menschen unterschiedlich. Ihr definiert die Rollenmatrix einmal — Texenda setzt sie zur Laufzeit durch, in jedem Client.
- Was darf ein Werkstudent?
- Was darf ein Marketing Manager?
- Was darf Marketing Operations?
- Was muss Legal freigeben?
-
Der Output
Ein Output-Vertrag statt „irgendein Text“. Pflichtfelder, Quellenangaben und Qualitätskriterien machen Ergebnisse vergleichbar und prüfbar.
- Welches Dokument oder Objekt entsteht?
- Welche Pflichtfelder gelten?
- Welche Quellen müssen angegeben werden?
- Welche Qualitätskriterien gelten?
-
Die Tests
Bevor etwas veröffentlicht wird, simuliert Forge den Skill aus der Perspektive jeder Rolle. Ihr seht schwarz auf weiß, welcher Kontext geladen und welche Aktion ausgeblendet wird.
- Wird der richtige Kontext geladen?
- Sind unerlaubte Aktionen ausgeblendet?
- Funktioniert der Skill für jede Rolle?
- Fehlen wichtige Quellen?
Ihr müsst nichts modellieren, bevor ihr anfangt.
Der häufigste Grund, warum Prozessprojekte scheitern: Man soll etwas abstrakt beschreiben, das man sonst einfach tut. Texenda dreht das um — man arbeitet ganz normal mit Agentenunterstützung, und die Struktur entsteht nebenbei.
-
Schritt 1 · Einfach arbeiten
- Aufgabe formulieren
- Kontext auswählen
- Quellen ergänzen
- Irrelevantes entfernen
- Ergebnis korrigieren
-
Schritt 2 · Texenda zeichnet auf
- Ausgewählte Datenquellen
- Verwendete Skills
- Reihenfolge der Aufrufe
- Rückfragen und Freigaben
- Fehler und Korrekturen
-
Schritt 3 · Texenda fragt
- Als persönlichen Skill speichern?
- Bestehenden Skill forken?
- Verbesserung vorschlagen?
- Als neues Playbook strukturieren?
So wird individuelles Erfahrungswissen schrittweise zu gemeinsamem Prozesswissen — ohne Workshop-Marathon.
„Und was mache ich damit konkret?“
Typische Situationen aus dem Alltag und der Weg in Forge.
-
„Ich erkläre jedem Neuen dasselbe.“
Einen Skill anlegen, die Erklärung als Instruktion hinterlegen, die drei verbindlichen Quellen verlinken. Beim nächsten Onboarding steht das im Client.
-
„Unsere Ergebnisse sehen jedes Mal anders aus.“
Einen Output-Vertrag mit Pflichtfeldern definieren. Der Agent liefert nur ab, wenn alle Felder belegt und Quellen angegeben sind.
-
„Ein Kollege hat schon etwas Ähnliches gebaut.“
In der Library suchen, den Skill forken, die eigenen Quellen und Rollen anpassen. Verbesserungen könnt ihr an das Original zurückgeben.
-
„Der Agent darf das auf keinen Fall selbst absenden.“
Die Aktion als bestätigungspflichtig markieren oder ganz aus der Rolle entfernen. Texenda blendet sie aus und blockiert sie beim Aufruf.
-
„Der Prozess hat sich geändert.“
Eine neue Version des Playbooks anlegen, Tests laufen lassen, veröffentlichen. Alte Runs bleiben mit ihrer damaligen Version nachvollziehbar.