AWS hat Kiro Crew geöffnet. Den Harness behielt es.

Ist Kiro Crew Open Source? Ja, tatsächlich, und zwar in größerem Umfang, als ich erwartet hatte. Ist auch das Open Source, was es nützlich macht? Das ist eine andere Frage, und genau in der Antwort liegt der interessante Teil dieses Launches.

Am 4. August veröffentlichte AWS Kiro Crew, einen persistenten agentischen Arbeitsbereich, der Coding-Agenten über Sitzungen, Zeitpläne und Messaging-Oberflächen hinweg weiterlaufen lässt, unter der Apache-2.0-Lizenz. Das Projekt begann bei Amazon als Nebenprojekt namens MeshClaw, verbreitete sich innerhalb von weniger als sechs Monaten auf mehr als 39.000 interne Entwickler und lebt nun in einem öffentlichen Repository mit offenem Governance-Modell. Ich habe die Ankündigung, das Repository und die Lizenz gelesen und Zeit damit verbracht, den tatsächlichen Repository-Inhalt den AWS-Komponenten gegenüberzustellen, die das Produkt weiterhin zum Funktionieren braucht. Diese Grenze ist bewusst gezogen, und man sollte sie verstehen, bevor man auf einer der beiden Seiten darauf aufbaut.

Wichtigste Erkenntnisse - Kiro Crew ist ein persistenter agentischer Arbeitsbereich von AWS, der am 4. August 2026 unter Apache 2.0 als Open Source veröffentlicht wurde. Er begann als internes Amazon-Nebenprojekt namens MeshClaw und wurde vor der Veröffentlichung von mehr als 39.000 Entwicklern genutzt. - Offen sind: das Gateway mit Sitzungen, Speicher, Planung, Freigaben und Sicherheitsrichtlinien, das Dashboard, die CLI, die Desktop-App, Apps und das App SDK, Skills sowie der vollständige Security-Stack. All das lässt sich lesen, forken und selbst hosten. - Geschlossen bleiben: die Kiro CLI, also die Agent-Engine, die Crew über das Agent Client Protocol steuert, außerdem Kiro-Anmeldung, Modell-Routing und Credit-Abrechnung. Crews Agent-Provider ist fest auf ACP und kiro-cli eingestellt, daher läuft jeder Modellaufruf weiterhin durch das kommerzielle AWS-Produkt. - Es handelt sich um einen teilweise offenen Vendor-Harness, nicht um eine offene Agent-Runtime. Zum Vergleich: TrueForge hat den Harness selbst unter MIT geöffnet und behandelt jedes Modell lediglich als weiteren Endpunkt. - Das Design ist trotzdem nützlich. Selbst gehosteter Zustand, sichtbarer Speicher und ein ernst zu nehmendes Sicherheitsmodell sind echte Vorteile. Man sollte nur klar wissen, auf welche Schicht man sich festlegt.

Was passiert ist

Am 4. August 2026 veröffentlichte AWS die Ankündigung zu Kiro Crew und öffnete das Repository kirodotdev/KiroCrew unter Apache 2.0. Noch in derselben Woche erschienen Berichte bei SiliconANGLE und DevOps.com. Als ich nachsah, lag das Repository bei ungefähr 3.400 Stars und 400 Forks. Die wichtigsten Fakten:

• Kiro Crew ist ein persistenter Arbeitsbereich für Entwicklungsagenten: mehrstufige Aufgaben, die unbeaufsichtigt laufen, wiederkehrende geplante Jobs, Heartbeats, die einen PR oder ein Deployment beobachten, bis etwas Aufmerksamkeit braucht, sowie Subagenten, die parallel ausschwärmen und anschließend Bericht erstatten.

• Es läuft dort, wo man es platziert: als Desktop-App, über eine Einzeileninstallation, als Docker-Image auf GHCR oder auf einem entfernten Linux-Host unter eigener Kontrolle. Der Zustand mit Sitzungen, Speicher und Checkpoints liegt auf der eigenen Hardware unter ~/.kiro/crew, nicht in einer AWS-Control-Plane.

• Arbeit erreicht Crew über ein Web-Dashboard, eine CLI, eine Desktop-App oder Messaging-Oberflächen: Slack, Discord, Telegram, Teams, Webex, WeCom, WeChat und WhatsApp.

• Es entstand aus MeshClaw, einem internen Amazon-Nebenprojekt, das von OpenClaw inspiriert war und laut Ankündigung mehr als 39.000 interne Entwickler erreichte. Fast 500 Mitwirkende lieferten vor der öffentlichen Veröffentlichung annähernd 600 Updates.

• Die Governance ist öffentlich: ein in MAINTAINERS.md aufgeführtes Steering Committee sowie Vorschläge, die als Pull Requests eingereicht und diskutiert werden. Derzeit sind die Maintainer Kiro- und AWS-Ingenieure, mit dem erklärten Ziel, externe Maintainer aufzunehmen, sobald sich vertrauenswürdige Mitwirkende herausbilden.

Kiro Crew ist ein Open-Source-Arbeitsbereich unter Apache 2.0 für persistente agentische Arbeit, den AWS am 4. August 2026 veröffentlicht hat. Er führt unbeaufsichtigte mehrstufige Aufgaben, geplante Jobs, Heartbeats und Subagenten aus und wird laut AWS-Ankündigung und Projekt-Repository auf der Hardware des Nutzers selbst gehostet.

Welche Schichten offen sind und welche nicht

Diesen Teil hat die Berichterstattung größtenteils übersprungen, deshalb bin ich selbst durch das Repository gegangen. Die Architektur hat drei Ebenen: die Oberflächen, über die man interagiert, also Dashboard, Desktop, CLI und Messaging; das Gateway, das den Zustand hält, also Sitzungen, Speicher, Zeitpläne, Freigaben und Sicherheitsrichtlinien; und die Agent-Sitzungen, die den eigentlichen Modell-Loop ausführen. Hier verläuft die Lizenzgrenze:

Die tragende Grenze steht in der Konfigurationsdokumentation: agent.provider ist fest auf acp eingestellt, und Kiro Crew steuert kiro-cli über das Agent Client Protocol. Jede Modellanfrage wird von kiro-cli unter dem eigenen Kiro-Konto und dessen Modellkonfiguration verarbeitet. Der Arbeitsbereich, der Speicher, die Zeitpläne, die Sicherheitsposition: alles gehört einem selbst, alles lässt sich forken, alles lässt sich verifizieren. Die Engine, die schlussfolgert, und die Abrechnung, die sie misst: AWS.

Gateway, Oberflächen, Apps und Sicherheitslayer von Kiro Crew sind im KiroCrew-Repository unter Apache 2.0 als Open Source verfügbar, doch die darunterliegende Agent-Engine kiro-cli bleibt ein geschlossenes AWS-Produkt. Crews Agent-Provider ist fest auf ACP über kiro-cli eingestellt, daher bleiben Modellzugriff, Anmeldung und Credit-Abrechnung unter AWS-Kontrolle.

Warum die Grenze genau dort verläuft

Die bequeme Lesart wäre, AWS habe Crew aus Gutwilligkeit geöffnet oder als Falle. Die nützlichere Lesart ist, dass die Grenze dem Geld folgt und dies ziemlich ehrlich tut.

Den Arbeitsbereich verschenken, Engine und Zähler behalten. Das ist derselbe Tausch, den viele vernünftige Open-Source-Infrastrukturprojekte anbieten, und AWS sagt offen, wie es funktioniert: In der Ankündigung steht, dass Crew auf der Kiro CLI läuft und die vorhandene .kiro-Konfiguration direkt übernimmt. Wer ohnehin in Kiro lebt, bekommt mit Crew ein Geschenk. Steering-Dateien, Skills und eigene Agenten lassen sich übernehmen, und die Agenten erhalten kostenlos Persistenz, Planung und ein Dutzend Messaging-Oberflächen. Die 39.000 internen Nutzer sind ein Beleg dafür, dass diese Form im großen Maßstab funktioniert, nicht nur eine Marketingzeile.

Aber man sollte beachten, was die Offenheit AWS bringt. Jede Crew-Installation ist auch eine Kiro-Installation, weil beim ersten Start kiro-cli und die Device-Code-Anmeldung eingerichtet werden. Jeder Agent-Turn wird über Kiro-Credits auf den Modellen abgerechnet, zu denen Kiro routet. Kiros Routing umfasst auf Bedrock Claude sowie chinesische offene Modelle wie Qwen, DeepSeek, GLM und MiniMax. Ein früher Nutzer verbrauchte in einer Woche 5.000 Credits für persönliche Projekte. Das zeigt, was ein dauerhaft aktiver Agent-Arbeitsbereich mit einem gemessenen Modellplan macht. Die offene Schicht vergrößert den Funnel für die geschlossene, und die geschlossene Schicht ist die, in der der Umsatz liegt. Nichts davon wird versteckt, und nichts davon ist finster. Es lohnt sich nur, es klar zu sehen, denn in derselben Woche kam eine vollständig offene Alternative heraus, die die Grenze an einer anderen Stelle zog.

Noch etwas innerhalb der offenen Schicht verdient Anerkennung. Das Sicherheitsmodell wird an der Runtime-Grenze statt durch Prompts durchgesetzt: OS-Sandboxing unter Linux und macOS, standardmäßig verweigerte Befehle, Redaction von Zugangsdaten und unter Windows eine Fail-Closed-Haltung, bei der Agent-Subprozesse abgelehnt werden, statt unbeschränkt zu laufen, sofern man nicht ausdrücklich zustimmt. Weil alles im Repository liegt, kann man jede Schicht prüfen, statt einer Vendor-Seite zu vertrauen. Das ist das stärkste Argument dafür, dass der offene Teil echt und keine Inszenierung ist.

Der offene Arbeitsbereich von Kiro Crew führt Nutzer in die geschlossene, gemessene Kiro-Engine: Jede Installation richtet kiro-cli und die Kiro-Anmeldung ein, und jeder Agent-Turn wird gegen Kiro-Credits abgerechnet. Der Security-Stack mit OS-Sandbox, standardmäßig verweigerten Befehlen, Redaction von Zugangsdaten und Audit-Logs ist im Repository tatsächlich offen und auditierbar.

Der Kontrast zu TrueForge

Zwei Wochen nach Kiro Crew veröffentlichte TrueFoundry TrueForge unter MIT, und zusammen bilden die beiden ein sauberes natürliches Experiment dafür, wie viel von einem Agent-Stack ein Anbieter bereit ist abzugeben.

TrueForge öffnete den Harness selbst: den Loop um das Modell, Sitzungen, Sandboxing, Freigaben und Context Management. Jeder OpenAI-kompatible Endpunkt lässt sich anschließen, sodass das günstigste Modell, das eine Aufgabe abschließt, den Workload gewinnen kann, während die kommerzielle Schicht darunter als optionales Gateway sitzt, das man ablehnen kann. Kiro Crew öffnete alles um den Harness herum: Persistenz, Planung, Oberflächen und Sicherheitsrichtlinien. Der Harness selbst, kiro-cli, bleibt geschlossen, und die Model Plane dahinter ist das Produkt.

Keines von beiden ist unehrlich, aber es sind unterschiedliche Verpflichtungen mit unterschiedlichen Ausfallmodi. Forkt man TrueForge, behält man eine funktionierende Agent-Runtime und verliert TrueFoundrys Gateway und Support. Forkt man Kiro Crew, behält man einen hervorragenden Arbeitsbereich ohne Engine darin. Sobald kiro-cli sein Protokoll, seine Preise oder seinen Abschaltplan ändert, erbt der eigene Fork das Problem. Wer Build versus Buy für den eigenen Agent-Stack abwägt, sollte bei jedem teilweise offenen Produkt genau diese Frage stellen: Welche Schicht funktioniert nicht mehr, wenn sich die Roadmap des Vendors verschiebt? Dasselbe habe ich allgemein zu agentischer Architektur geschrieben: Die interessante Frage ist selten, welches Modell verwendet wird. Entscheidend ist, was es umschließt und wem dieser Wrapper gehört.

Die Hangzhou-Fußnote kann ich mir nicht verkneifen: Kiros Routing behandelt Qwen, DeepSeek, GLM und MiniMax auf Bedrock bereits als vollwertige Optionen, und Crew liefert WeCom- und WeChat-Connectoren standardmäßig mit. Chinesische Modelle und chinesische Messaging-Oberflächen als ganz gewöhnliche Bestandteile des Stacks eines amerikanischen Anbieters. Mit einer gewissen Genugtuung notiert, aus der Stadt, in der die Hälfte dieser Modelle entsteht.

Was jetzt zu tun ist

Wenn Sie Kiro Crew evaluieren, dann in drei Schritten und in dieser Reihenfolge.

1. Heute: Lesen Sie das Repository, bevor Sie etwas installieren. Beginnen Sie mit dem Architekturabschnitt der README, GOVERNANCE.md und MAINTAINERS.md und gehen Sie dann zu den Security-Dokumenten. Der Sinn der offenen Schicht ist, dass man sie verifizieren kann, also tun Sie genau das. Die Installation selbst ist ein Einzeiler, und das Dashboard bindet standardmäßig an localhost.

2. Diese Woche: Lassen Sie Crew auf einem klar begrenzten, risikoarmen Workload laufen: etwa einer geplanten PR-Überwachung, einem morgendlichen Digest oder einer wiederkehrenden Review. Beobachten Sie im Activity View und im Audit-Log, was es tut, und verfolgen Sie Ihren Credit-Verbrauch. Persistente Agenten geben Geld aus, während Sie schlafen. Das ist das Produkt, das wie vorgesehen funktioniert, und zugleich ein Budgetthema.

3. Diesen Monat: Entscheiden Sie, auf welche Schicht Sie sich festlegen. Wenn Sie bereits Kiro nutzen, ist Crew ein leichtes Ja. Wenn Sie einen Stack von Grund auf auswählen, vergleichen Sie die Grenze mit einem vollständig offenen Harness wie TrueForge und denken Sie die Self-Hosting-Abwägungen durch, bevor sich die Workflows Ihres Teams um eine der beiden Optionen verhärten. Wenn Sie fortfahren, nimmt Crew dank MCP-Unterstützung Ihre bestehenden Tools mit; meine Auswahl an MCP-Servern, die sich anzubinden lohnen, ist ein vernünftiger Startpunkt.

FAQ

Ist Kiro Crew Open Source?

Der Arbeitsbereich ist es: Gateway, Dashboard, Desktop-App, CLI, Apps, Skills und der gesamte Security-Stack stehen im Repository kirodotdev/KiroCrew unter Apache 2.0, und all das lässt sich auf eigener Hardware ohne AWS-Control-Plane selbst hosten. Die darunterliegende Agent-Engine kiro-cli ist nicht Open Source, und Crew kann ohne sie nicht laufen. "Open Source" ist also für das Repository korrekt, als Beschreibung des gesamten Produkts aber unvollständig.

Braucht Kiro Crew ein AWS-Konto?

Es braucht eine Kiro-Anmeldung, die über kiro-cli Modellzugriff und Credit-Abrechnung abwickelt. Für die lokale Nutzung muss nichts in einem AWS-Konto bereitgestellt werden; Arbeitsbereich und Zustand bleiben auf dem eigenen Rechner. Wer eine dauerhaft aktive Remote-Instanz möchte, kann mit kirocrew cloud launch eine auf EC2 im eigenen AWS-Konto bereitstellen, aber ein normaler Linux-Server oder ein Home Lab funktioniert ebenfalls.

Wie unterscheidet sich Kiro Crew vom autonomen Modus von Kiro?

Im Umfang. Der autonome Modus bearbeitet eine Aufgabe in einer Sitzung, während man zusieht. Crew bleibt über Sitzungen und Neustarts hinweg bestehen, führt geplante und reaktive Arbeit aus, egal ob man online ist oder nicht, orchestriert Subagenten parallel und übernimmt Speicher, Lessons und Skills von einem Lauf zum nächsten. Es ist eine neue Oberfläche auf derselben Kiro-Engine und liest dieselbe .kiro-Konfiguration.

Kann ich Kiro Crew mit einer anderen Agent-Engine oder einem anderen Modellanbieter verwenden?

Heute nicht. Der Agent-Provider ist fest auf ACP über kiro-cli eingestellt, daher stammen Modelle aus dem Routing des eigenen Kiro-Kontos, das derzeit Claude sowie offene Modelle wie Qwen, DeepSeek, GLM und MiniMax auf Bedrock umfasst. Das Governance-Modell ist öffentlich, und die Maintainer sagen, dass externe Beiträge willkommen sind. Eine austauschbare Engine ist daher denkbar, aber sie gehört nicht zum ausgelieferten Design, und ich würde nicht darauf planen.

Fazit

Kiro Crew ist ein gutes Open-Source-Projekt um eine geschlossene kommerzielle Engine herum, und AWS war bei dieser Konstruktion geradliniger als die meisten Anbieter. Die offene Schicht ist real: selbst gehosteter Zustand, sichtbarer Speicher, ein auditierbares Sicherheitsmodell, öffentliche Governance. Die geschlossene Schicht ist ebenfalls real: der eigentliche Harness, die Anmeldung, der Zähler. Wenn man genau weiß, auf welcher Seite dieser Linie die eigene Verpflichtung liegt, ist Crew die Zeit wert. Wer die Linie an einer anderen Stelle braucht, bekam im selben Monat einen MIT-lizenzierten Harness, der sie dort zieht.

Wenn Sie herausfinden wollen, wo die offene Grenze in Ihrem eigenen Agent-Stack verlaufen sollte, ist das ein Gespräch, das ich regelmäßig mit Kunden führe. Kontakt aufnehmen.

Quellen

• Kiro (AWS), "Introducing Kiro Crew": https://kiro.dev/blog/introducing-kiro-crew/ (veröffentlicht 2026-08-04, abgerufen 2026-08-29)

• kirodotdev, KiroCrew-Repository (README, LICENSE, GOVERNANCE.md, Security-Dokumente): https://github.com/kirodotdev/KiroCrew (abgerufen 2026-08-29)

• Kiro, Kiro-Crew-Produktseite (Lizenz- und Funktions-FAQ): https://kiro.dev/crew/ (abgerufen 2026-08-29)

• SiliconANGLE, "AWS launches Kiro Crew, an autonomous agentic orchestrator for 24/7 code development": https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/ (veröffentlicht 2026-08-04, abgerufen 2026-08-29)

• DevOps.com, "AWS Adds Agentic Workspace to Kiro AI Coding Tool": https://devops.com/aws-adds-agentic-workspace-to-kiro-ai-coding-tool/ (veröffentlicht 2026-08-05, abgerufen 2026-08-29)

• Playing AWS, "Kiro Crew after one week (and more than 5000 credits)": https://www.playingaws.com/posts/what-is-kirocrew/ (veröffentlicht 2026-08-08, abgerufen 2026-08-29)