Wie man auf dem gelben Ziegelweg dem Tod entgeht – Die App-Layer ist noch nicht tot

• Unter Gründerinnen und Gründern verbreitet sich die Sorge, dass die AI-App-Layer von großen Labs wie OpenAI und Anthropic vereinnahmt wird. Doch die App-Layer ist keine einheitliche Chance, sondern eine Struktur, die sich in den „Yellow Brick Road“ und den „Rest of Oz“ aufteilt.
• Der Yellow Brick Road ist der horizontale Bereich, in dem sich die Qualität allein durch Leistungssteigerungen des Modells selbst verbessert, etwa bei Codegenerierung, Schreiben oder Bilderzeugung — also genau der Pfad, in den die Labs enorme Ressourcen investieren.
• Der Rest of Oz ist der Bereich, in dem bei vertikalen, mehrstufigen Workflows mit mehreren Freigaben das Scaffolding oberhalb des Modells über Zuverlässigkeit und Compliance entscheidet — hier gibt es Chancen für Startups, die Kundenschnittstelle zu besitzen.
• Schon die Ankündigung von großen Forward-Deployed Joint Ventures von OpenAI und Anthropic zur Enterprise-Anpassung deutet darauf hin, dass sich nicht alle Probleme allein mit einem generalisierten AI-Coworker lösen lassen.
• Die nächste Generation von Enterprise-Software wird „off the road“ entstehen; Modelle sind austauschbar, aber das System of Work ist es nicht — genau das ist die zentrale Verteidigungslinie.

---

Kernfrage und Annahmen

• Die wiederkehrende Frage von Gründerinnen, Gründern und Bewerberinnen oder Bewerbern lautet: „Werden OpenAI und Anthropic alles töten, und bleibt in der AI-App-Layer überhaupt noch etwas zu bauen?“
• Manche ziehen daraus den Schluss, dass man einem dauerhaften Platz in der Unterschicht nur innerhalb großer Labs oder an der Frontier wie Robotik oder Hardtech entgehen kann.
• Der Autor bewertet das aus maximalistischer AI-Perspektive als „zur Hälfte richtig“: Es stimmt, dass Labs große Teile der App-Oberfläche absorbieren werden.
• Entscheidend ist jedoch, dass die App-Layer keine einheitliche Gelegenheit ist — die richtige Einordnung lautet: Befindet man sich auf dem Yellow Brick Road oder irgendwo anders in Oz?

The Yellow Brick Road — der Weg, den die Labs gehen

• Das Muster besteht darin, an ein leistungsfähiges Modell off-the-shelf Konnektoren wie G Drive, Slack, Salesforce, Notion oder GitHub anzuschließen und darauf eine Agent-Orchestrierungsschicht zu setzen.
• Warum dieses Muster riskant ist: Die Labs machen mit Cowork und Codex bereits genau dasselbe.
  • Sie besitzen das Modell → bessere Margen, mehr Kontrolle und Preissetzungsmacht im Downstream.
  • Sie haben die Freiheit zu Architekturentscheidungen, die das Produkt erfolgreich machen — bisher wurde bewusst das Muster „model + tool calls“ gewählt, und das passt exakt zu horizontalen Low-Level-Aufgaben auf dem Weg.
• Selbst wenn ein Startup Codex oder Claude Code bei der Leistung übertrifft, verfügen die Labs über gewaltige Distribution und den stärksten Markenhalo im AI-Bereich.
• Eine AI-App-Firma, die mit derselben Konnektorkombination, ohne Sub-Agenten oder Konfiguration und ohne Distribution dieses Playbook kopiert, befindet sich auf einem „Weg, der nirgendwohin führt“.

The Rest of Oz — die Chance für Startups

• Gemeint ist der Bereich, in dem Modelle zu Agent-Erlebnissen verwoben werden, und zwar über ein komplexes Netz aus Tools, Automatisierung und Integrationen; meist führt das ganz natürlich in die Vertikale.
• Dort kann man sich auf mehrstufige Aufgaben mit mehreren Beteiligten konzentrieren, die eine horizontale Plattform nicht erreicht.
  • Kontext wird systemweit gesammelt und dann an mehrere Menschen mit schrittweiser Freigabe weitergeleitet.
  • Es braucht die Anbindung an ein oder mehrere Legacy-Systeme, deterministische Ergebnisse sind erforderlich und Unklarheiten sind nicht zulässig.
  • Häufig ist das direkt mit wertvollen Geschäftsergebnissen verknüpft.
• Auch die Labs erkennen den Wert dieses Problems, weshalb sie selbst Outsourced-Configuration-Teams betreiben und es eine Upmarket-Klasse im Reinforcement-Learning-Business gibt.

Warum der Rest von Oz nicht vom Zauberer vereinnahmt wird

• Data and learning flywheels (Daten- und Lern-Flywheels)

  • Implizite Branchennormen, undokumentierte Standards und Tribal Knowledge aus den Köpfen der Fachleute existieren nicht im offenen Web und stehen daher nicht im Trainingssatz.
  • Zwei Flywheels wirken übereinander:
    • across-customer: Muster, die sich ansammeln, wenn man Varianten desselben Problems bei vielen Kunden sieht
    • within-customer: Gründe für bestimmte Entscheidungen, implizite Ausnahmen und unternehmensspezifische Erfahrungsregeln
  • Ein Unternehmen, das 100 juristische Redlines, 1.000 Insurance-Underwritings oder 10.000 SDR-Kampagnen durchlaufen hat, internalisiert eine Problemgestalt, die ein Neueinsteiger mit einem gerade erst gestarteten Agenten nicht reproduzieren kann.
  • Der Hauptgrund, warum horizontale Agenten keine identische Lerninfrastruktur aufbauen können, ist UX — nur vertikale Player können die Workflow-Oberfläche präzise gestalten.
  • Eval-Sets, gelabelte Outputs und Taxonomien für Edge Cases sammeln sich als vertikal spezialisierte Daten-Flywheels an und werden zum Treibstoff für Fine-Tuning.

• Managing model variability and complexity (Umgang mit Modellvariabilität und -komplexität)

  • Labs betreiben intern bereits modellweises Routing und Ensembles pro Anfrage, doch vendorübergreifendes Routing, die Bewertung konkurrierender Modelle und der Einsatz von Open-Source-finetunten Modellen in engen Domänen sind ihnen nicht möglich.
  • Ein Rest-of-Oz-Unternehmen wählt für jede Teilaufgabe das beste Modell aus dem gesamten Modellmarkt, nicht nur aus dem Portfolio des eigenen Mutter-Labs.
  • Bei jedem Upgrade übernimmt es die „Arbeiten, die niemand machen will“: Evals neu ausführen, Prompts auf kundenspezifische Edge Cases neu kalibrieren und Rollouts so ausspielen, dass die Produktion nicht bricht.
  • Das Lab verkauft nur das nächste Modell und sagt „migriert“; das Rest-of-Oz-Unternehmen absorbiert die Migration und bietet dem Kunden die beste Intelligenz des Gesamtmarkts plus Kontinuität bei Upgrades.

• Cost optimization (Kostenoptimierung)

  • Alle Queries mit Opus 4.7 laufen zu lassen, ist der schnellste Weg zu negativem Bruttogewinn.
  • Die besten Rest-of-Oz-Unternehmen routen Modelle nach Tiers:
    • Frontier-Modelle für die schwierigsten Aufgaben
    • Mid-Tier für die meisten Aufgaben
    • kleine Custom- oder finetunte Modelle für qualifizierte Teilbereiche
  • Manche Unternehmen betreiben darüber hinaus eigenes Post-Training, optimiert für den engen Ausschnitt, der Kundinnen und Kunden wirklich wichtig ist, und serven so zu einem Bruchteil der Kosten von Frontier-APIs.
  • Wenn ein Lab eine Preisuntergrenze als „Mindestintelligenz für X Dollar“ setzt, dann verkauft ein Rest-of-Oz-Unternehmen das Gegenteil: die geringsten Dollar-Kosten für genau das Intelligenzniveau, das der Workflow real benötigt.

• Governance (Governance)

  • Es liegt erheblicher Wert darin, zur Control Plane dafür zu werden, wie Kundinnen und Kunden AI in dieser Vertikale betreiben — dort laufen Berechtigungen, Audits, die Fähigkeiten der Agenten und ihre tatsächlichen Handlungen zusammen.
  • Eine solche Control Plane besteht aus je nach Branche und Funktion vollkommen unterschiedlichen Use-Case-spezifischen Guardrails.
  • Weil Tools, Workflows und Daten end-to-end kontrolliert werden, lassen sich deterministische Ergebnisse liefern, die für horizontale Tools schwer erreichbar sind.
  • Diese Unternehmen absorbieren regulatorische Komplexität anstelle des Endkäufers:
    • Recht: FRCP und anwaltliche Standesregeln
    • Gesundheit: HIPAA
    • Finanzen: SEC und FINRA
    • Versicherung: einzelstaatliche Versicherungsregulierung usw.
  • Ein CIO will einen Partner, der für die Compliance der bereitgestellten Agenten vertraglich einsteht.

• Gemeinsames Fazit: Fokus

  • Ob Vertikale wie Versicherung, Recht oder Accounting oder tief ausgeführte Funktionen wie Vertrieb, Customer Support oder Finance: Es braucht ein Team, das sich den Workflows, Edge Cases und Regulierungen einer klaren Kundengruppe verschreibt.
  • Labs können das nicht leisten, weil sie strukturell für alle überall da sein müssen — entweder überall sein oder eine Sache richtig gut machen.

Fallbeispiel Sales — Praxistipps von 11x-CEO Prabhav Jain

• Focus on outcomes (Auf Ergebnisse fokussieren)

  • Der taktische Weg zu einem lab-resistenten Unternehmen beginnt bei einem konkreten Ergebnis, das dem Kunden wirklich wichtig ist — bei 11x etwa Pipeline-Generierung.
  • Jede Aktivität wird in Tasks zerlegt → was agentisch ist und was nicht, was tiefe Domain-Einsicht braucht und was nicht.
  • In Workflows mit mehreren Stufen, schmutzigen Inputs, schwer interpretierbaren Zuständen und realen Restriktionen reichen bessere Modelle allein nicht; es braucht klassisches Software Engineering, und auf dieser Oberfläche haben Labs keinen Vorteil.
  • Beispiele für Tasks, die 11x bearbeitet:
    • Lead-Prospecting auf Basis kundenspezifischer Signale, Lead Enrichment, tiefgehende Account-Recherche
    • CRM-Kontext-Fetcher, kanalbezogene Message-Generatoren, Agenten zur Lead-Qualifizierung, Systeme für E-Mail-Deliverability
  • Aufgabe eines App-Unternehmens ist es, Domänenwissen, das in allgemeinen Trainingsdaten nicht vorkommt, an den richtigen Stellen in den Workflow in das Modell einzuspeisen — und das akkumuliert.
  • Skills veralten durch die geschäftliche Weiterentwicklung ständig, daher ist die Fähigkeit, Workflow und Kontext weiterzuentwickeln, selbst der Wettbewerbsvorteil.
    • Beispiel: Seit AI-geschriebene E-Mails auftauchen, verändert sich das Nutzergefühl im Monatsrhythmus; Agenten müssen sich kontinuierlich an die Marktdynamik anpassen.
    • In den letzten Monaten stieg die positive reply rate um das Vierfache, und es wurde für Kunden eine Pipeline im Wert von hunderten Millionen Dollar erzeugt.

• Work on problems where complexity is high (An Problemen mit hoher Komplexität arbeiten)

  • Echter Geschäftswert wird bei komplexen Problemen freigesetzt, sonst bleibt man ein thin wrapper.
  • GTM-Beispiel: Schon die einfache Regel „Kontaktiere keine Kontakte in Unternehmen, die bereits Kunden sind“ ist in der Praxis hochkomplex.
    • Im CRM kann es Domain-Mappings geben, Unternehmen mit Dutzenden Tochtergesellschaften, Fälle, in denen nur die Domain der Muttergesellschaft erfasst ist, oder veraltete Matching-Felder in Salesforce — und schon landet ein Cold Pitch beim CRO eines Bestandskunden.
  • Reale Daten sind schmutzig, und weder Menschen noch Modelle lösen das auf magische Weise — es braucht zweckgebaute Agenten, die auf die konkrete Form des Problems hin entwickelt wurden.
  • Laut den Daten von 11x sind Qualität und Frische der eigenen Daten höher als beim Kunden, weshalb standardmäßig eine Verankerung in den eigenen Daten erfolgt.

• Guardrails — nicht das Verhindern schlechter Dinge, sondern der Kern, für den Kunden zahlen

  • Guardrails werden massiv unterschätzt; selbst innerhalb desselben Produkts braucht jeder Use Case eigene.
  • Regulierter Financial Services Prospecting und Mid-Market-SaaS-Kunden verlangen unterschiedliche Garantien, und das wirkt sich darauf aus, wie Agenten schreiben, wen sie kontaktieren, auf welche Daten sie zugreifen, was sie im Gespräch sagen und wie Entscheidungen geloggt werden.
  • Ein One-Size-Fits-All-System bricht zusammen; nötig sind use-case-spezifisches Design, kundenspezifische Konfiguration und kontinuierliches Auditing.
  • Deshalb betreibt man FDEs (Forward Deployed Engineers) und technische Deployment-Strategen, die auf Kundenanforderungen hin tunen.
  • Beispiel aus einer F1000-Institution:
    • Es ging um consent-basiertes Outbound-Voice für eine große Zahl von SMB-Kunden.
    • In frühen Iterationen war die Pickup-Rate niedrig → das System lernte schnell, wie man SMB-Inhaber in den ersten zehn Sekunden eines Gesprächs aktiviert.
    • SMB-Inhaber verhalten sich anders als große B2B-Einkäufer oder Konsumenten; inzwischen entstehen in diesem Segment an einem Tag mehr Verkaufschancen als zuvor das Vertriebsteam des Kunden in einem Monat.

Fallbeispiel Insurance — FurtherAI-CEO Aman Gour

• Bei der wiederholten Einführung von AI in reale Versicherungsprozesse ist er immer wieder auf dieselbe Annahme gestoßen — „Das Modell ist die Intelligenz, und der Workflow ist nur Scaffolding“ — und wurde in der Zusammenarbeit mit Carriern zunehmend davon überzeugt, dass das Gegenteil gilt.
• In der Versicherung liegt ein großer Teil der Intelligenz im Workflow selbst.
  • Selbst wenn zwei Carrier denselben Pfad (submission → review → quote → bind) verwenden, liegt der Unterschied in allem dazwischen:
    • Welche Risiken werden eskaliert?
    • Welche Loss-Signale sind relevant?
    • Welche Seite gewinnt, wenn Appetite-Regeln in Konflikt geraten?
    • Wann braucht es menschliche Freigabe, wann werden externe Daten abgefragt und wie wird die finale Entscheidung dokumentiert?
  • Diese Logik steckt nicht an einer sauberen Stelle in einer Rules Engine, sondern ist über SOPs, Manager-Reviews, Underwriting-Philosophie, carrierspezifische Appetite und jahrelange operative Erfahrung verteilt; vieles davon ist nicht in einer Form dokumentiert, die ein Modell lesen könnte.
• Das Ergebnis ist weder ein reiner Agent, der jedes Mal bei null schlussfolgert, noch ein starrer Workflow, der zerbricht, sobald die Realität schmutzig wird, sondern agentic workflows.
  • Workflow → Wiederholbarkeit, Auditierbarkeit, Kostenkontrolle
  • Agent → Umgang mit Variabilität, Erholung, wenn der Happy Path zerbricht
  • Human-in-the-loop → Urteilsentscheidungen, bei denen Verantwortung zählt
• An Day 1 steht die Automatisierung manueller Arbeit; mit der Zeit wird jede Eskalation zum Signal, jede Ausnahme zum Feedback und jede menschliche Korrektur zum Hinweis auf eine Lücke im Runbook — der Workflow entwickelt sich zur operativen Erinnerung des Carriers.
• Labs werden weiter bessere Modelle und bessere allgemeine Agenten veröffentlichen, aber welches Konto eskaliert wurde, welches Risiko abgelehnt wurde und warum ein Underwriter die Appetite-Guideline überstimmt hat und damit richtig lag, lässt sich nur lernen, wenn man lange genug in der Produktion des Carriers bleibt.
• „Nicht der an Day 1 gelaunchte Workflow ist der Burggraben, sondern die Loops, die Produktionseinsatz über die Zeit erzeugt.“

Drei Tests, um zu prüfen, ob man zum Rest of Oz gehört

• The tools-and-steps test (Tool- und Schrittetest)

  • Wie viele Schritte umfasst die Aufgabe, und wie komplex sind die unterstützenden Tools?
  • Vergleich:
    • Horizontale AI-Suche (quer durch Google Drive): 1 Schritt, 1 Tool, tolerantes Ergebnis — wenn es falsch ist, fragt man noch einmal.
    • Juristische Redlines (Abgleich mit Präzedenzfällen einer Kanzlei über drei Jahre): Dutzende Schritte, viele Tools, ein Output, der Partner-Review bestehen muss und womöglich vor Gericht angefochten wird.
  • Beides sieht aus wie „ein Agent bei der Arbeit“, aber nur eine Seite erfordert tiefe Software, die ein fokussiertes Team über Jahre baut.

• The system test (Systemtest)

  • Baut man ein System, durch das der Kunde seine Arbeit schleust, oder nur ein Tool auf einem bereits existierenden System?
  • Ein System besitzt Datenerfassung, Governance und Ausführungsprotokolle end-to-end und ist das, worauf der Kunde zeigt, wenn er sagt: „Hier passiert die eigentliche Arbeit.“
  • Ein Tool fügt einem bereits laufenden Workflow nur Intelligenz hinzu; damit lässt sich Umsatz erzielen, aber es ist ein Bereich, den Labs übernehmen können.
  • Hoher ACV ist oft ein Signal für ein System, aber keine Garantie — entscheidend ist, ob Kunden Ihr Tool noch brauchen, selbst wenn ein Lab direkt ein Konkurrenzprodukt auf den Markt bringt.

• The hedge fund / P&L test (Hedgefonds-/P&L-Test)

  • Die Leistung von Labs wird an Benchmarks gemessen, die Leistung des Rest of Oz am P&L des Kunden.
  • Kunden interessieren sich nicht für SWE-Bench- oder MMLU-Scores — sie schauen darauf, ob der Agent Deals abgeschlossen, Verträge korrekt redlined oder die richtige Police gebunden hat.
  • Kunden, die auf workflow-spezifische Ergebnisse fixiert sind → Rest of Oz; Kunden, die für allgemeine Fähigkeiten zahlen → ein Claude- oder Codex-Seat reicht aus.
  • Die besten Agent-Businesses müssen wie Hedgefonds über Alpha konkurrieren, das am P&L des Kunden gemessen wird.

Beide Seiten können gewinnen

• Auch auf dem Yellow Brick Road wird es riesige Gewinner geben — die Labs besitzen die Modelle und auch die Distribution der horizontalen Tools, die sie selbst entwerfen.
• Die Gewinnbedingung im Rest of Oz ist der Besitz des System of Work — also der Oberfläche, auf der die Arbeit eines Unternehmens tatsächlich ausgeführt und Daten erfasst werden.
  • Besitz von Datenerfassung, dem Action-System des Workflows und Governance
  • Je stärker komplexe Workflows in einer Vertikale reifen, desto mehr verdichten sie sich zu einer zentralen Erfahrung, von der Kunden abhängen.
  • Wenn neue und alte Modellgenerationen erscheinen, wird das Unternehmen zur Schicht, die sie integriert und ausliefert.
  • Modelle sind darunter fungibel, das System of Work jedoch nicht.
• Die nächste Generation von Enterprise-Software wird „off the road“ gebaut.