Warum die App-Ebene nicht tot ist
Die Frage, die mir Gründer und potenzielle Mitarbeiter immer wieder stellen: Gibt es überhaupt noch eine KI-Anwendungsebene, die es zu bauen gilt, oder werden OpenAI und Anthropic alles zerstören?
Hinter der Frage steckt eine bestimmte Art von KI-Psychose. Manche Leute sind zu dem Schluss gekommen, dass die einzigen dauerhaften Orte, die der permanenten Unterklasse entgehen, in einem großen Labor oder an der Front im Bereich Robotik, Hardtech oder Ähnlichem liegen – theoretisch alles, „was die Labore nicht anfassen können". Wenn jedes Stück Software bald aufgefressen wird, entweder von Codex oder Claude, die die Arbeit direkt übernehmen, oder von einem zukünftigen Modell, das das, was du gebaut hast, überflüssig macht, dann renn!
Hör zu, ich bin ein genauso großer KI-Maximalist wie fast jeder andere, und ich denke, sie liegen zur Hälfte richtig. Die Labore werden wirklich eine riesige Menge der Anwendungsoberfläche übernehmen. Aber „die Anwendungsebene" ist nicht nur eine einzige homogene Chance. Die richtige Einordnung ist, ob du auf der Yellow Brick Road bist oder woanders in Oz.
Die Yellow Brick Road ist unser Kürzel für den Weg, den die Labore gehen, auf den sie außergewöhnliche Ressourcen konzentrieren. Der Grund, warum die Labore am besten für Probleme wie Codegenerierung, Schreiben oder Bilderstellung geeignet sind, ist, dass diese Probleme mit der rohen Modellfähigkeit besser werden: Jeder Dollar, der für Pre-Training und Post-Training ausgegeben wird, verbessert die Produktqualität. Der Rest von Oz hingegen wird von komplexeren, oft vertikalen Problemen bewohnt, die nicht so einfach sind wie einem Geschäftsanwender ein horizontales Tool mit Zugang zu Standardwerkzeugen und Computernutzung zu geben. Der Wert entsteht weniger aus der rohen Fähigkeit des zugrunde liegenden Modells (obwohl diese immer noch wichtig ist!) als vielmehr aus dem Gerüst darum herum, das die Ausgabe vertrauenswürdig, konform und innerhalb einer bestimmten Branche betriebsbereit macht.
Wir sehen das in Echtzeit, während OpenAI und Anthropic dem Markt effektiv mitteilen, dass sie nicht jedes Problem mit einem generischen KI-Kollegen lösen können. Sie haben massive forward-deployed Joint Ventures angekündigt, um ganze Unternehmen rund um die Konfiguration und Anpassung ihrer Modelle für Unternehmen aufzubauen. Du investierst nicht Milliarden in diese Programme, wenn du denkst, dass die nächste Modellversion das Problem lösen wird.
Wenn du also reich werden willst, indem du KI-Apps baust – meide die Yellow Brick Road und baue woanders in Oz. Hier ist, was wir gelernt haben und was einige unserer Portfoliogründer über das gelernt haben, was funktioniert.
Die Yellow Brick Road
Wenn du ein Unternehmen gründest, ist die Yellow Brick Road der offensichtlichste Weg, aber er ist der gefährlichste. Nimm ein leistungsstarkes Modell, schließe ein paar Standard-Konnektoren an (wie G Drive, Slack, Salesforce, Notion, GitHub) und setze eine Art agentische Orchestrierungsschicht obendrauf. Magie!
Das Problem dabei ist, dass genau das die Labore mit Cowork und Codex tun. Offensichtlich besitzen sie das Modell, was ihnen bessere Margen, Kontrolle und die Fähigkeit gibt, Preisdruck auf alle nachgelagerten Akteure auszuüben. Aber vielleicht am wichtigsten ist, dass sie auch die architektonischen Entscheidungen besitzen, die definieren, wofür ihre Produkte gebaut sind, um sie gut zu lösen. Sie waren bisher bewusst bei dem Muster „Modell plus Tool-Aufrufe", und genau das erfordert die horizontale Arbeit mit wenigen Schritten auf der Road. Selbst wenn ein Startup irgendwie besser abschneiden könnte als Codex oder Claude Code, haben die Labore massive Vertriebsarme und den größten Marken-Heiligenschein im KI-Bereich.
Wenn du ein KI-App-Unternehmen bist, das dieses Playbook mit denselben Connectoren, ohne Sub-Agenten oder Konfiguration darunter und ohne Vertriebskanäle fährst, gehst du wahrscheinlich den Weg ins Nichts.
Der Rest von Oz
Es ist nicht alles Untergang und Finsternis für Startups. Es gibt eine enorme Chance außerhalb der Yellow Brick Road, wo Startups einen klaren Weg haben, ihre Kunden zu besitzen und komplexe Probleme zu lösen.
Diese Unternehmen bauen agentische Erlebnisse, bei denen das Modell durch ein komplexes Netz von Tools, Automatisierungen und Integrationen (lies: Software) verwoben ist, was die meisten dieser Startups standardmäßig vertikal ausrichtet. Sie können sich auf mehrstufige und mehrteilige Arbeit konzentrieren, mit Sub-Agenten für rollen- und vertikalspezifische Aufgaben, die Anthropic und OpenAI mit horizontalen Plattformen nicht erreichen können: Kontext aus Systemen sammeln, dann durch mehrere Menschen leiten, die in verschiedenen Phasen zustimmen müssen. Es geht oft um ein oder mehrere Altsysteme, neigt zu deterministischen Ergebnissen, bei denen Mehrdeutigkeit nicht akzeptabel ist, und ist manchmal an ein wertvolles Geschäftsergebnis gebunden. Die Labore verstehen, wie wertvoll diese Probleme sind: Deshalb bauen sie ihre eigenen ausgelagerten Konfigurationsshops und warum eine ganze Klasse von Reinforcement-Learning-Unternehmen im oberen Marktsegment existiert.
Warum der Rest von Oz nicht vom Zauberer besessen wird
Die Antwort auf das Obige wäre, dass es bisher eine ziemlich schlechte Wette war, gegen die Verbesserung der Modelle/Labore zu setzen. Sie werden sich wahrscheinlich einfach weiter verbessern und irgendwann den Markt dieser Anwendungsebenen-Unternehmen auffressen.
Die Labore werden sich sicherlich verbessern, aber ich würde argumentieren, dass es ein paar Möglichkeiten gibt, wie der Rest von Oz sich im Laufe der Zeit verteidigen kann:
Daten- und Lern-Schwungräder:
Ein Großteil dessen, was du verinnerlichst, befindet sich in keinem Trainingssatz – ungeschriebene Branchennormen, undokumentierte Standards, das Stammeswissen, das in den Köpfen der Praktiker lebt. Nichts davon ist im öffentlichen Web. Keine noch so große Trainingsrechenleistung kann das ersetzen, was es bedeutet, in den Workflows zu sein, in denen dieses Wissen tatsächlich lebt. Hier gibt es zwei übereinander gestapelte Schwungräder: eines kundenübergreifend – Muster, die sich summieren, wenn du mehr Varianten desselben Problems siehst – und eines kundenintern – das „Warum" hinter bestimmten Entscheidungen, die unausgesprochenen Ausnahmen, die eigenen Faustregeln des Unternehmens, die nur durch echte Interaktion mit dem System an die Oberfläche kommen.
Selbst wenn Kundendaten nicht kundenübergreifend verwendet werden können, können Anwendungsunternehmen Mustererkennung über Kundentypen hinweg nutzen und diese nutzen, um die richtige Architektur für zukünftige Probleme zu bestimmen. Ein Unternehmen, das seine Agenten durch hundert juristische Prüfungen, tausend Versicherungszeichnungszyklen oder zehntausend SDR-Kampagnen geschickt hat, hat die Form des Problems so verinnerlicht, dass ein Neueinsteiger dies nicht replizieren kann, indem er zum ersten Mal einen frischen Agenten hochfährt.
Ein horizontaler Agent könnte prinzipiell dieselbe Lerninfrastruktur aufbauen. Der Grund, warum er es nicht tut – abgesehen von purer Fokussierung – ist die UX: Die Erfassung dieser Art von Wissen hängt vollständig von den Workflow-Oberflächen ab, die du dem Benutzer gibst, und vertikale Player können diese Oberflächen genau um das herum formen, was ihr Workflow an die Oberfläche bringen muss. Horizontale Tools können das nicht. Evaluierungssets, gelabelte Ausgaben und Taxonomien für Randfälle können sich zu einem vertikalspezifischen Daten-Schwungrad summieren, das Feintuning ermöglicht, das ein Neueinsteiger ohne vergleichbare Produktionsexposition nicht erzeugen kann. Ob dies möglich ist, hängt von Datenrechten, dem Umfang der angesammelten Produktionsexposition und der Struktur der Kundenverträge ab, aber Mustererkennung findet trotzdem statt.
Verwaltung von Modellvariabilität und -komplexität: Die Labore routen bereits intern – verschiedene Modellklassen für verschiedene Anfragen, Ensembles unter der Haube. Was sie nicht können, ist, zwischen Anbietern zu routen oder das Modell eines Konkurrenten für eine bestimmte Unteraufgabe zu bewerten oder einen Open-Source-Feintune für den engen Bereich zu verwenden, in dem es tatsächlich am besten ist. Das „Rest of Oz"-Unternehmen wählt das richtige Modell für jede Unteraufgabe im gesamten Modellmarkt aus, nicht nur das, was das Mutterlabor ausliefert. Es erledigt auch die Arbeit, die niemand machen will – Evaluierungen bei Upgrades neu durchführen, Prompts für die Randfälle des Kunden neu kalibrieren, Rollouts ohne Unterbrechung der Produktion durchführen – jedes Mal, wenn ein neues Modell erscheint. Die Labore tun das nicht im Namen des Kunden; sie verkaufen dir ihr nächstes Modell und sagen dir, du sollst migrieren. Das „Rest of Oz"-Unternehmen absorbiert die Migration. Was der Kunde bekommt, ist die beste verfügbare Intelligenz im gesamten Markt, plus Kontinuität durch jedes Upgrade.
Kostenoptimierung: Jede Abfrage durch Opus 4.7 zu jagen, ist der schnellste Weg zu negativen Bruttomargen. Die besten „Rest of Oz"-Unternehmen routen über Modellstufen hinweg – Frontier-Modelle für die schwierigsten Aufgaben, mittlere Stufe für die Masse, kleinere benutzerdefinierte oder feingetunte Modelle, wo sie sich das Recht verdient haben, sie zu verwenden. Einige trainieren jetzt darüber hinaus ihre eigenen Modelle nach, optimieren sie für den engen Ausschnitt der Arbeit, der ihrem Kunden wichtig ist, und liefern sie zu einem Bruchteil der Kosten eines Frontier-API-Aufrufs aus. Die Labore bepreisen den Boden: die geringste verfügbare Intelligenz für X Dollar. Das „Rest of Oz"-Unternehmen verkauft das Gegenteil – die niedrigsten Dollarkosten für das spezifische Intelligenzniveau, das der Workflow tatsächlich benötigt. Das ist nur möglich, wenn du genau weißt, welches Niveau jede Unteraufgabe braucht, was die Labore strukturell nicht über jede Vertikale hinweg wissen können. Es übersetzt sich direkt in niedrigere, kontrollierte Preise für Ergebnisse.
Governance: Es gibt einen erheblichen Wert darin, die Kontrollebene dafür zu werden, wie die Kunden KI in dieser Vertikalen betreiben – der Ort, an dem Berechtigungen, Prüfungen, was-der-Agent-tun-darf und was-der-Agent-tatsächlich-getan-hat zusammenlaufen. Diese Kontrollebene ist aus anwendungsfallspezifischen Schutzvorrichtungen aufgebaut, die in verschiedenen Branchen und Jobtypen völlig unterschiedlich aussehen. Weil sie die Tools, die Workflows und die Daten, die der Agent durchgehend berührt, besitzen, können sie deterministische Ergebnisse auf eine Weise liefern, die horizontale Tools nur schwer erreichen. Sie sind auch die Entität, die die regulatorische Komplexität für den Endkäufer absorbiert – FRCP und Anwaltsregeln im Rechtswesen, HIPAA im Gesundheitswesen, SEC und FINRA im Finanzwesen, staatliche Versicherungsvorschriften und so weiter. Ein horizontaler Player kann das nicht glaubwürdig tun, ohne gleichzeitig hundert verschiedene Vertikalen zu werden. CIOs wollen einen Partner, der vertraglich zusichert, dass er die Compliance für die von ihm bereitgestellten Agenten übernimmt.
All das läuft auf dasselbe hinaus: Fokus. Das könnte eine Vertikale sein (Versicherung, Recht, Buchhaltung) oder eine tiefgehend ausgeführte Funktion (Vertrieb, Kundenservice, Finanzen). In jedem Fall erfordert die Arbeit ein Team, das sich intensiv mit einer Kundengruppe beschäftigt – ihren Workflows, ihren Randfällen, ihren Vorschriften. Die Labore sind dafür nicht gebaut. Sie müssen überall sein, für alle, was auch der Grund ist, warum sie überhaupt die Yellow Brick Road gebaut haben. Derselbe Zielkonflikt hält sie vom Rest von Oz fern – du kannst entweder überall gleichzeitig sein oder du kannst in einer Sache großartig sein. Nicht beides.
Vertrieb als Beispiel – praktische Tipps von 11x' technischem CEO
Wie solltest du das in der Praxis betrachten? Hier sind einige praktische Tipps von Prabhav Jain, dem CEO von 11x.
Konzentrier dich auf Ergebnisse
Ein taktischer Weg, um ein Unternehmen aufzubauen, das widerstandsfähig gegenüber den Laboren ist, ist, einfach von einem bestimmten Ergebnis auszugehen, das deine Kunden wirklich interessiert. Für uns war das, Unternehmen dabei zu helfen, mehr Pipeline zu generieren. Von dort aus werden die Fragen taktisch. Welche Aktivitäten wollen wir durchgängig besitzen, die tatsächlich Pipeline antreiben? Zerlege jede Aktivität in Aufgaben. Welche Aufgaben sind agentisch und welche nicht. Welche erfordern komplexe Domäneneinblicke und welche nicht. Die Labore werden ebenfalls Workflows ausliefern, aber wenn der Workflow viele Schritte, unordentliche Eingaben, schwer zu interpretierende Zustände oder reale Einschränkungen hat, bringt dich ein besseres Modell allein nicht weiter. Die Arbeit fällt auf die gute alte Softwareentwicklung zurück, und die Labore haben auf dieser Oberfläche keinen Vorteil gegenüber einem fokussierten Anwendungsunternehmen. Hier sind zum Beispiel einige der Aufgaben, die wir erledigen, einige agentisch, einige nicht: Lead-Prospektion basierend auf benutzerdefinierten Signalen, Lead-Anreicherung, tiefgehende Account-Recherche, Kontextabrufer aus CRM, kanalspezifischer Nachrichtenschreiber, Lead-Qualifizierungs-Agent und E-Mail-Zustellbarkeitssystem. Das sind keine Aufgaben, die man einfach so mit einem einzigen Durchlauf erledigen kann; sie erfordern tiefgehende Technik.
Die entscheidende Erkenntnis in der Oz-Analogie ist, dass etwa die Hälfte jedes realen Workflows, der nicht agentisch ist, keinen Laborvorteil mit sich bringt. Die Labore sind nicht besser als du darin, die deterministische Software unter der Modellebene zu schreiben. Und die Hälfte, die agentisch ist, erfordert immer noch, dass du die Modelle gegen das gewünschte Ergebnis abstimmst, trainierst und einschränkst. Domänenwissen liegt oft nicht in allgemeinen Trainingsdaten. Diese Fähigkeiten werden von Grund auf für die Vertikale oder Funktion aufgebaut und zum richtigen Zeitpunkt im Workflow in das Modell eingespeist. Wenn unsere Agenten einen eingehenden Lead am Telefon qualifizieren, muss ich darauf trainiert sein, was ein gutes Verkaufsgespräch für diese spezifische Branche und diese Persona ist. Das ist Arbeit für das Anwendungsunternehmen, und sie summiert sich.
Noch wichtiger ist, dass diese Fähigkeiten ständig veralten, weil sich Unternehmen weiterentwickeln, so dass deine Fähigkeit, diese Workflows und Kontexte weiterzuentwickeln, zu einem Wettbewerbsvorteil wird. Als wir zum Beispiel unser Produkt für skalierte E-Mail-Ansprache starteten, kamen „KI"-geschriebene E-Mails gerade erst ins Spiel. Spulen wir vor bis heute: Die Leute haben ein feines Gespür dafür entwickelt, welche E-Mails von KI geschrieben sind und welche von Menschen, und entscheidend ist, dass sich dies alle paar Monate ändert. Unsere Agenten müssen sich ständig an die Marktdynamik anpassen, aber genau hier wird der Burggraben gebaut. Tatsächlich sind trotz dieser Dynamik unsere positiven Antwortraten in den letzten Monaten um das Vierfache gestiegen, und wir haben Hunderte Millionen an Pipeline für unsere Kunden generiert.
Arbeite an Problemen mit hoher Komplexität
Komplexe Probleme sind der Ort, an dem echter Geschäftswert freigesetzt wird. Ansonsten wirst du dich dabei ertappen, eine dünne Hülle zu bauen.
Zerlege ein ausreichend komplexes Geschäftsproblem, und Chaos zeigt sich schnell. Hier ist ein Beispiel aus der GTM-Welt, das trivial klingt: Du solltest keinen Kontakt in einem Unternehmen ansprechen, wenn dieses Unternehmen bereits Kunde ist. Das ist alles andere als trivial. Vielleicht hast du die zugehörige Domain des Unternehmens in deinem CRM. Was ist mit Unternehmen mit Dutzenden von Tochtergesellschaften? Was, wenn der CRM-Datensatz die Domain der Muttergesellschaft hat? Was, wenn ein veraltetes Zuordnungsfeld in Salesforce eine kalte Anfrage an den CRO eines bestehenden Kunden sendet? Reale Daten sind chaotisch. Menschen haben damit zu kämpfen. Modelle heben diese Hürde nicht magisch. Ordnung aus diesem Chaos zu schaffen, erfordert zweckgebundene Agenten, die für die spezifische Form des Problems entwickelt wurden, nicht einen universellen Copilot, der auf ein CRM zeigt. Basierend auf den Daten, die wir haben, haben wir tatsächlich festgestellt, dass die Qualität und Aktualität unserer Daten viel höher ist als die unserer Kunden, daher orientieren wir uns standardmäßig an unseren eigenen.
Schutzvorrichtungen dienen nicht nur dazu, schlimme Dinge zu verhindern. Dafür bezahlen dich deine Kunden.
Schutzvorrichtungen werden massiv unterschätzt. Selbst innerhalb desselben Produkts benötigt jeder Anwendungsfall seine eigenen. Für uns verlangt ein regulierter Finanzdienstleistungs-Interessent andere Garantien als ein Mid-Market-SaaS-Kunde, und diese Garantien wirken sich darauf aus, wie der Agent schreiben darf, wen er kontaktieren darf, welche Daten er berühren darf, was er in einem Anruf sagen darf und wie jede Entscheidung protokolliert wird.
Ein Einheitsgröße-für-alle-System bricht unter dieser Varianz zusammen. Schutzvorrichtungen müssen pro Anwendungsfall gebaut, pro Kunde konfiguriert und kontinuierlich geprüft werden, und diese Arbeit liegt eindeutig beim Anwendungsunternehmen. Deshalb haben wir FDEs und technische Bereitstellungsstrategen, die für die Anforderungen jedes Kunden optimieren müssen. Ein Beispiel: Wir haben mit einer F1000-Institution zusammengearbeitet, um konsentierte Outbound-Akquise per Sprache bei ihrem großen KMU-Kundenstamm durchzuführen. Die ersten paar Iterationen hatten niedrige Abheberaten – wir mussten schnell iterieren und lernen, wie wir dieses spezifische Publikum in den ersten 10 Sekunden des Anrufs zur Interaktion bewegen können. KMU-Inhaber verhalten sich völlig anders als große B2B-Käufer oder Konsumenten. Wir generieren jetzt an einem Tag mehr Vertriebschancen für sie als ihr gesamtes Vertriebsteam für dieses Segment in einem Monat.
Versicherungen als Beispiel – praktische Tipps von FurtherAIs CEO
Vertrieb ist ein Beispiel. Versicherungen sind ein weiteres, und sie machen denselben Punkt aus einem anderen Blickwinkel. Hier ist, wie Aman Gour, CEO von FurtherAI, über das Bauen abseits der Road denkt:
Als wir begannen, KI in realen Versicherungsbetrieben einzusetzen, hörten wir immer wieder eine bestimmte Annahme: Das Modell ist die Intelligenz, und der Workflow ist nur ein Gerüst darum herum.
Je mehr Versicherer wir begleiteten, desto überzeugter wurden wir, dass dies falsch herum ist.
In der Versicherung lebt ein Großteil der Intelligenz im Workflow selbst. Zwei Versicherer können eine Einreichung durch denselben Weg laufen lassen: Einreichung, Prüfung, Angebot, Bindung. Aber der Weg ist der einfache Teil. Was die beiden Versicherer unterscheidet, ist alles darin: welche Risiken eskaliert werden, welche Verlustsignale wichtig sind, welche Risikobereitschaftsregel gewinnt, wenn zwei davon kollidieren, wann ein Mensch abzeichnen muss, welche externen Daten einbezogen werden und wie die endgültige Entscheidung dokumentiert wird.
Diese Logik lebt nicht in einer einzigen sauberen Regel-Engine. Sie ist verteilt auf SOPs, Managerprüfungen, Zeichnungsphilosophie, versichererspezifische Risikobereitschaft und Jahre operativer Erfahrung. Ein Großteil davon ist nicht in einer Form niedergeschrieben, die ein Modell einfach lesen kann.
Deshalb glauben wir nicht an einen reinen Agenten, der jedes Mal von Grund auf neu denkt, und wir glauben auch nicht an einen starren Workflow, der bricht, sobald die Realität chaotisch wird. Stattdessen bauen wir agentische Workflows. Der Workflow gibt dir Wiederholbarkeit, Prüfbarkeit und Kostenkontrolle. Der Agent handhabt die Variabilität und erholt sich, wenn der Happy Path bricht. Der Mensch bleibt für die Beurteilungen im Loop, bei denen Verantwortlichkeit zählt.
Am ersten Tag automatisiert dies manuelle Arbeit. Aber im Laufe der Zeit wird jede Eskalation zu einem Signal, jede Ausnahme zu einem Feedback und jede menschliche Korrektur zeigt, wo das Drehbuch unvollständig war. Im Laufe der Zeit hört der Workflow auf, ein Skript zu sein, und wird zur operativen Erinnerung des Versicherers. Das ist der Teil, den die Labore nur schwer erreichen können. Sie werden weiterhin bessere Modelle und bessere allgemeine Agenten ausliefern, und das sollten sie auch. Aber sie sitzen nicht lange genug in den Produktions-Workflows eines Versicherers, um zu lernen, warum ein Konto eskaliert wurde, warum ein Risiko abgelehnt wurde oder warum ein Underwriter den Risikobereitschaftsleitfaden übergangen hat und damit richtig lag.
Dieses Verständnis kommt nur davon, den Workflow tausendfach in der Produktion auszuführen. Der Workflow, den du am ersten Tag auslieferst, ist nicht der Burggraben. Die Schleife, die die Produktionsnutzung im Laufe der Zeit erzeugt, ist es.
Für uns bedeutet das, abseits der Road zu bauen.
Wie entscheidest du, ob du im Rest von Oz bist oder nicht?
Der Tools-und-Schritte-Test: Wie viele Schritte erfordert die Arbeit, und wie komplex sind die Tools, die du bauen musst, um sie zu unterstützen? Vergleiche eine horizontale KI-Suche über Google Drive – ein Schritt mit einem Tool und einem verzeihenden Ergebnis, der Benutzer liest die Zusammenfassung und fragt erneut, wenn sie falsch ist – mit einer mehrstufigen juristischen Prüfung gegen drei Jahre Kanzleipräzedenzfälle: Dutzende von Schritten über viele Tools hinweg, Ausgabe, die die Partnerprüfung bestehen muss und möglicherweise vor Gericht argumentiert werden muss. Beides sieht aus wie „ein Agent, der Arbeit erledigt", aber nur eines erfordert die Art tiefer Software, deren Bau ein fokussiertes Team Jahre braucht.
Der System-Test: Baust du ein System, durch das der Kunde seine Arbeit laufen lässt, oder ein Tool, das auf einem System sitzt, das er bereits hat? Systeme besitzen den Workflow durchgängig – die Datenerfassung, die Governance, die Aufzeichnungen darüber, was getan wurde – und sie sind das, worauf der Kunde zeigt, wenn er beschreibt, wie die eigentliche Arbeit abläuft. Tools hingegen fügen nur Intelligenz zu einem Workflow hinzu, den der Kunde bereits ausführt. Der Tool-Fall generiert echte Einnahmen, und die Labore können ihn übernehmen, weil der Kunde nicht von dir als Orchestrierungsschicht abhängig ist. Ein hoher ACV ist normalerweise ein Zeichen für ein System, da Systeme echte Mitarbeiter ersetzen und entsprechend bezahlt werden, aber es ist keine Garantie. Frage dich, ob der Kunde dein Tool noch brauchen würde, wenn ein Labor etwas ausliefern würde, das angeblich direkt mit dir konkurriert. Wenn ja, baust du ein System. Wenn nein, bist du ein Tool – selbst wenn dein ACV hoch ist.
Der Hedgefonds-/P&L-Test: Während die Leistung von Laboren an Benchmarks gemessen wird, wird die Leistung des Rest von Oz an der Gewinn- und Verlustrechnung deines Kunden gemessen. Dein Kunde interessiert sich nicht dafür, dass dein Modell gut bei SWE-Bench oder MMLU abgeschnitten hat – er interessiert sich dafür, ob dein Agent den Deal abgeschlossen, den Vertrag korrekt geprüft oder die richtige Police gebunden hat. Wenn sie auf ihr workflow-spezifisches Ergebnis fixiert sind und nicht auf einen generischen Fähigkeits-Score, bist du im Rest von Oz. Wenn sie für generische Fähigkeiten bezahlen, verkaufst du ihnen etwas, das sie auch mit einem Claude- oder Codex-Sitz bekommen können. Die besten Agenten-Unternehmen werden wie Hedgefonds agieren müssen – gewinnen mit Alpha, gemessen am P&L des Kunden, nicht an Benchmark-Scores.
Beide können (und werden) gewinnen
Wir werden massive Gewinner auf und abseits der Yellow Brick Road sehen. Die Modelle werden weiterhin gewinnen, weil sie das Modell besitzen und sie die Distribution für die horizontalen Tools besitzen, die sie entwickelt haben.
Der Rest von Oz kann gewinnen, wenn sie das Work-System besitzen – die Oberfläche, auf der die Arbeit des Unternehmens tatsächlich ausgeführt wird und die Daten, die daraus fließen, erfasst werden. Diese Unternehmen besitzen die Datenerfassung, das Workflow-System der Aktion und die Governance. Wenn komplexere Workflows in einer Vertikalen reifen, verdichten sie sich zu einer Kern-Erfahrung, von der der Kunde abhängig wird. Wenn neue Modellgenerationen von etablierten Anbietern und Neueinsteigern ausgeliefert werden, wird das Unternehmen zur Schicht, die sie integriert und dem Kunden liefert. Das Modell ist darunter austauschbar; das Work-System ist es nicht.
Die nächste Generation von Unternehmenssoftware wird abseits der Road gebaut.
Wenn du sie baust, melde dich: jschmidt@a16z.com.
