Alle sagen plötzlich “agentische Plattform”. Fast niemand kann eine definieren. Genau das wollten wir ändern.
Ich habe Kaspar von Grünberg auf den Kanal eingeladen. Er formt seit Jahren Plattformen, hat mit Humanitec die Internal Developer Platform, die IDP, auf die Landkarte gebracht und PlatformCon zur grössten Platform-Engineering-Community gemacht. Jetzt baut er Canyon, einen Control Plane für Enterprise-KI, und sein Buch Thinking in Platforms ist auf dem Weg. Am Ende dieses Gesprächs wisst ihr, was eine agentische Plattform wirklich ist, warum sie wichtig ist, was es braucht, um eine zu bauen, und wie man anfängt.
Zuerst: Was eine Plattform eigentlich ist#
Bevor man über agentische Plattformen reden kann, muss man klären, was eine Plattform überhaupt ist. Im klassischen Sinn des Platform Engineering ist eine Plattform ein Set von Pfaden entlang eines Value Streams zu einem geschäftlichen Endpunkt. Wenn du als Wissensarbeiter etwas erreichen willst, brauchst du Dinge von einem anderen Team, aus der Dokumentation, aus internen Tools. Eine gute Plattform ebnet dir diese Pfade. Sie sagt: Romano, wenn du eine ephemere Umgebung brauchst, mach das, und hier ist sie.
Platform Engineering hat in der Softwareentwicklung begonnen, und Kaspar beschreibt es als die Disziplin, digitale Fabriken zu bauen. In den letzten zehn Jahren hat die Softwareentwicklung ihre eigene industrielle Revolution durchlaufen. Der Sinn der Fabrik ist nicht, dass der Entwickler zum Fabrikarbeiter wird. Der Sinn ist, dass die Fabrik alles auf dem Weg erledigt, damit der Entwickler sich auf die Arbeit konzentrieren kann, die wirklich zählt, das Coden. Wie so oft in der Wissensarbeit entsteht das Muster in der Softwareentwicklung und breitet sich dann in den Rest der Wirtschaft aus. Agile, SAFe und Kanban haben genau diesen Weg genommen.
Mehr als eine Plattform mit etwas KI obendrauf#
Der naheliegende Einwand ist: Wir haben doch schon Platform Engineering. Ist eine agentische Plattform nicht einfach eine normale Plattform mit etwas KI obendrauf? Kaspars Antwort ist nein, und der Grund lohnt sich.
Das grosse Problem, das alle haben, ist, Agenten im Unternehmen produktiv zu machen, und das Unternehmen ist etwas ganz anderes als ein Fünfzehn-Personen-Startup. In einer Umgebung mit Hunderttausenden Menschen kannst du kein Frontier-Modell nehmen, es hineinwerfen und den Job für erledigt erklären. Genau dort beginnt der Job. Um produktiv zu sein, müssen Agenten fast wie Menschen behandelt werden. Man muss vorsichtig sein, denn sie sind keine Menschen, aber die Arbeitsumgebung muss für sie gebaut sein. Sie arbeiten entlang eines Value Streams, sie müssen erreichbar sein, sie müssen Ausnahmen behandeln.
Kaspar hat das mit einem Bild beschrieben, das bei mir hängen geblieben ist. Stell dir vor, du stellst einen brillanten Menschen ein, wirfst ihn dann als Mac-User in eine Linux-Umgebung, packst alles in eine Sprache, die er nicht spricht, und gibst ihm kein Onboarding. Eine Woche später bist du überrascht, dass er nicht produktiv war. Genau das machen Unternehmen gerade mit Agenten, und das wird nicht funktionieren. Der Base Layer der Plattform muss trotzdem da sein. Ohne eine gut definierte Single Source of Truth, saubere Pipelines und ein vernünftiges Ressourcen- und Hosting-Setup wird es schwierig. Aber auf dieser Basis brauchen Agenten mehr.
Die drei Schichten einer agentischen Plattform#
Die Internal Developer Platform, die Kaspar mitdefiniert hat, wurde jahrelang gezeichnet als Developer Control Plane mit Portal und Versionskontrolle, einer Integrations- und Ressourcenebene, überwacht und abgesichert, läuft irgendwo. Das war das Diagramm der Prä-Agenten-Ära, und es war rein für die Softwareentwicklung gebaut. Heute sieht man auf LinkedIn schon Legal Platform Engineers und Sales Platform Engineers, die Disziplin breitet sich also aus. Die agentische Plattform, die er jetzt beschreibt, hat drei Schichten und lässt sich vertikalisieren in Development, Marketing, Sales, Finance oder Legal.
Die erste Schicht ist Tooling. Das ist weitgehend die Plattform, die du schon hast: Kontrolle und Governance, Integration, Provisioning, Ressourcen, Tools, Security, Observability. In der agentischen Welt wird sie zur Basis, die die Agenten aufrufen. Es hilft, sie als Basis statt als oberste Schicht zu sehen, denn Agenten arbeiten nicht linear. Sie bewegen sich vor und zurück durch die Schichten.
Die zweite Schicht sind die Path Specifications. Das ist die Karte, die Agenten und allen anderen Teilen des Systems sagt, wie sie ihren Weg durch die Plattform finden. Das kann man nicht den Agenten überlassen.
Die dritte Schicht ist die Agent Infrastructure. Sie ist das, was den Agenten tatsächlich bedient: Kontext, Fähigkeiten, Memory, Evaluation. Die entscheidende Erkenntnis ist, dass du das Tooling pro Vertikale austauschen kannst, während die Path Specifications und die Agent Infrastructure gleich bleiben. Wechsle von Development nach Marketing, und du bekommst Marketing-Tools, aber das System, das die Agenten steuert, ändert sich nicht.
Wo die Datenplattform hineinpasst#
Eine Frage, die ich ständig höre, ist, wo in all dem die Datenplattform sitzt. Die Daten selbst liegen in der Tooling-Schicht der Entwicklungsplattform, die Data Lakes, Datenbanken und Ressourcen, die die Software betreiben. Aber ehrlich gesagt wird daneben noch eine andere Umgebung gebaut: die Datenplattform für die ML- und Quant-Leute, die Model Evaluation und Fine-Tuning verantworten. Sie ist eine spezielle Form von Plattform, mit einer Referenzarchitektur, aber wirklich anderen Anforderungen.
Kaspars Empfehlung, und meine, ist, zwei Plattformen zu betreiben: eine Datenplattform und eine agentische Entwicklungsplattform. Zu viel auf eine einzige Plattform zu packen, ist fast immer ein Fehler. Er führt diese Gespräche mit Organisationen, die vier- oder fünftausend Entwickler haben, und der Management-Impuls ist immer, eine grosse Plattform zu bauen. Es gibt eine natürliche Grenze, irgendwo bei einigen hundert Entwicklern, jenseits derer eine Plattform keinen Sinn mehr macht. Datenplattformen sind besonders anders und verdienen ein eigenes Zuhause, gerade in Branchen wie Finance, wo Data Engineering und Software Engineering zwei verschiedene Jobrollen sind.
Alles als Code ist das Eintrittsticket#
Eine Sache, die ich seit Jahren predige, ist, dass heute alles in Code gehört und unter Versionskontrolle. Nicht nur die Applikation, sondern Jira, Confluence, SharePoint, alles. Kaspar hat es klar gesagt: 2026 ist das die Gewinnerstrategie, und mit Agenten wird sie viel wichtiger. Was nicht codifiziert ist, damit können Agenten nicht arbeiten.
Path Specifications, und wo die Arbeit wirklich passiert#
Die Path Specification ist der eigentliche Neuling, deshalb lohnt sich ein genauer Blick. Kaspar und seine Kollegen diskutieren die Kernfrage: Soll man einem Agenten genau sagen, was er tun soll, oder einfach “hier ist die Aufgabe, mach das”? Seit Opus 4.5 und 4.7 ist das Modell nicht das Problem. Diese Modelle sind bemerkenswert. Das Problem ist, sie effizient mit Information zu versorgen, und genau dafür ist die Plattform da.
Er hat auf eine Analyse des Claude-Code-Quellcodes verwiesen, veröffentlicht Ende letzten Jahres, die sich angeschaut hat, wie das Tool tatsächlich gebaut ist. Der auffällige Befund, den er zitiert, ist, dass nur rund 1,6 Prozent davon der Teil ist, in dem das LLM seine Magie entfaltet, und etwa 98 Prozent deterministisches Routing sind. Die Anthropic-Engineers geben dem Agenten Freiheit und schränken ihn dann ein, denn das Modell in jeder Runde alles von Grund auf durchdenken zu lassen, verbrennt Tokens und ist ineffizient.
Genau das ist ein Agent Path. Wenn du ein PR-Review machst, sagt der Pfad: Hier sind die Tools, hier ist der Kontext, hier ist dein direkter Weg zur Versionskontrolle, so machst du das. Kaspar nennt Agent Paths probabilistisch, aber wenn man genau hinschaut, tragen sie eine grosse Zahl deterministischer Vorgaben, und das LLM macht nur ein paar Prozent der Arbeit. Hier sitzt aus meiner Sicht der eigentliche Gewinn, und deshalb wandert die Komplexität nach unten in die Path Specification statt ins Modell.
Agent Infrastructure: Harness und Governance#
Agent Files, die agent.md-Dateien, listen auf, was ein Agent kann, aber sie brauchen ein System, auf dem sie laufen. Dieses System ist die Agent Infrastructure, und sie hat zwei Teile: den Harness und die Governance-Schicht.
Der Harness ist, in Kaspars Worten, das Betriebssystem für einen einzelnen Agenten. Er hat vier Komponenten: Serving, Context Management, Capabilities und Evaluation. Serving umfasst die Modelle, GPU-Hosting, Gateways, Router, Orchestrierung, Runtime-Management und Queues. Context Management ist Memory-Management, das effiziente Ausliefern von Kontextteilen und das effektive Chunking, wenn man Background-Agenten startet. Er hat angemerkt, dass das meiste davon ganz normales Infrastruktur-Management ist, weshalb Infrastruktur-Leute wichtiger sind denn je. Capabilities ist die Menge all dessen, was der Agent über Protokolle, Gateways und Tool-Anbindungen tun kann. Evaluation ist der LLM-as-Judge, die Rubriken, das Scoring.
Governance ist der andere Teil, das Management-Framework für Hunderte und Tausende Agenten. Hier liegen gerade die schwersten offenen Fragen. Wie geht man mit Identität um? Ist es Identity Federation? Mit welcher Identität handelt ein Agent tatsächlich, und wer trägt die Accountability? Genau darüber hatte Kaspar eine faszinierende Debatte mit einer regulierten Branche in New York. Security und Observability der Agenten sitzen ebenfalls hier. Der Agent Path wird über den Governance Plane verfolgt und überwacht.
Das Gleichgewicht zwischen probabilistisch und deterministisch#
Die deterministische Seite von all dem ist nicht neu. CI/CD-Pipelines, die kompilieren, bauen, scannen und deployen, stehen seit Jahrzehnten in der Referenzarchitektur. Worauf es ankommt, ist das Gleichgewicht zwischen den probabilistischen und den deterministischen Teilen des Systems. Das probabilistische System macht seinen Teil, ein deterministisches Gate prüft ihn und liefert klare Fehlermeldungen zurück, und das probabilistische System liest diese Fehler und entscheidet, ob es weitergeht.
Je fragiler das ist, was angefasst wird, desto wichtiger ist das. Du würdest nicht sagen “hey Agent, setz mal die Postgres-Konfiguration in Produktion”. Du würdest sagen “hey Agent Path, hier sind die Optionen”, einen deterministischen Endpunkt mit einer klaren Produktionsdatenbank exponieren, den Agenten innerhalb von Grenzen wählen lassen und diese Wahl dann gegen ein Policy-Framework wie OPA prüfen. Das sind die Integration- und Delivery-Planes, und sie zusammenzubringen macht den Plane von Grund auf hybrid.
Die vier Stufen agentischer Autonomie#
Kaspars Team arbeitet mit vier Stufen agentischer Softwareentwicklung. Stufe 0 ist menschlich. Stufe 1 ist eine Prise KI, der Assistent in deiner CI, der reviewt und Vorschläge macht. Stufe 2 ist Human-in-the-Loop, wo du zum Orchestrator wirst. Du triggerst das System, es macht die Arbeit, du reviewst sie, und du kannst zwei oder drei parallel laufen lassen. Das ist die Stufe, die heute langsam in die Unternehmen kommt, und der Zielzustand der meisten grösseren Organisationen.
Er hat mich durch ein Stufe-2-PR-Review geführt. Ein Entwickler öffnet einen PR, ein Webhook triggert einen Orchestrator, Identität wird aufgelöst, ein Lookup passiert auf Basis der Orchestrierung, Policies werden angewandt, die richtigen Capabilities werden angehängt, Kontext wird aus der Versionskontrolle gezogen, und erst dann, weit im Flow, läuft das probabilistische System und das Modell macht seine Arbeit. Der Output geht durch Model Safety, dann durch das Eval-Framework, und das Ergebnis wird ans Modell zurückgegeben, um zu entscheiden, ob es neu gemacht wird. Exit-Kriterien werden geprüft, alles wird beobachtet, und es landet zurück beim Menschen für die Entscheidung. Der Nutzer bleibt im Loop, deshalb ist es Stufe 2.
Stufe 3 braucht die volle Plattform. Wenn du sie hast, kannst du Stufe 3 erreichen. Wenn nicht, kannst du es nicht, weshalb der Sprung von Stufe 2 auf Stufe 3 der grosse ist.
Die Dark Factory ist schon da, am Rand#
Nicht viele Unternehmen sind schon auf Stufe 3, aber die Vorreiter sind viel weiter, als die meisten annehmen. Kaspar kennt bereits Stufe-4-Unternehmen, die ausserhalb des Loops arbeiten, die Dark Factory. Das verbreitete Missverständnis ist, dass Stufe 4 bedeutet, das ganze Unternehmen läuft autonom. Das tut es nicht. Die Realität ist, dass Stufe 4 eine Maschinen-Fehlerrate unter der menschlichen Fehlerrate verlangt und am besten ausserhalb regulierter Branchen funktioniert, wo die Frage, warum überhaupt noch ein Mensch im Loop ist, keine Compliance-Antwort braucht.
Das konkrete Beispiel, das er gab: Ein Agent liest die Transkripte eines Kundensupport-Gesprächs, erkennt, dass eine Komponente für einen Nutzer ausgefallen ist, erstellt einen PR, gibt frei, dass er gefixt ist, und deployt, ohne Mensch im Loop. Diese Dinge existieren jetzt, in Apps, die ihr schon benutzt, und es sind vielleicht fünf Prozent von dem, was die absoluten Vorreiter machen. Es gibt keinen technischen Grund, warum wir nicht dort ankommen. Es ist reines Platform-Management. In fünf Jahren wird das so aussehen, wie DevOps und Platform Engineering heute aussehen. Es ist immer eine Glockenkurve, und die Vorreiter bewegen sich schnell.
Standardisierung ist der eigentliche Hebel#
Die unbequeme Wahrheit ist, dass der meiste Enterprise-Quellcode ein Chaos ist, und die Leute nutzen das als Ausrede. Sie sagen, ihr Code sei zu komplex, als dass Agenten ihn je verstehen könnten, und damit haben sie wahrscheinlich recht. Die Antwort ist nicht, das Chaos zu schützen. Sie ist, es wegzuwerfen und neu anzufangen. Wenn dein Standard-Enterprise-Setup fünfhundert verschiedene Wege hat, eine Postgres-Datenbank und eine Staging-Umgebung aufzusetzen, Go im einen Microservice, Python im nächsten, Java und Spring im dritten, dann ergibt das für Menschen keinen Sinn und für Agenten noch weniger.
Die Aufgabe ist, wie immer in der Informatik, einen Schritt zurückzutreten. Die Flut steigt, und du musst mit ihr steigen. Alles wird standardisiert. Alle deine Postgres-Datenbanken sehen gleich aus, und out of the box ist alles für Agenten gebaut. Das verändert komplett, wie du baust. Aber du musst zu dieser Erkenntnis kommen und danach handeln, sonst hast du ein ernstes Problem.
Ich sehe das wie die Geschichte der Programmiersprachen. An der Universität habe ich Assembler gelernt, direkt auf den Registern der Maschine gearbeitet. Heute programmiert niemand mehr Assembler. Dann kamen C, C++, Java, die objektorientierten Sprachen. Wir sind einfach in einem weiteren Schritt dieser Evolution, nur ist der Output nicht mehr deterministisch, wie es Maschinencode immer war.
Determinismus war immer eine Illusion#
Das führte zu einem meiner Lieblingsteile des Gesprächs. Ich habe gefragt, ob Spezifikationen der neue Quellcode sind und ob wir bei jedem Kompilieren eine neue Applikation bekommen. Kaspars Antwort hat die ganze Frage neu gerahmt. Der Output war nie deterministisch. Determinismus existiert nur, wenn du ein sauberes Input-Regime hast, es kompilierst und einen klaren Output bekommst. Aber daher kommen die Fehler nicht. Fehler kommen vom probabilistischen Knoten in jedem realen System, und das ist der Mensch. Zwölf Leute machen jeweils die Dinge leicht anders. Unsere Software-Setups waren nie deterministisch. Sie waren immer ein Kampf gegen die probabilistische Natur der Menschen im Loop, und das geht nicht weg.
Das andere Missverständnis ist die Erwartung, dass Agenten es beim ersten Mal richtig machen. Menschen machen nichts beim ersten Mal richtig. Die Mathematik auch nicht. Wenn du das globale Maximum einer komplexen Funktion willst, springst du nicht direkt dorthin. Du machst einen Versuch, analysierst, schaust auf den Gradienten und iterierst. Es ist immer ein iterativer Prozess, und das wird es immer sein. Deshalb ist die Plattform so wichtig, und deshalb werden die Grundlagen wichtiger, nicht weniger.
Die Grundlage, die am meisten zählt, ist zu wissen, was man eigentlich will. Kaspars Lackmustest nach der Arbeit mit fünfzehn Softwareentwicklungs-Teams ist, zu fragen, warum sie ein Feature bauen und welches Problem es löst. In neunzig Prozent der Fälle weiss es niemand. Das war das Problem der letzten Jahrzehnte, und es wird das Problem der nächsten sein.
Multi-Model ist der neue Standard#
Wir haben das im Juli 2026 aufgenommen, am Rand eines schnell bewegten Markts, dieser Teil ist also eine Momentaufnahme. Aus Kaspars Konferenzen in London und New York ist die Botschaft unter Platform Engineers klar: Alle gehen Multi-Model. Der Grund ist Geschwindigkeit und Lock-in-Risiko. Wenn du alles auf ein Modell setzt und der Anbieter es dann abschaltet, oder die Wechselkosten zu hoch werden, bist du exponiert. Multi-Model zu gehen heisst, dass du wahrscheinlich auch nicht komplett auf ein einziges Agenten-Tool setzen kannst. In dieser Phase der Entwicklung auf einen Anbieter zu setzen, ist zu gefährlich.
Darunter liegt eine ökonomische Schicht. Wenn jemand die Frontier von GPUs und die Applikationsschicht zugleich besitzt, ziehen die Incentives sie zusammen. Hardware-Anbieter bewegen sich in die Modellschicht und in die App. Open-Source-Modelle liegen inzwischen ungefähr auf dem Niveau von Sonnet, wohl einen Tick besser, und diese Entwicklung geht weiter. Kaspars Lesart ist, dass viele der harten Komponenten, besonders Context- und Memory-Management, und sicher die Governance-Services wie Identität, Observability, Security und Eval-Frameworks, in-house gebaut werden. Er sieht keine Welt, in der man das auslagert. Er hält das auch für gute Nachrichten für Europa, denn der grosse Vorsprung, den die US-Frontier-Labs heute haben, erodiert, sobald die Modelle konvergieren und Self-Hosting machbar wird.
Was sich für die Organisation ändert#
Ich vertrete seit Jahren, in meinem Buch über die Cybernetic Enterprise, dass die Plattform das Fundament einer agentischen Organisation ist und dass Organisation und Prozesse genauso wichtig sind wie die Technologie. Also habe ich Kaspar gefragt, ob ein Unternehmen eine agentische Plattform einführen und seine Organisation lassen kann, wie sie ist. Seine Antwort war, dass man an der Transformation nicht vorbeikommt.
Seine Analogie war, eine Bank vom Schalter zum Hochleistungs-Trading-Floor umzubauen, computergesteuert. Der Schalter wird weniger wichtig. Was zählt, sind die Menschen im Hochleistungsprogramm. In unserer Welt sind das die technischen Produktmanager, die guten Softwarearchitekten, die Leute, die die Spezifikationen schreiben, aus denen die Agenten arbeiten, und vor allem die Plattform-Teams. Das Plattform-Team muss die Security- und Infrastruktur-Leute einbinden und zu einer engen Gruppe werden, die die Plattform rund um die Architekten und die Leute optimiert, die die Schnittstellen definieren.
Sein praktischer Rat ist, super klein anzufangen. Jede neue Software, die du baust, bau sie in der neuen Welt, egal wie klein. Er plädiert stark dafür, in eine molekulare Einheit zu investieren, in der man testet, wie es tatsächlich funktioniert. Das läuft jedem Management-Ratschlag zuwider und macht das Management nervös, weil es noch nicht sieht, wie das auf Hunderte Kunden skaliert. Aber du musst dich damit anfreunden, eine grosse Plattform-Gruppe auf eine winzige App anzusetzen. Es ist Startup-Denken. Du machst am Anfang Dinge, die nicht skalieren, und wenn es funktioniert, gibst du mehr Energie dazu.
Wie man anfängt: Die 3-3-3-Regel#
Das verbindet sich direkt mit meiner eigenen Hypothese, dass die ganze Organisation entlang des Value Streams strukturiert sein sollte, mit IT und Business zusammen in einer Linienorganisation, kleinen Produktteams von etwa drei plus/minus zwei Personen und dem Plattform-Team als der neuen IT darunter. Kaspar stimmt zu, und Zühlke arbeitet intern bereits so.
Sein Playbook, dem ein ganzer Abschnitt seines Buchs gewidmet ist, lautet: Baut eine Minimum Viable Platform. Fangt super klein an, startet mit User-Interviews, baut die erste Agenten-Fähigkeit. Sie muss nicht gross sein, aber du musst vor echte Nutzer treten. Seine Faustregel ist 3-3-3: drei Leute, die drei Teams onboarden, in drei Monaten. Das ist das Investment. Du hältst die Erwartungen bescheiden, baust mit der 3-3-3-Methode ein MVP, gehst dann in ein Production-Readiness-Programm und bringst das erste Ding für diese drei Teams in Produktion. Wenn es solide und klar besser ist als das, was die Teams heute haben, baust du das Production-Scaling-Programm und onboardest Teams eines nach dem anderen.
Der Satz, der am meisten bei mir hängen geblieben ist: Eine Plattform ist nie fertig. Sie ist die Sammlung von Pfaden innerhalb eines Value Streams, und du arbeitest den Rest deines Arbeitslebens daran. Du baust ein gutes Fundament, dann sind es Pfade, Pfade, Pfade, hinzugefügt, indem du zu den Nutzern zurückgehst und einsammelst, was sie brauchen. Es ist das interne Produkt, und aus meiner Sicht ist es deine Fabrik.
Bleibt Platform Engineer#
Ich habe Kaspar nach der einen Sache gefragt, die man mitnehmen soll. Seine Antwort: Bleibt Platform Engineer. Es ist der Job der Zukunft, denn KI-Agenten sind ohne Plattformen nicht produktiv, was den Plattformbau wichtiger macht als je zuvor. Wir werden die Rolle wahrscheinlich neu nennen, agentischer Platform Engineer oder AI Platform Engineer, auch wenn es im Kern dieselbe Disziplin ist, die wir die ganze Zeit betrieben haben.
Kaspars Buch, Thinking in Platforms: Platform Engineering as the Operating Model for Work in the AI Era, erscheint am 18. August. Es hat drei Teile: eine Reflexion über Plattformen, ein abstraktes Modell, um sie von den Architekten bis in den Boardroom zu visualisieren, und ein Playbook, um sie zu bauen.
Materialien von Kaspar#
- Referenzarchitektur
- Die vier Stufen agentischer Softwareentwicklung
- Kaspars Newsletter
- University: Agent Infrastructure und Agentic Development Platforms
- Kaspars Website
- PlatformCon
Danke, Kaspar, für ein wirklich grossartiges Gespräch. Ich habe viel gelernt. Wenn ihr mehr darüber wollt, wie man mit dieser Art von KI umgeht, abonniert den Kanal, und wenn ihr Fragen oder Empfehlungen habt, schreibt sie in die Kommentare.