Wie „Build versus Buy“ in der agentischen Entwicklung tatsächlich aussieht

Bei den meisten „Build-versus-Buy“-Debatten wird davon ausgegangen, dass man sich zu Beginn einmalig entscheidet und dann damit leben muss.

Agentic Engineering funktioniert so nicht. Die Entscheidung taucht auf jeder Ebene des Stacks auf, und die Teams, die es richtig machen, sind nicht diejenigen, die sich philosophisch für „selbst entwickeln“ oder „kaufen“ entschieden haben. Es sind diejenigen, die wissen, welche Ebene welche ist.

Patrick Dawkins, leitender Softwareentwickler bei Upsun, half beim Aufbau des internen KI-Prüfagenten von Upsun, noch bevor Upsun Dispatch™ als Produkt existierte, und war später an der Entwicklung von Upsun Dispatch selbst beteiligt. 

Dabei traf er auf drei verschiedenen Ebenen des Stacks dieselbe Entscheidung und kam jedes Mal zu einem anderen Ergebnis. Das ist nützlicher als ein Framework, denn es zeigt, wo sich die Argumentation tatsächlich ändert.

Die Tool-Flut, für die sich niemand entschieden hat

Bevor es eine Plattform gab, gab es Laptops. Die Entwickler wählten ihre eigenen Tools aus, ließen ihre eigenen Agenten lokal laufen, und alle gingen davon aus, dass das in Ordnung war, weil es schon immer so funktioniert hatte. Dawkins beobachtete, wie die Risse sichtbar wurden.

„Wenn du deinen Laptop zuklappst, hört er auf zu laufen“, sagte er. „Du kannst nicht in ein Flugzeug steigen, in dem es kein WLAN gibt, oder einfach mit der Arbeit aufhören, schlafen gehen und deine Agenten weiterlaufen lassen.“ In London drückte er es noch deutlicher aus: Einstieg in die U-Bahn beendete alles, was ein Agent gerade tat.

Für eine einzelne Person ist das nur ein kleines Ärgernis. Auf der Ebene einer Entwicklerorganisation ist es jedoch eine Lücke in der Steuerung. Niemand außerhalb dieses einen Laptops hat auch nur den geringsten Einblick darin, was der Agent tatsächlich getan hat. Die „Kaufentscheidung“ war hier eigentlich gar keine richtige Entscheidung. Dass jeder Entwickler sein eigenes Tool auswählen durfte, wurde automatisch zur gesamten KI-Strategie der Organisation, ohne dass jemand dies offiziell genehmigt hätte. 

Die Lösung lag nicht in einem besseren einzelnen Tool. Es ging darum, etwas zu entwickeln, das zentralisiert genug war, damit die Arbeit nicht in dem Moment verschwand, in dem ein Fenster geschlossen wurde.

Der billige Weg – und was er später kostet

Es gibt einen schnelleren Weg, einen Agenten dazu zu bringen, echte Arbeit zu leisten, und Dawkins gibt nicht vor, dass es anders wäre. „Man kann als Einzelperson Dinge wie OpenClaude oder Claude mit ‚dangerously-skip-permissions‘ nutzen“, sagte er. Keine Genehmigungshürden, keine Einschränkungen, voller Zugriff auf die Tools, laufen lassen, bis das Ziel erreicht ist. „Aber als Organisation hilft uns das nicht weiter.“

Die Kluft zwischen diesen beiden Sätzen ist das ganze Argument. Das Überspringen von Berechtigungen funktioniert gut, bis ein Compliance-Prüfer oder ein regulierter Kunde anfängt, Fragen zu stellen, die du nicht beantworten kannst. 

Dawkins nennt die Alternative „Harness Engineering“: Man gibt einem Agenten genügend Werkzeuge, damit er wirklich nützlich ist, schränkt aber genau ein, was er anfassen darf, und lässt ihn in einer Sandbox laufen, die in dem Moment gelöscht wird, in dem die Aufgabe beendet ist. 

Die Entwicklung dauert länger. Es ist aber auch die Variante, die standhält, wenn jemand fragt, woher du weißt, dass es sicher ist.

So sieht eine konkrete Anbieterentscheidung aus

Als Dawkins einen Sandbox-Anbieter für Dispatch auswählen musste, hat er nicht einfach geraten. Sein Team entwickelte Wegwerf-Prototypen für verschiedene Optionen, um zu sehen, wie sich jede einzelne tatsächlich verhielt.

Das Ergebnis war fast schon eine Enttäuschung. Die Optionen lagen in ihren Fähigkeiten so nah beieinander, dass die Wahl allein aufgrund technischer Vorzüge kaum eine Rolle spielte. Also wählte das Team einen Anbieter aus und hielt die Infrastrukturebene bewusst davon entkoppelt, wobei es die Entscheidung als reversibel und nicht als endgültig betrachtete. 

Das ist die eigentliche Kunst bei der „Build-versus-Buy“-Entscheidung auf der Infrastrukturebene: zu erkennen, wann die Wahl kaum eine Rolle spielt, und so zu entwickeln, dass man seine Meinung noch ändern kann, anstatt darauf zu setzen, beim ersten Mal die richtige Wahl getroffen zu haben.

Kauf die Standardkomponente, entwickle das Urteilsvermögen

Die gleiche Logik zeigt sich eine Ebene höher, beim Modell selbst. Upsun Dispatch begann damit, Kunden ihren eigenen Anthropic-Schlüssel mitbringen zu lassen, anstatt von Anfang an eine proprietäre Modellzugriffsebene aufzubauen. Kauf die Standardkomponente. Baue nicht neu auf, was ein Pionierlabor bereits gut macht.

Was Dawkins stattdessen aufbaut, ist der Teil, den man nicht von der Stange kaufen kann: ein Bewertungsframework, um Modelle wissenschaftlich zu vergleichen, damit Entscheidungen über Kosten, Qualität und den Aufwand für die Argumentation kein Rätselraten mehr sind. 

„Man bekommt oft das, wofür man bezahlt“, sagte er, „nur eben nicht immer.“ Zu wissen, wann und für welche Aufgaben das gilt, ist das eigentliche Produkt.

Das Muster, das allen drei Entscheidungen zugrunde liegt

Kauf die Teile, die wirklich Standardware sind: eine Sandbox-Laufzeitumgebung, ein Pioniermodell, die zugrunde liegende Rechenleistung. Entwickle die Teile, bei denen dein eigenes Urteilsvermögen tatsächlich das Produkt ist: die Einschränkungen, die Bewertung, die Argumentation, die du gegenüber jemandem verteidigen müsstest, der das System nicht selbst entwickelt hat. 

Upsun Dispatch gibt es, weil Dawkins dreimal an diese Weggabelung gestoßen ist und immer wieder zu derselben Antwort gelangt ist.

• Neu hier? Lies die Einführung zu Upsun Dispatch.
• Möchtest du beim Aufbau mithelfen? Bewirb dich für die Gruppe der Gründungs-Design-Partner.