Stripe hat minions entwickelt, ein eigenes Agentensystem, das jede Woche über 1.300 Pull Requests ohne menschlich geschriebenen Code zusammenführt. Sierras Pinecone eröffnet 70 % ihrer PRs. Die Berichte sind hervorragend. Wenn du sie noch nicht gelesen hast, solltest du das tun. Falls doch, hast du dich wahrscheinlich gefragt, ob du dein eigenes System bauen solltest.
Für die meisten Teams lautet die Antwort meiner Meinung nach Nein. Nicht, weil Stripe und Sierra es falsch gemacht hätten. Sie waren früh dran mit diesen Ideen und haben die Teams, um das umzusetzen. Aber heute kannst du (fast) alles kaufen, was sie selbst bauen mussten. Die meisten Organisationen sollten sich auf etwas anderes konzentrieren: Geschwindigkeit zum Mehrwert. Ich arbeite bei Cursor, habe also meine eigenen Vorurteile, aber hier sind meine Gründe:
1. Der differenzierende Teil ist ohnehin portabel
Der Teil eines Cloud-Agenten-Systems, der sich wie dein Eigenes anfühlt, ist die Kontextebene. Regeln, die deine Konventionen kodieren. Skills, um wiederverwendbare Anweisungen zu kodifizieren. MCP-Zugriff auf deine internen Systeme. Workflows, um zu überprüfen, was Agenten geschrieben haben. Wenn Stripes minions dieselben Regeldateien lesen, die ihre Ingenieure für Cursor und Claude Code schreiben, und Kontext aus denselben internen MCP-Tools ziehen, dann ist es der Kontext, der die Arbeit macht.
Das Besondere an dieser Ebene: Sie ist der am stärksten differenzierende Teil des Systems und gleichzeitig der portabelste. Eine Regeldatei, ein Skill und eine MCP-Konfiguration funktionieren überall gleich und binden dich an keinen Anbieter. Stripe hat den Punkt bewiesen, indem sie das Regelformat von Cursor standardisiert haben, sodass ein Satz Regeln ihre minions, Cursor und Claude Code gleichermaßen leitet. Die übliche Befürchtung – „Wenn wir die Plattform kaufen, geben wir unsere Differenzierung auf" – ist also kein Problem. Du behältst den differenzierenden Teil, egal was passiert. Kaufen bedeutet, dass du alles darunter überspringst.
2. Der Bau ist viel größer, als es aussieht
Einen Agenten in einer VM zum Laufen zu bringen? Das ist ein Wochenende. Vier Neunen Zuverlässigkeit und Umgebungsstarts unter zehn Sekunden zu erreichen? Das ist ein Infrastrukturprojekt über mehrere Quartale. Wir bauen bei Cursor seit 18 Monaten an Cloud-Agenten und glauben, dass dies ein Bereich dauerhafter Investitionen sein wird.
Es gibt auch ein Problem mit der Politur. Selbst ein funktionierender interner Build bekommt selten die Liebe zum Detail, die die Leute dazu bringt, ihn tatsächlich zu nutzen. Ein internes Tool, das zu 80 % gut ist, hat eine Nutzung von 20 %. Die meisten Teams liefern einen Slack-Bot aus und hören dann auf, weil die Integration desselben Agenten in IDE, CLI, Web, Mobile, Jira usw. viel zu viel Fläche abdeckt. Und dann ist da noch die Governance: Benutzerverwaltung, Token-Analysen, Budgetkontrollen, Prüfpfade. Alles ist obligatorisch, nichts davon ist differenzierend.
Verantwortlichkeit ist ein weiterer Kostenfaktor, der nie in die Baukostenschätzung einfließt. Agenten tun Dinge. Irgendwann tut einer das Falsche. Wenn das passiert, schauen alle auf das Team, das das System gebaut hat, und dann ist dieses Team für den Vorfall, die Nachbesprechung und die Behebung verantwortlich. Kaufen macht Vorfälle nicht unmöglich, aber es bringt einen Anbieter mit einem Sicherheitsteam an deine Seite, der mit in der Verantwortung steht.
3. Der Stand der Technik bleibt nicht stehen
Etwa jeden Monat erfindet ein zukunftsorientiertes Team einen besseren Weg, um den SDLC zu automatisieren, und was auch immer du vor drei Monaten gebaut hast, sieht veraltet aus. Feinabgestimmte Codermodelle wurden von der nächsten bahnbrechenden Veröffentlichung überholt. Die RAG-Stacks, die alle gebaut haben, haben gegen lange Kontexte und agentische Suche verloren. Benutzerdefinierte Integrationen wurden über Nacht zu MCP-Konfigurationen. Selbst Sierra begann mit parallelen Agenten in Git-Worktrees und hat sie innerhalb von Monaten überholt.
Auf der Skala von Cursor können wir uns diesem Wandel hingeben. Wir bauen gerne neu, weil sich die Kosten auf Tausende von Kunden verteilen und die Rechnung immer noch aufgeht. Dieselbe Skala sichert ausgehandelte Cloud-Verträge und Multi-Tenant-Bin-Packing, die kein interner Betrieb erreichen kann. Für ein internes Entwicklerteam ist derselbe Wandel eine Steuer. Jede Neuerfindung landet auf einer Roadmap, die bereits voll mit internen Kunden ist. Du willst nicht auf dem permanenten R&D-Förderband sein. Du willst einen Partner, der für dich skaliert und es für dich betreibt.
4. Kaufen bedeutet nicht, Kontrolle aufzugeben
Der letzte Einwand ist die Kontrolle. Die meisten Build-Entscheidungen sind eigentlich getarnte Lock-in-Ängste. Also mach dir konkret klar, wo du tatsächlich Optionen brauchst. Modelle sind der offensichtliche Punkt: Token-Ausgaben werden zu einem echten Kostenfaktor, und die Pareto-Grenze von Fähigkeit vs. Kosten verschiebt sich alle paar Wochen. Mit einer modellneutralen Plattform hast du immer Zugang zum Besten, egal wer in dieser Woche das Rennen anführt.
Der andere Punkt ist die Agenten-Ausführungsebene. Betreibe sie, wie du willst, von vollständig bei Cursor gehostet bis vollständig selbst gehostet in deinem eigenen Netzwerk, wo Agenten wie jedes Servicekonto interne Endpunkte und Testinfrastruktur erreichen können. Deine Sicherheitslage wird zu einer Bereitstellungsentscheidung, nicht zu einem Grund, etwas zu bauen.
Wann Bauen sinnvoll ist
Es gibt einige Dinge, die die Waage zugunsten des Bauens kippen lassen. Je mehr davon auf dich zutreffen, desto stärker ist das Argument.
Dein Produkt ist Agenten-Infrastruktur. Sierra verkauft KI-Agenten für den Lebensunterhalt. Der Bau von Agentensystemen liegt in ihrer DNA und wird täglich von ein paar hundert Mitarbeitern dogfooded. Sie haben sicherlich das Fachwissen, um auch ein Codier-Agenten-System zu bauen.
Du besitzt bereits die schwierigen Teile. Stripe betrieb minions auf Devboxen, die sie ein Jahrzehnt lang perfektioniert hatten. Für sie ist es wahrscheinlich weniger Arbeit, ein Agentensystem um diese Devboxen herum zu bauen, als sie an die Form eines Standardprodukts anzupassen. Wenn deine Entwicklungsinfrastruktur so ausgereift und so maßgeschneidert ist, kann die Rechnung für dich genauso aufgehen.
Du wirst es wie ein Produkt finanzieren, auf unbestimmte Zeit. Ein besetztes Team mit einer Roadmap, Bereitschaftsdienst und einem Budget, das Umstrukturierungen übersteht. Aber selbst dann fang nicht bei Null an: Bausteine wie das Cursor SDK geben dir ein modellagnostisches Agenten-Geschirr, das einsatzbereit ist, sodass die Arbeit deines Teams in die Teile fließt, die für dich einzigartig sind.
Anerkennung, wo Anerkennung gebührt
Ich habe enormen Respekt vor Stripe, Sierra und den anderen Teams, die die Grenzen des agentischen Engineerings verschieben. Ihre Engineering-Teams sind unübertroffen. Aber die meisten Organisationen müssen nicht in ihre Fußstapfen treten. Sie brauchen Geschwindigkeit zum Mehrwert und einen Partner, dessen einzige Aufgabe es ist, in ihrem Namen an der Spitze der Entwicklung zu bleiben. Für fast alle ist das mehr wert als vollständige Anpassung.
Werde schnell KI-nativ. Und entscheide dann Stück für Stück, welche Teile du ins eigene Haus holst.
