Wie man ein AI-native Startup aufbaut

• Ein neues Betriebsmodell, bei dem Gründer sich auf die Produktverbesserung konzentrieren, während AI nachts wiederkehrende Aufgaben erledigt; die eigentliche Veränderung liegt nicht in der Zeitnutzung, sondern in der Geschwindigkeit, mit der ein Unternehmen lernt, iteriert und sich weiterentwickelt
• Ein AI-natives Unternehmen verändert sein Betriebsmodell selbst: Wenige Menschen müssen weniger koordinieren, Agenten führen repetitive Arbeiten aus, und Menschen konzentrieren sich auf Richtung, Geschmack, Beziehungen, Validierung und Verantwortung
• Der Übergang verläuft in den Schritten: Arbeit kartieren, ein Kontextsystem aufbauen, die einfachste Automatisierung wählen, wiederkehrende Arbeit in Skills überführen, Evals schreiben, die Qualität beurteilen, und eine wöchentliche Verbesserungsschleife ausführen
• Modelle werden jeden Monat ausgetauscht und verbessert und ähneln sich dadurch zunehmend; der eigentliche unternehmenseigene Vermögenswert ist daher das Betriebssystem wie Kontext und Evals
• In einer Umgebung, in der alle dieselben Modelle nutzen, ist der echte Burggraben Disziplin, also die Konsequenz, jede Woche Arbeit zu kartieren, Kontext aufzubauen, Evals zu schreiben und die Schleife zu drehen

---

Kontrast zwischen zwei Startups

• Vergleich zweier Unternehmen, die im selben Monat im selben Markt gegründet wurden, um 9 Uhr morgens
  • Im ersten Unternehmen bearbeitet der Operations Lead aufgelaufene Support-Tickets, der Analyst erstellt das Dashboard der Vorwoche neu, und der Gründer steckt während des Stand-ups in einem Kundencall fest, den niemand lösen konnte – alle sind damit beschäftigt, die Probleme von gestern zu bereinigen, und das Produkt stagniert
  • Im zweiten Unternehmen haben Agenten all das über Nacht erledigt – Ticket-Klassifizierung, Dashboard-Aktualisierung und das Herausarbeiten von Abwanderungsrisiken (churn risk) aus Gesprächen sind abgeschlossen, und der Gründer behebt bereits Probleme und verbessert mit dem Team das Produkt
• Der Kernunterschied ist die Lerngeschwindigkeit: Das zweite Unternehmen lernt jeden Tag schneller, und dieser Hebel akkumuliert sich über Wochen, Monate und Jahre wie Zinseszins

Schritt 1 – Die Arbeit kartieren (Map The Work)

• Alle wiederkehrenden Aufgaben der letzten zwei Wochen auflisten – Notizen aus Kundengesprächen, Lead-Recherche, Outbound-Entwürfe, Support-Klassifizierung, Produkt-QA, Onboarding, Release Notes, Investoren-Updates, wöchentliche Metriken, Bug-Reproduktion, Recruiting-Screening, Rechnungsprüfung, Wettbewerbsmonitoring usw.
  • Wenn etwas wiederkehrt, ist es ein Kandidat zum Kodifizieren; in den Kalendern von Gründern finden sich meist 20 bis 40 solcher Punkte
  • Wenn ein frühes Team ehrlich auflistet, entdeckt es meist bereits 10 bis 15 Tätigkeiten, die schon Routine waren

• Nach Autonomiegrad klassifizieren

  • L1 ist nur für Menschen – strategische Entscheidungen, finale Einstellungen, große Rückerstattungen, rechtliche Unterschriften, Kommunikation mit dem Board
  • L2 ist von AI vorbereitet, von Menschen freigegeben – Entwürfe für Investoren-Updates, Redlines in Verträgen, Überarbeitung der Pricing-Seite, Support-Makros
  • L3 ist von AI ausgeführt, von Menschen überwacht – Inbound-Klassifizierung, Routing von Meeting-Notizen, Lead-Enrichment, Testgenerierung
  • L4 ist autonom innerhalb klarer Grenzen – Wettbewerbsmonitoring, nächtliche Berichtserstellung, Extraktion von Rechnungen bekannter Anbieter, einfache Anomalieerkennung

• Langweilige Workflows gewinnen meist

  • Statt plausibel klingender Aufgaben wie einem wöchentlichen Strategie-Memo wird Support-Tagging, das täglich wiederkehrt, zehnmal häufiger ausgeführt, gewinnt mehr Zeit zurück und liefert saubere Ground-Truth-Daten – Frequenz schlägt Prestige
  • Die ersten Zielaufgaben sind häufig, messbar, reversibel und mit einem echten Engpass verbunden

• Aufgaben, die nicht automatisiert werden sollten

  • Seltene, unklare, vertrauenskritische oder instabile Aufgaben werden ausgeschlossen
  • Das Team von C.H. Robinson schob die Klassifizierung von 10.000 E-Mails pro Tag auf L4, kehrte aber zu L2 zurück, weil Aufsicht unmöglich wurde – das Volumen verdeckte die Kosten von Fehlklassifizierungen
  • Wenn man nicht erklären kann, wie ein gutes Ergebnis aussieht, ist die Aufgabe nicht bereit zur Kodifizierung; wenn ein einzelner falscher Output eine Kundenbeziehung beschädigen kann, sollte man langsam vorgehen

• Startaufbau

  • Mit einer Seite und drei Workflows beginnen – persönlich (Inbox-Klassifizierung, Daily Brief, Entwurf für Investoren-Update), kundenseitig (Gesprächszusammenfassung, Ticket-Klassifizierung, Lead-Enrichment), intern (Testgenerierung, Rechnungsextraktion, narrative Darstellung der Wochenmetriken)
  • Zu viele gleichzeitige Experimente zerstreuen die Aufmerksamkeit und führen zum häufigsten Fehlermodus: 20 unvollendete Piloten

Schritt 2 – Das Kontextsystem aufbauen (Build The Context System)

• Kontext ist das operative Gedächtnis (operating memory) eines AI-nativen Startups, also der Ort, an dem alles, was das Unternehmen über sich weiß, so gespeichert wird, dass Agenten es lesen können
  • Modelle sind austauschbar, Kontext jedoch ist der echte unternehmenseigene Vermögenswert – er trennt Agenten, die wie Mitgründer arbeiten, von Agenten, die wie verwirrte Zeitarbeitskräfte arbeiten
  • Wenn das Umschreiben von Outputs mehr Zeit kostet als die Prüfung, liegt das Problem nicht im Prompt oder Modell, sondern darin, dass der Agent das Unternehmen nicht gut genug kennt

• Wöchentliche Diagnosemethode

  • Eine repräsentative Aufgabe einem neuen Agenten geben, der nur den Workspace-Kontext hat, und ihn nach den nächsten drei Handlungen fragen
  • Wenn mindestens zwei starke Vorschläge kommen, erfüllt der Kontext seinen Zweck; wenn drei generische Antworten kommen, ist der Kontext zu schwach und durch Prompts nicht zu retten

• Auf einem Git-Repository basieren

  • Mit einem gemeinsamen Git-Repository beginnen, das alle Teammitglieder und Agenten lesen können – Versionsverwaltung, Diffs, von Menschen und Agenten lesbar und nicht an die Runtime eines bestimmten Anbieters gebunden
  • Ein Workspace an Tag 7 kann aus einer einzigen Root mit CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md sowie GTD.md für aktive Arbeit bestehen
  • Bei handgeschriebenen 40 bis 60 Zeilen bleiben – eine dichte Liste dessen, was zu vermeiden ist, ist besser als 400 Zeilen generierter Wortmüll

• Nach Berechtigungsgrenzen aufteilen

  • Mit dem Wachstum: ein gemeinsames Unternehmens-Repository plus funktionsspezifische private Repositories (Sales, Produkt, Engineering, Finanzen, Support) oder projektspezifische bzw. kundenspezifische private Repositories plus gemeinsame Root für das ganze Unternehmen
  • Im Enterprise-Maßstab werden private Git-Server wie selbstgehostetes Gitea, GitHub Enterprise oder GitLab genutzt, um Berechtigungen auf Verzeichnis- oder Repository-Ebene zu vergeben
  • Der interne Harness Goose von Block liest denselben Artefaktstrom mit rollenspezifischen Scopes; sobald diese Scopes verrutschen, werden öffentliche Aussagen und private Deal-Kontexte vermischt – Grenzen sind extrem wichtig

• Drei Datentypen im System

  • Konnektoren – Sammlung externer Daten aus SaaS, API, MCP-Servern, E-Mail, Kalender, CRM, Support, Analytics, GitHub, Linear, Stripe, Warehouse und Dokumenten
    • Jeder Konnektor braucht Identitäten, Scope-Berechtigungen, Audit-Logs und verwaltete Credentials, sonst wird er zum größten Sicherheitsleck – eine IAM-Schicht wie Zitadel sorgt für Identitätsdisziplin
    • Bei der MCP-Codeausführungsarbeit von Anthropic senkte das Filesystem-Muster eines Server-Ordners, das alle Tool-Definitionen vorab lädt, den Kontextverbrauch gegenüber einem Ansatz von rund 150.000 Tokens auf etwa 2.000 Tokens – eine Reduktion um 98,7 %
  • Vom Unternehmen erzeugte Daten – Spezifikationen, Kundenzusammenfassungen, Entscheidungen, Learnings, Projektnotizen, Betriebsregeln, standardmäßig in Markdown
    • Die wichtigste Regel ist die Trennung von Rohdaten (raw) und verdichteten Daten (distilled) – ein Gesprächsmitschnitt ist roh, Entscheidungen aus dem Gespräch, Kundeneinwände, Zuständigkeiten für Follow-ups und Verlängerungsrisiken sind verdichtet und das, worauf Agenten tatsächlich zugreifen
    • Entscheidungslogs sollten append-only bleiben, eine Zeile pro Eintrag, damit die Begründung zusammen mit dem Ergebnis nachvollziehbar bleibt
  • Datenbanken und Streams – dort, wo Quelldaten ohnehin leben, etwa Produktdaten in Postgres, Marketingdaten im Warehouse oder Analytics-Events
    • Nicht blind nach Markdown kopieren, sondern die Datenbank als Quelle beibehalten, Agenten einen eingeschränkten Read-User geben, das Schema in einer agentenorientierten Datei (data-models/postgres.md) dokumentieren und erlaubte Queries bzw. Schreibzugriffe festlegen
    • Standardmäßig so einrichten, dass Agenten keine Produktionsdaten löschen können – der Replit-Vorfall Mitte 2025, bei dem ein Coding-Agent während einer Session eine Produktionsdatenbank löschte, erinnert daran, dass Prompt-Anweisungen keine Sicherheitsgrenze sind

• Erweiterte Version und Quellenverfolgung

  • Ein strukturierter Kontext-Graph – bevor Agenten abfragen, werden Rohdaten in Entitäten und Beziehungen wie Personen, Unternehmen, Einwände, Zusagen, Feature Requests, Verlängerungsrisiken, Follow-ups, Daten, Entscheidungen und Quelllinks überführt
    • Statt Mitschriften nur zu speichern, wird der Inhalt extrahiert und Gespräche derselben Person oder desselben Projekts zu Ketten verbunden, sodass auf „Wie hoch ist das Verlängerungsrisiko bei Vandelay Industries?“ mit Zitaten aus den exakten Aussagen geantwortet werden kann
  • Jede Zusammenfassung muss bis zur Quelle zurückverfolgbar sein (Mitschrift, Ticket, Commit, Rechnung, DB-Zeile) – ohne Quelle häufen sich plausible, aber nicht verifizierbare Zusammenfassungen an, und mit der ersten falschen Antwort bricht das Vertrauen in den gesamten Agenten zusammen
    • Mit Quellen werden Agenten auditierbar, sodass Teammitglieder mit einem Klick die Quelle prüfen und Meinungsverschiedenheiten in Sekunden klären können

Schritt 3 – Die einfachste Automatisierung wählen (Choose The Simplest Automation)

• Nicht alle Workflows zu Agenten machen – die besten Systeme sind eine Mischung aus Skripten, KI-unterstützten Menschen, deterministischen Workflows und Agenten
  • Die Rolle des Gründers ist es, das leichteste Werkzeug auszuwählen, das den Qualitätsmaßstab erfüllt und sich zugleich sicher betreiben lässt

• Einsatz nach Werkzeugtyp

  • Skript – deterministische Schritte (Berichte exportieren, CSV konvertieren, Tests ausführen, Links prüfen, JSON validieren, wöchentliche Metrikpakete formatieren)
  • KI-unterstützter Mensch – Outputs, die vor dem Verlassen des Unternehmens Urteilsvermögen erfordern (Investor-Updates, Gründer-E-Mails, Pricing-Text, Vertragsnotizen)
  • Workflow – wenn die Schritte im Voraus bekannt sind (Call erfassen → zusammenfassen → Einwände extrahieren → CRM-Notiz schreiben → Follow-up erzeugen); Engines wie LangGraph, Temporal, Inngest und Prefect übernehmen Reihenfolge, Retries und Observability
  • Agent – wenn der Pfad nicht im Voraus festgelegt werden kann (Untersuchung eines Production-Bugs, Markt-Research, ungewöhnliche Support-Fälle, verhedderte Kundenkonten)
    • Browserbases bb-Agent ist ein universeller, in Slack eingebundener Agent, der pro Aufgabe unterschiedliche Skill-Dateien und Scope-Berechtigungen lädt – besser, als für jede Aufgabe eigene Bots zu bauen (weil Bots mit der Zeit auseinanderdriften)

• Harness – 6-stufige Sicherheitsschicht

  • Preflight – Kontext und Berechtigungen prüfen, bevor der Agent Tokens verbraucht
  • Plan – Aufgabe zerlegen und die vorgeschlagenen Schritte sichtbar machen
  • Approve – ein Mensch oder ein Bewertungsmodell blockiert schlechte Pläne vor der Ausführung
  • Execute – Aufgabe ausführen
  • Verify – Output mit Tests, Schema, Rubriken und Beispielen validieren
  • Log – festhalten, was passiert ist, damit die nächste Iteration über eine ausführbare Aufzeichnung der richtigen Antwort verfügt

• Guardrails gehören in Code und Konfiguration (nicht in Prompts)

  • Ein Prompt wie „Lösche keine Produktionsdaten“ ist keine Sicherheitsgrenze
  • Nicht verhandelbare Punkte – Ausführungs- und tägliche Kostenobergrenzen, Retry-Limits, maximale Tiefe von Tool-Aufrufen, Scope-Credentials pro Agent, keine Production-Schreibzugriffe ohne Freigabe, kein automatisches Mergen von Code, Kill Switch für die gesamte Flotte
  • Die rekursiven Generierungs-Vorfälle, die 2025 durchgehend auftraten (Agenten riefen immer weiter Child-Agenten auf), verursachten reale Kosten, bevor Harnesses sie einfangen konnten – Limits müssen zur Laufzeit greifen, bevor das Modell überhaupt eine Chance hat, Anweisungen zu ignorieren

Schritt 4 – Skills und Evals codieren (Encode Skills And Evals)

• Bis hierhin war alles Vorbereitung; die eigentliche Maschine, die das Unternehmen jede Woche ein wenig im Zinseszinseffekt wachsen lässt, ist das Codieren wiederkehrender Arbeit als Skills und ihre Bewertung mit Evals
  • Skills sind wiederverwendbare Anweisungen plus Beispiele für wiederkehrende Aufgaben – nachdem man etwas zweimal per Hand ausgeführt hat, wird der sich wiederholende Teil codiert
  • Jeder Skill braucht eine klare Form – Scope, Inputs, zu ladender Kontext, Verfahren, Ausgabeformat, Beispiele, Eskalationsregeln, Owner, Ausführungsprotokoll
  • Wenn nicht festgehalten ist, was hineingeht, was zurückkommt, wann Hilfe angefordert wird und wer es pflegt, dann ist es kein Skill, sondern nur ein langer Prompt

• Beispiel für ein Skill-Template (customer-call-synthesis)

  • Scope: Vertriebs-Calls nach verfügbarer Aufzeichnung / Inputs: Aufzeichnung, Account-Historie, Produktkontext, laufende Opportunities
  • Load: ICP, Pricing, Produkt-Roadmap, Taxonomie für Einwände / Steps: Fakten extrahieren → Einwände clustern → Risiken identifizieren → Follow-up schreiben
  • Output: CRM-Notizen, Kundenbriefing, Feature-Requests, nächste Aktionen / Examples: drei frühere Calls mit erwarteten Notizen
  • Escalate: rechtliche oder Sicherheitsprobleme, Churn-Risiko, Enterprise-Pricing / Owner: Revenue Lead / Eval: 30 frühere Calls mit erwarteten Extraktionsfeldern

• Mit gründerfreundlichen Skills anfangen

  • Kundencall-Synthese – Einwände, Feature-Requests, Risiken, Zusagen und nächste Aktionen aus Rohtranskripten extrahieren
  • Inbox-Triage – Investor-, Kunden-, Hiring- und Ops-Nachrichten sortieren und Antwortentwürfe für die ersten drei Kategorien erstellen
  • Investor-Update – aus Metriken und Entscheidungen den Text formulieren und beide Seiten zitieren
  • Analyse der Pricing-Page – die Live-Seite mit dem aktuellen Log von Kundeneinwänden vergleichen
  • Wöchentliche Metrik-Erzählung – erklären, was sich geändert hat, was kaputtging und was geprüft werden sollte
  • Testgenerierung – aus einer Spezifikation Tests und einen PR-Entwurf machen

• Drei Ebenen von Evals (in dieser Reihenfolge aufbauen)

  • Erstens, manuell gelabelte Ground Truth – Menschen markieren an realen Beispielen, wie guter Output aussieht
  • Zweitens, deterministische Checks – liefern zum Nulltarif ein klares Urteil (gültiges Schema, Zahlen stimmen mit der Quelle überein, Links lassen sich auflösen, Zitate existieren, Tests bestehen)
  • Drittens, LLM-Bewertung – nur für das, was deterministische Checks nicht abdecken (Textqualität, Tonalität, Übereinstimmung mit dem Briefing); dafür reicht ein kleines, schnelles Modell, das vor vertrauenswürdigem Einsatz aber mit von Menschen markierten Beispielen kalibriert werden muss

• Fallstudie: Kundencall-Synthese

  • 30 frühere Calls wurden vom Revenue Lead annotiert – wichtige Fakten, Einwände, Risiken, Follow-ups
  • Deterministische Prüfung – Korrektheit von Namen, Vertragswerten und Kalenderwoche des Follow-up-Datums; ob das Briefing wie der Call klingt, bewertet das LLM
  • Nach etwa 50 Durchläufen gehen meist dieselben zwei Dinge kaputt – Speaker-Tracking scheitert bei Calls mit mehr als drei Personen, oder zwei unterschiedliche Einwände werden zu einem zusammengeführt – das wird auf Clusterebene korrigiert und so lange umgeschrieben, bis es konsistent funktioniert

• Fallstudie: Outbound-Lead-Klassifizierung

  • 300 frühere Leads wurden vom Gründer mit yes/no auf ICP-Fit markiert
  • Mechanische Prüfung – existiert das Unternehmen wirklich, lädt die Website, ist die Mitarbeiterzahl eingetragen; den Rest beurteilt ein LLM gegen die ICP-Beschreibung
  • Sobald das Eval steht, können Open-Source-Prompt-Evolution-Loops (GEPA, DSPy) den Klassifizierungs-Prompt über Nacht gegen die Labels umschreiben – der Gründer liest den finalen Prompt nicht, entscheidend ist nur das Eval-Urteil

• Fünf Stufen der Eval-Reife

  • 1. ein Beispiel manuell prüfen → 2) wenige Fälle mit einer formulierten Rubrik bewerten → 3) diese Rubrik auf 20 bis 300 frühere Fälle anwenden → 4) mit einem Holdout-Set testen, das der Agent nie gesehen hat → 5) die Business-Metrik verfolgen, die der Skill eigentlich bewegen sollte

• Nach dem Launch gut bleiben – jede Woche 6 Zahlen

  • Akzeptanzrate, Override-Rate, Kosten pro Run, Cycle Time, Review-Zeit, Anzahl der Vorfälle
  • Die Akzeptanzrate ist entscheidend – liegt sie unter etwa 70 % (kleine Edits zählen als akzeptiert), ist man noch nicht bereit, das Autonomie-Level zu erhöhen
  • Wenn die Akzeptanzrate niedrig ist, ist das Umschreiben des Prompts fast nie die richtige Antwort; meist ist es eines von vier Dingen – mehr Kontext zur Laufzeit hinzufügen, den Scope des Skills enger fassen, funktionierende Beispiele in die Datei aufnehmen oder klare Eskalationsregeln für Fälle schreiben, die der Skill gar nicht hätte übernehmen sollen

Schritt 5 – Das Team AI-native machen (Make The Team AI-Native)

• Der Gründer beginnt zuerst – der schnellste Weg, das Team auf eine neue Arbeitsweise umzustellen, ist, sie live im Kontext des Unternehmens zu zeigen
  • Vorführen: das morgendliche Briefing, das über Nacht aus Kalender, Inbox und Slack gezogen wurde; die Kundensynthese der gestrigen Calls; ein vom Agenten aus der Spezifikation gebauter Test-PR; ein Entwurf des Investor-Updates aus dem letzten Metrikpaket
  • Das Ziel ist Kalibrierung – aus erster Hand sehen, was die Agenten-Schicht kann und was nicht
  • Jack Dorsey arbeitete 2025 jeden Morgen mehrere Stunden selbst mit diesen Tools und stellte danach Block neu auf – das führte zu massiven Effizienz-Restrukturierungen, und die Entscheidungen kamen von Führungskräften, die Agenten selbst verwendet hatten

• Ab Tag eins installieren, Onboarding mit einem Deliverable abschließen

  • Jede Person verlässt die erste Session mit einem noch am selben Tag auslieferbaren Ergebnis (ein bereinigtes Kundenbriefing, ein Support-Makro, ein Test-PR, eine Kritik der Pricing-Page) – Schulungen, die keine echte Arbeit erzeugen, sind in der nächsten Woche vergessen
  • Das Tool Glass von Ramp wuchs in drei Monaten von 20 auf rund 700 tägliche Nutzer, weil jede Onboarding-Session nach der Regel endete, dass ein Skill oder Artefakt der neuen Person zur geteilten Bibliothek hinzugefügt wird

• Die Rolle des Menschen wird größer

  • Menschen entwerfen das System, besitzen die Beziehungen, beurteilen Outputs und tragen Verantwortung; Agenten übernehmen die Ausführung
  • Teammitglieder, die nur enge Aufgaben abarbeiten, sind in diesem Modell exponiert; wer Urteilsvermögen in Anweisungen, Beispiele und Evals übersetzen kann, ist wertvoller als zuvor

• Auch Hiring verändert sich

  • Die Schwelle, eine Rolle zu eröffnen, steigt – ein Teil dessen, wofür früher eingestellt wurde, sind heute Skills; neue Rollen werden nur noch dort geschaffen, wo wirklich ein Mensch gebraucht wird
  • Beim Hiring gibt man statt Trivia ein großes Projekt, das in der vorgegebenen Zeit von Hand nicht fertig würde, und beobachtet, wie Kandidaten Agenten steuern – man achtet auf Urteilsvermögen, Geschmack und die Fähigkeit, den Kurs zu korrigieren, wenn Agenten falsch abbiegen
  • Konkrete Beispiele – Ein Analyst erstellt in 3 Stunden einen echten Report bis hin zu Source Collection, Evidenzextraktion und einem ausgearbeiteten Briefing; ein Engineer repliziert innerhalb eines Tages eine echte Produktoberfläche oder baut ein internes Tool auf Basis einer Spezifikation inklusive Tests; ein Growth-Hire erstellt für 50 bis 100 Unternehmen eine Market Map und einen Kampagnenplan (Scraping, Clustering, Schreiben, Priorisierung) – entscheidend ist, dass all das in der vorgegebenen Zeit nicht manuell fertigzustellen ist

Schritt 6 – Das Startup als Feedback-Loop betreiben (Run As A Feedback Loop)

• AI-native Startups verbessern ihr Betriebssystem jede Woche – zurück zum Anfang und noch einmal von vorn
  • Was das Review behandeln sollte – was Agenten erledigt haben, wo Menschen eingegriffen haben, fehlgeschlagene evals, fehlender Kontext, Skills, die eingegrenzt werden müssen, Workflows, die eingestellt werden sollten, und Workflows, deren Autonomiegrad erhöht werden sollte

• Zwei Loops gleichzeitig ausführen

  • Inner Loop – bestehende Arbeit verbessern (Kosten pro Ausführung ↓, Cycle Time ↓, Incidents ↓, Review-Zeit pro Artefakt ↓)
  • Outer Loop – Folgendes erkunden (neue Kundensegmente, Produktideen, Preisänderungen, Partnerschaften, Bewegungen von Wettbewerbern, regulatorische Änderungen, Churn-Risiken); Background-Agenten liefern rund um die Uhr Kandidaten, und Menschen wählen aus, was weiterverfolgt wird

• Softwarefabrik (der größte Teil des Inner Loop)

  • Menschen schreiben Spezifikationen und Tests, Agenten implementieren danach; deterministische Checks laufen selbstständig, und vor dem Merge prüft ein Mensch
  • Mit Bereichen beginnen, in denen die Akzeptanzkriterien klar und der Wirkungsradius klein ist – Testgenerierung, Dependency-Upgrades, Migrationen, interne Tools, Integrations-Scaffolds, QA-Skripte, automatische Sicherheits-Fixes
  • Zwei harte Regeln – nichts wird automatisch gemergt, kein Agent schreibt in Production
    • Sogar Cursor behält trotz groß angelegter autonomer Cloud-Agenten bis Anfang 2026 ein menschliches Review-Gate vor dem Merge bei – dieses Gate ermöglicht es, alles andere sicher zu skalieren

• System zum Lernen aus dem Markt (Outer Loop)

  • Gesprächsprotokolle, Extraktion von Einwänden, Clustering von Feature-Requests, Wettbewerbsbeobachtung, Beobachtung von Nutzungsänderungen, Lesen von Support-Mustern, Analyse verlorener Deals
  • Erkenntnisse in Hypothesen umwandeln und dann die stärksten testen – Kundengespräche, Landing-Page-Tests, Produktexperimente, neue Queries auf Daten
  • Agenten machen Vorschläge, Menschen treffen die Auswahl – wenn man Agenten sowohl Vorschläge als auch Entscheidungen in der Strategie überlässt, landet man bei unverbindlichem Konsens oder optimiert hügelsteigend die Kennzahl, die sich am leichtesten verbessern lässt

• Der Kern unternehmensweiter Selbstverbesserung = die Fähigkeit, evals zu schreiben

  • Hunderte Beispiele manuell als gut/schlecht labeln, daraus evals bauen und sie an den Prompt-Evolutions-Loop anschließen – Frameworks wie GEPA und DSPy lassen kleine Reflexionsmodelle Prompt-Mutationen vorschlagen, evals ranken diese auf dem gelabelten Datensatz, der Gewinner wird ausgerollt, dann wiederholen
  • Gründer schreiben evals und lesen Fehlercluster, nutzen oder lesen aber die evolvierten Prompts nicht
  • Der Engpass ist nicht die Fähigkeit der Agenten, sondern ob man den Maßstab für „gut“ kodieren kann – Coding hilft, ist aber nicht der Flaschenhals; Domänenexpert:innen, die Outputs zuverlässig als gut/schlecht markieren können, können den gesamten Loop betreiben
  • Evals sind das tragende Kernartefakt, und in dem Moment, in dem das Schreiben von evals stoppt, stoppt auch das Zinseszinzwachstum des Unternehmens

Fazit

• Man braucht weder Genies noch ein großes Team, sondern die Disziplin, Arbeit zu kartieren, Kontext aufzubauen, evals zu schreiben und den Loop jede Woche zu drehen – jetzt, wo alle dasselbe Modell nutzen, ist das Betriebssystem die Geheimwaffe