![\"Developer](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/08\/1786003451_664_0x0.jpg\")
<\/p>\n<\/p>\n
On August 4, AWS open-sourced<\/a> Kiro Crew under the Apache 2.0 license. Crew turns Kiro from an interactive coding assistant into a persistent agent platform that continues working across sessions, machines and events, provided the underlying host remains available.<\/p>\n The release is significant not because AWS open-sourced another developer tool, but because it reveals where the company believes openness creates value. AWS released the orchestration layer around the agent while keeping the agent runtime itself proprietary.<\/p>\n When I asked Deepak Singh<\/a>, Vice President for Agentic AI at AWS, during a briefing in late July whether the underlying agent harness would also be open-sourced, his answer was unambiguous.<\/p>\n “We are not open sourcing the harness,” he said, adding that AWS’s strategy is to standardize on open protocols rather than open implementations.<\/p>\n That distinction matters. Enterprises can now inspect how long-running agents are orchestrated, scheduled and governed, but not the code that actually plans, reasons and executes the agent loop.<\/p>\n AWS Opened the Orchestration Layer<\/p>\n Kiro Crew is essentially a persistent workspace built around the Kiro CLI<\/a>. It adds the operational capabilities required for autonomous agents rather than improving the underlying model.<\/p>\n Scheduling is the first pillar. Beyond recurring jobs, Crew supports heartbeat-based monitoring that waits for external state changes such as pull requests or deployments before resuming execution. Authenticated webhooks can trigger workflows from external systems, while deterministic tasks can execute as ordinary scripts without invoking an LLM.<\/p>\n Memory is the second pillar. Workspace preferences, project context and execution history persist across sessions. Corrections become reusable knowledge, and repeated interaction patterns evolve into editable skills that developers can inspect, modify or remove.<\/p>\n The third capability is multi-agent coordination through the Agent Client Protocol<\/a> (ACP). Multiple agent conversations execute concurrently within isolated contexts before reporting results back to a parent workflow. Planning, tool invocation and approval decisions remain visible through a live activity view.<\/p>\n Applications form the fourth building block. Instead of treating every task as a chat conversation, Crew introduces standalone applications such as DevFleets for worktree management, Task Runner for long-running execution and Issue Radar for repository triage. AWS also provides an SDK for building additional applications. Its LaunchDarkly integration illustrates the approach, with feature flags flowing into the workspace through MCP, allowing agents to discover flag usage and modify configuration without leaving the development environment.<\/p>\n Security receives equal attention. Crew includes operating-system sandboxing, deny-by-default command execution, sensitive-path protection, credential redaction and signed audit logs. By default, its management dashboard binds only to localhost unless explicitly configured otherwise.<\/p>\n The Runtime Remains Proprietary<\/p>\n The open source boundary is narrower than it first appears.<\/p>\n Crew implements the persistent workspace, scheduling, memory injection, workflow orchestration, approval management and its own runtime policy layer. Underneath it sits the Kiro agent harness<\/a> that AWS described a day earlier. That harness executes the core agent loop, communicates with foundation models, invokes tools and enforces capability-based permissions through Cedar<\/a>.<\/p>\n The result is effectively two policy layers stacked together. Only one is open.<\/p>\n The harness is also not a cloud service. AWS rearchitected Kiro earlier this week around a standalone local process communicating over ACP. Crew therefore drives a locally running Kiro harness rather than calling a hosted API. The architectural separation creates a clean protocol boundary while allowing AWS to retain ownership of the underlying implementation.<\/p>\n This reflects a broader industry trend. Open protocols increasingly define interoperability, while proprietary runtimes compete on execution quality.<\/p>\n Open Protocols Do Not Mean Open Implementations<\/p>\n AWS deserves credit for adopting ACP as the internal boundary between Kiro clients and the agent itself. ACP reached version 1.0 in June 2026 and already has support across tools, including JetBrains IDEs, Zed and Xcode.<\/p>\n But AWS also introduced what it calls Kiro-ACP, extending the protocol with more than twenty additional agent methods covering capabilities such as live steering, specifications and richer permission controls.<\/p>\n That creates two levels of compatibility.<\/p>\n Any ACP client can communicate with Kiro. Only Kiro-aware clients understand the extended capabilities that differentiate the product.<\/p>\n This mirrors earlier platform strategies. Standards establish interoperability, while proprietary extensions preserve product differentiation.<\/p>\n Singh argues that specifications serve both humans and agents.<\/p>\n “Specs are as much agent-facing as human-facing.”<\/p>\n Accordingly, the harness continuously consumes project specifications during execution to maintain alignment. Crew automatically reuses existing .kiro configurations, allowing steering files, skills and custom agents to migrate without modification.<\/p>\n From MeshClaw to Internal Scale<\/p>\n Crew originated inside Amazon as an internal project called MeshClaw. According to AWS, three engineers wanted agents that could continue working while developers focused elsewhere, producing meaningful progress before they returned.<\/p>\n The team acknowledges inspiration from OpenClaw’s autonomous workflow while emphasizing that Amazon required substantially stronger governance controls before such capabilities could be deployed internally.<\/p>\n OpenClaw therefore provides useful competitive context rather than a direct comparison. Its permissive design accelerated experimentation but also exposed governance challenges that enterprises struggled to operationalize. Crew’s emphasis on sandboxing, approval workflows, policy enforcement and auditability can be viewed as AWS’s response to those concerns.<\/p>\n AWS also disclosed unusually detailed internal adoption metrics. More than 39,000 Amazon developers reportedly used Crew within six months, while nearly 500 contributors submitted 597 changes to the project. Governance now operates through a published steering committee<\/a> with design proposals managed through GitHub pull requests.<\/p>\n Those numbers demonstrate meaningful internal validation, although they represent a single enterprise operating within Amazon’s own engineering environment.<\/p>\n Questions Enterprises Should Still Ask<\/p>\n Open sourcing Crew improves transparency around orchestration, but it leaves several operational questions unanswered.<\/p>\n The first concern is audit integrity. AWS describes signed audit logs but has not publicly explained precisely what is signed, where signing keys reside or whether administrators can independently detect deleted or reordered events.<\/p>\n The second concern is policy precedence. Crew introduces its own runtime policies alongside approval settings, while the proprietary harness independently enforces Cedar authorization policies. Enterprises need clarity about which layer ultimately determines execution when policies conflict.<\/p>\n The third concerns operational cost. Crew can execute deterministic jobs without model inference, but any model-backed workflow ultimately runs through the Kiro CLI using Kiro credits<\/a>. Organizations should understand whether spending controls exist at the job, workspace and organizational levels, particularly for long-running workflows that automatically resume after external events.<\/p>\n