Stell dir vor, du arbeitest an einem Projekt. Am Abend schließt du den Laptop, und die Codierungsagentur läuft einfach weiter – in einer Cloud-Sandbox. Unterwegs wirfst du einen Blick auf das Terminal von deinem Handy aus. Am nächsten Morgen öffnest du die IDE und setzt genau dort fort, wo du aufgehört hast. Kein Export, kein Import, kein Neustart der Gedanken. Für die Entwickler von Kiro ist genau das die Vision von agentischer Entwicklung: Eine einzige durchgehende Konversation über alle Oberflächen hinweg, egal ob du im Terminal arbeitest, im Browser oder in einer nativen App.
Lange Zeit war diese Vision allerdings nicht mehr als ein Wunschbild. Der Grund lag nicht in fehlenden Client-Apps, sondern in der Architektur dahinter. Die Kiro-IDE, das Kiro-CLI und das Web-Interface betrieben jeweils einen eigenen Agenten mit eigenem Session-Format, eigenen Werkzeugen und eigenem Konfigurationsmodell. Eine Session, die in einem Client begann, konnte nicht in einem anderen weiterlaufen, weil die Agenten zu wenig gemeinsame Basis hatten. Genau diese Geschichte erzählt der neue Tech-Blogbeitrag des Teams: wie die drei getrennten Agent-Codebasen zu einer einzigen Kiro-Agent-Harness zusammengeführt wurden – und welche Architekturentscheidungen die ursprüngliche Vision nun in greifbare Nähe rücken.
Drei Clients, drei Agenten, dreifacher Aufwand
Am Anfang stand bewusstes Tempo. Als Kiro gestartet wurde, optimierte das Team auf schnelle Experimente. Jedes Client-Team bekam die Freiheit, seine eigene Agent-Harness zu bauen. Die IDE entwickelte ihre in TypeScript, passend zum Code-OSS-Erweiterungsmodell. Das CLI setzte auf Rust, weil dort Performance zählt. Und das Web-Team wählte Python, um näher an der aktuellen Agentenforschung zu sein. Diese Aufteilung erlaubte schnelle, unabhängige Releases – aber sie erzeugte auch eine Menge verborgener Kosten.
Denn die Teams trafen unterschiedliche Entscheidungen. Die Session-Speicherung funktionierte in jedem Client anders. Die Berechtigungssysteme wurden unabhängig entworfen und verwendeten inkompatible Syntaxen: Das CLI nutzte regex-basierte allowedCommands und deniedCommands, die IDE setzte auf Präfix-Matching bei trustedCommands und Substring-Matching bei der Denylist. Auch die Strategien zur Kompaktierung von langen Kontexten gingen auseinander. Sub-Agenten teilten Kontext auf unterschiedliche Weise, und Custom Agents verhielten sich je nach Client anders. Schließlich drifteten auch die Feature-Sets auseinander: Spezifikationsgetriebene Entwicklung und Powers gab es nur in der IDE, Plan-Modus und Code-Intelligenz nur im CLI.
Der Preis dafür wuchs mit jeder neuen Funktion. Jede Fähigkeit musste dreimal gebaut und gewartet werden, oft mit leicht abweichendem Verhalten. Jeder Bug musste dreimal gefixt werden. Und die Nutzer bekamen je nach gewähltem Client ein anderes Produktgefühl. Mehr noch: Die eigentliche Vision war architektonisch unmöglich. Ohne gemeinsames Session-Format, ohne gemeinsamen Werkzeugsatz und ohne gemeinsames Konfigurationsmodell konnten Sessions nicht zwischen Clients und Rechenumgebungen wandern. Es fehlte schlicht die gemeinsame Sprache.
Die Entscheidung: Eine Harness statt drei
Eine mögliche Lösung wäre gewesen, Verträge über das Agentenverhalten zwischen den Clients zu definieren und diese Verträge in allen drei Harnesses zu implementieren. Das hätte die Unabhängigkeit der Teams bewahrt. Aber es hätte auch bedeutet, dass jede neue Funktion eine Spezifikation, drei Implementierungen und eine laufende Validierung benötigt, dass sich die Implementierungen wirklich gleich verhalten. Der Koordinationsaufwand wäre mit jedem Feature gewachsen.
Der Wendepunkt kam, als Kiro sich auf den öffentlichen Start im Web vorbereitete. Statt den Web-Client mit einem weiteren separaten Agenten zu launchen und die wachsenden Implementierungskosten weiterzutragen, entschied sich das Team für den radikalen Schritt: eine einzige Agent-Harness, die das Beste aus allen drei bisherigen Ansätzen vereint. Eine einzige Harness beseitigt die Duplikation zwischen den Teams und konzentriert die gesamte Entwicklungsarbeit an einem Ort.
Eine zentrale Architekturentscheidung war dabei, die Harness als eigenständigen Serverprozess zu bauen – nicht als Bibliothek, die in jeden Client einkompiliert wird. Aus früheren Versuchen wusste das Team, dass gemeinsame Bibliotheken keine starke Grenze erzwingen. Client-Code ruft schnell interne Methoden auf, die gar nicht für den Export gedacht waren, oder legt eigene Agentenlogik oben auf die Bibliothek. Dann ist man zurück bei divergierenden Implementierungen. Ein eigenständiger Prozess macht die Trennung real: Die Harness und die Clients müssen nicht dieselbe Sprache oder Laufzeit teilen, und jeder Client kann in dem Stack bleiben, der zu seiner Plattform passt.
Wie die neue Architektur aussieht
Vorher gab es drei eng gekoppelte Paare aus Client und Agent: den IDE-Agenten in TypeScript, den CLI-Agenten in Rust und den Web-Agenten in Python. Jetzt gibt es eine saubere Trennung. Auf der einen Seite stehen die Clients mit UX, Darstellung, Nutzerinteraktion und plattformspezifischen Werkzeugen. Auf der anderen Seite steht die Kiro-Agent-Harness, die den Agent-Loop verwaltet, Werkzeuge ausführt, Sub-Agenten delegiert, Session-State hält, als MCP-Client fungiert, Konfiguration lädt, Berechtigungen prüft und Telemetrie sammelt. Die einzige Möglichkeit, diese Grenze zu überschreiten, ist das definierte Protokoll.
Weil die Harness ein eigenständiger Prozess ist und keine eingebundene Bibliothek, kann sie auf jeder Rechenumgebung laufen. Dieselbe Harness startet auf deinem Laptop oder in einer VM in der Cloud, ohne dass der Client davon wissen muss. Das wohldefinierte Interface zwischen Server und Client erlaubt es, die Agentenlogik unabhängig von den Clients weiterzuentwickeln. Wenn eine Änderung an der Harness das Protokoll nicht berührt – etwa ein neues Werkzeug, eine verbesserte Planung oder eine Optimierung des Agent-Loops – dann wird sie sofort in jedem Client wirksam, ohne dass dort auch nur eine Zeile geändert werden muss.
Ein konkretes Beispiel nennt der Beitrag: Vor kurzem wurde ein Live-Reload für Custom Agents eingeführt. Wenn du eine Datei unter .kiro/agents/ mitten in einer Sitzung bearbeitest, erkennt die Harness die Änderung sofort und teilt dem Client die neuen verfügbaren Befehle mit. Dafür war keine einzige Client-Änderung nötig, weil der Benachrichtigungstyp für verfügbare Befehle bereits im Protokoll existierte. Jeder Client hat das Feature dadurch automatisch erhalten.
Nicht Einheitsbrei, sondern Anpassung
Trotz der zentralen Harness wird das System nicht zum Einheitsbrei. Die Entwickler betonen, dass verschiedene Clients unterschiedliche Fähigkeiten haben und einige Operationen auf Client-Ebene besser aufgehoben sind. Der Client kann eigene Werkzeuge bereitstellen und eingebaute der Harness unterdrücken. Die IDE nutzt zum Beispiel die Dateizugriffs-APIs von Code OSS und stellt eigene Lese- und Schreibwerkzeuge bereit, anstatt die direkten Dateisystem-Werkzeuge der Harness zu verwenden. Wenn der Agent eines dieser client-seitigen Werkzeuge ausführen möchte, benachrichtigt er den Client, der die Ausführung übernimmt und das Ergebnis zurückgibt.
Diese Flexibilität ist wichtig, weil die Harness für ganz unterschiedliche Umgebungen gebaut wurde. Ein Terminal hat andere Bedürfnisse als eine grafische IDE, und eine mobile App wiederum andere als eine Webanwendung. Die Architektur zwingt nicht alle in dasselbe Schema, sondern definiert einen gemeinsamen Kern und lässt an den Rändern Platz für Plattform-Eigenheiten. Das ist kein Widerspruch, sondern die eigentliche Stärke des Ansatzes: Einheitlichkeit dort, wo sie Verhalten und Konfiguration betrifft, und Vielfalt dort, wo die Darstellung und Interaktion es verlangt.
ACP als Protokoll der Wahl
Für die Grenze zwischen Client und Harness wählte das Team das Agent Client Protocol, kurz ACP. Das ist ein standardisiertes Spezifikationsformat für die Kommunikation zwischen Agenten und Clients, das im Juni 2026 die Version 1.0 erreicht hat. ACP wird in IDEs wie JetBrains-Produkten, Xcode und Zed unterstützt, aber auch in Obsidian, Emacs und Neovim. Die Kiro-Entwickler hatten bereits Erfahrung mit ACP gesammelt, als sie es im CLI einführten, um Kiro direkt in diesen Anwendungen nutzbar zu machen.
Zwei Eigenschaften von ACP machten es zur passenden Grundlage: die Erweiterbarkeit für eigene Methoden und die Flexibilität bei den Transportwegen. Standardmäßig unterstützt ACP stdio als Transport, was für lokale Clients gut funktioniert, bei denen die Harness als Kindprozess des Editors oder Terminals läuft. Für entfernte Clients wie Kiro im Web oder die iOS-App war ein anderer Transport nötig. Das Team ergänzte einen eigenen WebSocket-basierten Transport, damit diese Clients sich mit einer Harness in einer Cloud-Sandbox verbinden können. Die Binärdatei, die Werkzeuge und das Agentenverhalten bleiben dabei identisch, egal welchen Transport ein Client verwendet.
Über die Transportfrage hinaus erweiterte das Team die ACP-Methoden zu dem, was sie Kiro-ACP nennen. Standard-ACP deckt die Grundlagen ab: Session-Lebenszyklus, Message-Streaming und Meldung von Werkzeugaufrufen. Doch Kiro benötigt mehr. Ein Beispiel ist das Live-Steering: ein Nutzer kann während der Arbeit des Agenten eine Nachricht senden, die in den nächsten Inferenz-Schritt eingefügt wird, um die Richtung zu beeinflussen, ohne die laufende Aktion abzubrechen. ACP unterstützt das Einreihen von Nachrichten nicht von Haus aus, daher ergänzte Kiro neue Methoden-Eigenschaften und Benachrichtigungen. Auch der spezifikationsgetriebene Entwicklungsablauf wurde als eigener Methodensatz modelliert, die einfache Werkzeugfreigabe von ACP zu einem mehrstufigen Berechtigungssystem ausgebaut und Benachrichtigungen für Kontextfenster-Auslastung und Hook-Ausführung hinzugefügt. Insgesamt kommen so mehr als 20 agent-aufrufbare Methoden, 15 client-aufrufbare Methoden und 20 Benachrichtigungstypen zur Basisprotokoll hinzu.
Die Sauberkeit dieser Erweiterungen liegt im Namespace-Konzept von ACP. Eigene Methoden verwenden laut Spezifikation einen Unterstrich-Präfix, und alle Kiro-Erweiterungen liegen unter _kiro/. Dadurch kann das Team das Protokoll für Kiro-spezifische Funktionen erweitern, ohne es zu forken. Drittanbieter-Clients können sich auf dieselbe Weise verbinden wie die eigenen Client-Anwendungen. Jeder ACP-kompatible Client erhält den vollen Agenten mit Werkzeugen, Sub-Agenten, Session-Verwaltung und MCP-Konnektivität. Die ersten Parteien – IDE, CLI, Web und iOS – nutzen zusätzlich die Kiro-ACP-Erweiterungen für Live-Steering, Spezifikationen, eine reichhaltige Berechtigungsoberfläche und Kontext-Tracking.
Was sich dadurch konkret ändert
Der unmittelbarste Nutzen der einheitlichen Harness ist, dass Funktionen, die vorher nur in einem Client existierten, nun überall verfügbar sind – mit demselben Konfigurationsformat und demselben Verhalten. Spezifikationsgetriebene Entwicklung war früher nur in der IDE möglich. Jetzt läuft sie auch im CLI, wo man sie mit /spec new startet, und in Kiro im Web. Der Agent übernimmt dabei die Interaktion mit dem Sprachmodell und die automatisierten Denkschritte, die für den Ablauf nötig sind: Anforderungen generieren, einen technischen Entwurf produzieren, Arbeit in Aufgaben zerlegen. Jeder Client präsentiert das Ergebnis so, wie es zu seiner Form passt. Die IDE zeigt die Spezifikationsartefakte in seitlichen Panels, das CLI rendert sie im Terminal, und die Web-Version stellt sie im Browser mit Inline-Review und Mehrbenutzer-Zusammenarbeit dar. Der Agent spricht ACP, und der Client entscheidet, wie er die Ausgabe präsentiert.
Auch Custom Agents profitieren von der Vereinheitlichung. Sie verwenden auf allen Oberflächen dasselbe Markdown-Format unter .kiro/agents/. Eine Agent-Definition enthält Beschreibung, System-Prompt, tag-basierte Werkzeugauswahl, zugängliche Sub-Agenten, Inline-MCP-Serverdefinitionen und Inline-Berechtigungsregeln. Wenn du die Konfiguration eines Custom Agents in die Versionskontrolle eincheckst, bekommt jedes Teammitglied sie in jedem Client. Kein separater Export, kein manuelles Einrichten, keine Syntax-Unterschiede mehr.
Für Entwickler bedeutet das eine spürbare Vereinfachung im Alltag. Eine einmal definierte Agentenkonfiguration funktioniert überall gleich. Eine Sitzung, die im Web beginnt, kann in der IDE weitergeführt werden, weil die Harness den Zustand hält und der Client nur die Darstellung wechselt. Die lästige Frage, in welchem Tool ein bestimmtes Feature verfügbar ist, verschwindet zunehmend. Stattdessen wächst das Vertrauen, dass das Verhalten des Agenten nicht davon abhängt, ob man gerade im Terminal, im Browser oder in der IDE arbeitet.
Natürlich ist eine einheitliche Harness kein Allheilmittel. Die Architektur verschiebt Komplexität, sie löst sie nicht auf. Die Protokollgrenze muss sauber gepflegt werden, und Erweiterungen wie Kiro-ACP brauchen eine klare Versionierung, damit Drittanbieter nicht abgehängt werden. Auch die Entscheidung, die eigene Agentenlogik in einem separaten Prozess zu halten, verlangt Disziplin bei der Gestaltung des Interfaces. Doch der eingeschlagene Weg macht die ursprüngliche Vision zumindest technisch erreichbar: eine kontinuierliche agentische Konversation, die sich über alle Oberflächen erstreckt, mit einer Harness, die überall läuft. Das ist kein Hype, sondern solide Architekturarbeit – und genau die Art von Fundament, auf der man als Entwickler gerne aufbaut.
Quelle: kiro.dev
