Ein guter KI-Workflow beginnt nicht mit dem neuesten Modell, sondern mit der Frage, ob du überhaupt einen Agenten brauchst. Servus, ich bin Lissy. Heute machen wir eine Landkarte für praktische KI-Arbeit: Wann reicht ein Script, wann nimmst du klassische Automation, wann lohnt sich ein Skill, und wann ist ein echter Agent sinnvoll. Der Auslöser sind frische Open-Source-Projekte aus Coding und Creator-Workflows. Die Lektion gilt aber breiter: für Selbstständige, Gründer, Produktleute und alle, die KI in echte Arbeit bringen wollen.
Fangen wir mit der Sortierung an. Ein Script ist richtig, wenn die Aufgabe stabil ist. Gleicher Input, gleiche Schritte, gleiches Ergebnis. Jeden Morgen eine CSV prüfen, PDFs umbenennen, eine Webseite neu bauen. Dafür brauchst du keinen digitalen Mitarbeiter, sondern etwas, das langweilig zuverlässig läuft.
Eine klassische Automation passt, wenn Dienste verbunden werden und die Logik fest bleibt. Formular rein, CRM aktualisieren, Mail raus. Zapier, Make oder n8n sind dafür gut. Der Haken: Ausnahmen werden schnell hässlich. Sobald ein Kunde drei Sonderfälle in dieselbe Mail schreibt, wächst aus dem sauberen Ablauf ein Kabelsalat.
Ein Skill ist eine wiederverwendbare Arbeitsanweisung für einen Agenten. Welche Dateien lesen, welche Checks laufen, welche Fehler vermeiden, welches Ergebnis liefern. Skills lohnen sich, wenn die Aufgabe jedes Mal anders aussieht, aber deine Methode gleich bleibt: Code reviewen, Research zusammenfassen, Kundenanfragen triagieren.
Ein App-Agent ist sinnvoll, wenn die Aufgabe variabel ist, mehrere Werkzeuge braucht und unterwegs Entscheidungen treffen muss. Recherchieren, Material sammeln, etwas bauen, Ergebnis bewerten, Fehler beheben, neu versuchen. Da wäre ein starres Flussdiagramm zu eng. Aber dann brauchst du klare Regeln: Was darf der Agent allein, wo schaut ein Mensch drauf, und woran erkennt ihr, dass die Aufgabe fertig ist.
Indexio zeigt, wie man so eine Entscheidung sauber trifft. Der Builder hat zuerst Claude Code bei der Arbeit beobachtet. Dabei fiel auf: Viel Zeit und viele Tokens gingen für Regex-Suchen durch die Codebase drauf. Der Agent suchte wieder und wieder in denselben Dateien, bekam viel Text zurück und füllte damit sein Kontextfenster.
Indexio indiziert die Codebase lokal, bietet Suche per MCP an und lenkt den Agenten auf gezielte Lookups. Wenn der Index nichts findet, fällt es auf normale Regex-Suche zurück. Laut Post auf Hacker News sieht der Autor in realen Tests 50 bis 60 Prozent weniger Tokenverbrauch und fast sofortige Lookups statt mehrerer Sekunden pro Suche. Er nennt auch die Grenze: symbol-lastige Workflows können mit klassischer Suche besser fahren.
Der 45-Minuten-Test dafür ist simpel: Nimm ein eigenes Repo, lass deinen Coding-Agenten eine kleine Aufgabe erledigen und speichere Toolcalls oder Verlauf. Dann markierst du die drei häufigsten Suchmuster. Wenn ein Index, eine kleine Dokumentation oder ein Manifest diese Muster gezielter beantworten kann, hast du einen Hebel. Erfolg heißt nicht: neues Tool installiert. Erfolg heißt: dieselbe Aufgabe braucht weniger Suchaufrufe, weniger Tokens und bleibt korrekt.
SoloMCN ist das Gegenstück. Das Projekt macht aus Claude Code eine Art Kurzvideo-Team. Trends einlesen, Material sammeln, Video bauen, Untertitel und Voice vorbereiten, auf Plattformen wie Douyin, Xiaohongshu, Bilibili, YouTube oder X posten. Der README beschreibt genau den Unterschied: keine starre Node-Kette, sondern Jobbeschreibungen und Skills für Claude Code.
Content-Produktion ist voller Ausnahmen. Mal ist das Quellmaterial mies. Mal ist das Voice-Kontingent leer. Mal passt der Schnitt nicht. Ein starrer Workflow müsste jeden Fall vorher kennen. Ein Agent kann eher reagieren, solange er Werkzeuge hat und nicht einfach wild veröffentlicht. Laut GitHub hatte das Repo heute 50 Sterne und wurde am 9. Oktober erstellt. Die Zahl ist weniger wichtig als die Arbeitsform.
Wenn du so etwas testest, mach es klein. Nicht direkt mit echten Accounts posten. Nimm einen Blogpost, ein paar lokale Bilder und gib dem Agenten die Aufgabe: Baue daraus einen 30-Sekunden-Draft. Vorher definierst du drei Gates: keine Veröffentlichung, alle Assets in einen Ordner schreiben, am Ende eine Liste liefern, was manuell geprüft werden muss. Erfolg ist ein brauchbarer Entwurf. Wenn der Agent bei jedem kleinen Fehler nach dir ruft, ist die Aufgabe noch nicht reif. Wenn er sinnvolle Alternativen findet und du nur final auswählst, lohnt sich der Agent eher als ein starrer Flow.
Der nächste Baustein kommt aus Eval Skills und Done is a Claim. Eval Skills will Teams von echten Ausführungsbeispielen zu wiederholbaren Bewertungen führen. Zielgruppen sind Product Manager, Domain Experts, Gründer, Solo Builder und Entwickler. Der Startpunkt ist kein Dashboard. Der Startpunkt sind echte Beispiele: Was war gut, was war schlecht, und warum?
Done is a Claim formuliert dieselbe Haltung härter. Ein Agent sagt, er sei fertig. Dann soll er den Beleg zeigen. Das Repo beschreibt einen Evidence-first Ablauf mit 15 Skills, 18 incident-backed Rules und optionalen Tools für Claude Code und Codex. Die Demo im Research ist schön nüchtern: Wenn der Verifier mit Exit 1 scheitert, aber die Zusammenfassung Erfolg behauptet, bleibt das Receipt trotzdem FAIL. Die Wahrheit hängt am Ergebnis, nicht an der hübschen Zusammenfassung.
Der 60-Minuten-Test: Nimm zehn Beispiele aus einem echten Arbeitsablauf. Fünf sollen als gut gelten, fünf als schlecht. Schreib für jedes Beispiel einen Satz, warum. Dann baust du den ersten Check, der mindestens einen bekannten schlechten Fall findet und einen bekannten guten Fall akzeptiert. Mehr braucht es am Anfang nicht. Keine große Metrikmaschine. Nur eine kleine Belegkette. Wenn diese Belegkette nicht gelingt, gehört der Agent noch nicht in den Betrieb.
Noch ein praktisches Muster ist das Workflow-Repo von truongfelix. Eine Claude-Code-Session startet dort mit einem Ground-Truth-Script. Das Script liest Git-Status, GitHub, Remote-Status, offene PRs, CI und Hintergrundjobs. Erst danach vergleicht der Agent diese Fakten mit dem letzten Handoff. Wenn beides nicht zusammenpasst, wird der Widerspruch sichtbar, bevor neue Arbeit beginnt.
Das ist ein allgemeines Arbeitsprinzip. Erinnerung ist eine Behauptung. Systemzustand ist ein Beleg. Wenn du einen Agenten für Kundenmails, Rechnungen oder Content nutzt, kann er am Anfang die echten Eingänge lesen: offene Mails, Tasks, letzte Rechnungsliste, letzte Veröffentlichung, letzter Fehlerbericht. Dann erst plant er.
Plimsoll ergänzt die Ausführungsseite. Wenn Agenten Code ausführen, reicht es nicht, Sandbox dranzuschreiben. Das Tool gibt eine Isolation-Stufe zurück, etwa process, container, kernel oder vm. Ein Request kann eine Mindeststufe verlangen. Wird sie nicht erreicht, läuft nichts. Die Regel dahinter: Eine Sicherheitsannahme muss maschinenlesbar sein. Sonst ist sie nur Hoffnung.
Meine Entscheidungskarte: Script, wenn der Ablauf stabil ist. Automation, wenn Dienste verbunden werden und Regeln fest sind. Skill, wenn die Methode wiederkehrt, aber der Input variiert. Agent, wenn Entscheidungen, Werkzeuge und Ausnahmen zusammenkommen. Erst klein testen, dann Rechte geben, dann automatisieren.
Mein Schluss für heute: Die beste KI-Entscheidung ist oft die Form der Arbeit. Wenn ihr morgen etwas testen wollt, nehmt eine einzige Aufgabe und sortiert sie in vier Schubladen: Script, Automation, Skill oder Agent. Dann baut nur den kleinsten Test, der diese Zuordnung bestätigt. Wenn euch die Folge geholfen hat, hinterlasst gerne eine Bewertung auf Spotify oder Apple Podcasts. Das hilft mir mehr, als man denkt. Pfiat euch und bis morgen, eure Lissy.