diff --git a/docs/landscape.md b/docs/landscape.md
index a15b0260d9..73ac91f777 100644
--- a/docs/landscape.md
+++ b/docs/landscape.md
@@ -237,6 +237,24 @@ An Apache-2.0, Go-first, superhero-themed multi-agent framework. The central the
 * *Gaze's test-quality scoring* is directly relevant to [testing-agents.md](https://github.com/fullsend-ai/fullsend/blob/main/docs/problems/testing-agents.md) and to the "fitness function has to be honest and not gameable" concern that any adaptive-selection experiment has to solve. Coverage as a fitness signal collapses as soon as agents optimize for it; side-effect/behavior scoring is one way to raise the bar. Go-only today, but the idea ports.
 * *Dewey's MCP-gated context* and *Replicator's worktree-per-task isolation* are two narrow, well-scoped primitives worth looking at independently of the wider hero metaphor. They map respectively to [codebase-context.md](https://github.com/fullsend-ai/fullsend/blob/main/docs/problems/codebase-context.md) (how agents acquire codebase understanding without bloating context) and [agent-infrastructure.md](https://github.com/fullsend-ai/fullsend/blob/main/docs/problems/agent-infrastructure.md) (how parallel agents get isolated workspaces). Either can be adopted without adopting the Speckit/OpenSpec workflow.
 
+### Kiro Crew
+
+[Announcement (2026-08-04)](https://kiro.dev/blog/introducing-kiro-crew/) | [Kiro Crew repo](https://github.com/kirodotdev/kirocrew) | [Kiro CLI repo](https://github.com/kirodotdev/Kiro) | [Kiro docs](https://kiro.dev/docs/)
+
+Kiro is AWS's spec-driven AI IDE: a "unified agent harness" spanning desktop, CLI, web, and mobile surfaces, all reading the same `.kiro/` project configuration — specs (requirements/design/tasks), steering files (project standards), hooks (event-triggered automation), skills, and MCP server config. Kiro Crew, open-sourced 2026-08-04 (started internally at Amazon as "MeshClaw"), is an orchestration layer on the Kiro CLI aimed at multi-session, multi-hour work — incident investigation across repos, migrations, recurring code review/test-fix jobs, ticket triage — that keeps moving through checkpoints and retries while a developer works on something else.
+
+**Architecture:** Three layers. **Surfaces** are how a developer works with it — desktop app, web dashboard, TUI, CLI, Slack, Telegram, WeCom. The **Gateway** is the orchestration layer: it persists session state, injects memory and skills, starts scheduled work, coordinates sub-agents, brokers approvals, and enforces runtime policy — deliberately separating *where the agent runs* from *where you work with it*, so a developer can check in from a phone while the Gateway runs elsewhere. **Agent Sessions** are the execution layer, running `kiro-cli` over the [Agent Client Protocol](https://agentclientprotocol.com) — an existing open standard for editor/agent communication, analogous to LSP and originated at Zed, adopted here rather than invented (not to be confused with "Ambient Code Platform," also abbreviated ACP, discussed below). The protocol gives an "Activity view" where task planning, sub-agent spawning, tool selection, and approvals are observable live instead of hidden inside one opaque chat, and lets a parent conversation delegate to sub-agents that "return their results to the parent conversation." "Apps" package a UI with agents, skills, schedules, integrations, and backend services into a shareable interface for recurring work (examples shipped at launch: work-tree management, a long-running task runner, PR/issue triage, and a LaunchDarkly feature-flag app built on an MCP server), plus an SDK for building more.
+
+**Deployment model:** Local-first and self-hosted, not a managed service — "run it locally or on a remote machine you control," including "your Mac, inside a container on your machine, or on a remote Linux host you control." There is no AWS/Kiro-hosted execution tier. This does allow "always-on" operation (a Gateway running on a home server or cloud instance you administer, reached from Slack or the web dashboard), but the state model is single-tenant: session history, memory, config, and the security audit log all live in one local store (`~/.kiro/crew/`, overridable via `KIROCREW_HOME`) per install. The docs and blog post frame everything around "your crew" and "your work"; there is no workspace, tenant, or per-team isolation concept, and the only "enterprise" references are about an admin locking down security policy on an installed instance, not multiple teams or projects sharing one instance with separated state.
+
+**Memory model:** A three-tier stack — **Memory** (preferences and project context carried into new sessions), **Lessons** (corrections that become "durable lessons," some workspace-scoped), and **Skills** (repeated patterns promoted into inspectable, editable, removable artifacts) — kept visible throughout so a developer can decide what a crew carries forward.
+
+**Security:** Described as "defense in depth from day one" — OS-level sandbox, denied-by-default commands, suspicious-pattern and sensitive-path blocking, credential redaction, per-tool-call approval gates, and a signed audit log. This is a hardened-workstation/CLI sandbox model, not a per-event ephemeral container model — a different threat surface than gh-aw's Actions-runner isolation, closer to "the agent runs where the developer runs."
+
+**Relevance to fullsend:** Kiro Crew's Memory/Lessons/Skills split independently arrives at close to the same three-way distinction [cross-run-memory.md](problems/cross-run-memory.md) draws between stable repo guidance, recent operational state, and agent self-assessment — a real-world existence proof that the split is practically necessary, not just tidy in theory. The difference is promotion policy: Kiro Crew promotes an observation to a durable lesson automatically and leaves it inspectable after the fact, whereas fullsend's open question is whether that promotion needs to be review-gated *before* it can influence a different agent (see the memory-as-attack-surface discussion in that document). Kiro Crew's sub-agent delegation and protocol-based observability are a concrete instance of the parent/child pattern discussed in [agent-architecture.md](problems/agent-architecture.md#relationship-to-multi-agent-frameworks) — a single conversation remains the coordinator, and a sub-agent's returned result is consumed by the parent without the zero-trust composition fullsend's independent review sub-agents use. "Apps" as schedule-plus-agent bundles are a lighter-weight cousin of what fullsend would call a workflow harness, but the trust boundary is a developer's own machine (or a server they administer), not a repo's branch protection and CODEOWNERS.
+
+The single-tenant deployment model is itself a useful data point: Kiro Crew answers "how does one developer's agent act on their behalf across sessions and tools" convincingly, but it is architected as *a developer's* crew, not *an org's* factory — there is no described mechanism for one Gateway to safely serve multiple teams or repos with separated memory, audit, and policy. That gap is exactly the shared-vs-per-repo instance question in [agent-infrastructure.md](problems/agent-infrastructure.md#relationship-to-other-problem-areas) and the "who controls the agents' policies" question in [governance.md](problems/governance.md) — fullsend has to answer both to be a viable multi-team, multi-repo system, where Kiro Crew's single-user framing lets it not.
+
 ### Ambient Code Platform (ACP)
 
 [GitHub](https://github.com/ambient-code/platform)
diff --git a/docs/problems/agent-architecture.md b/docs/problems/agent-architecture.md
index 999fede9eb..b4c21e8bfe 100644
--- a/docs/problems/agent-architecture.md
+++ b/docs/problems/agent-architecture.md
@@ -207,6 +207,8 @@ The multi-agent framework space is expanding rapidly, with new entries appearing
 
 **FSM framing (AAMAS 2025).** Researchers demonstrated that all multi-agent architectures — linear, decentralized debate, and orchestrated — are specialized finite state machines. Fullsend's model maps naturally to an FSM where states are PR lifecycle stages, transitions are triggered by GitHub events, and transition guards are branch protection rules. This framing could be useful for formal reasoning about deadlock and liveness properties.
 
+**Observable delegation, still a single coordinator ([Kiro Crew](../landscape.md#kiro-crew)).** Kiro Crew lets a parent conversation delegate to sub-agents that "return their results to the parent conversation," with every step — planning, sub-agent spawning, tool selection, approvals — observable live via the Agent Client Protocol. The observability is worth borrowing: making agent reasoning and tool calls inspectable in real time, rather than only after the fact in a transcript, is a good default regardless of coordination model. But the coordination model itself is the same star topology as MetaGPT and CrewAI — the parent conversation is the coordinator, and it consumes a sub-agent's returned result without the zero-trust composition fullsend's independent review sub-agents apply to each other's findings. It is a session-scoped pattern (one developer's crew, running on their own machine or a remote host they control) rather than a repo-scoped one, so it does not need to answer the question this document is built around: what authorizes a decision when no single human or agent is watching.
+
 ## Open questions
 
 - Should agents be stateless (fresh context per task) or stateful (accumulated knowledge of the codebase)? Stateless is safer (no poisoned state persists) but less efficient.
diff --git a/docs/problems/cross-run-memory.md b/docs/problems/cross-run-memory.md
index 8e7f821836..24cb6ba5da 100644
--- a/docs/problems/cross-run-memory.md
+++ b/docs/problems/cross-run-memory.md
@@ -62,6 +62,10 @@ Any eventual design needs to split several concerns that are easy to conflate:
 
 These splits suggest that "memory" may not be one feature. It may be several feedback paths with different trust levels, retention windows, and promotion rules.
 
+## Industry precedent
+
+[Kiro Crew](../landscape.md#kiro-crew) ships a three-tier stack — Memory (preferences/project context), Lessons (corrections promoted into "durable lessons"), Skills (repeated patterns promoted into inspectable, editable, removable artifacts) — that lands close to the stable/tactical/self-assessment split above, independently arrived at. It is a useful existence proof that the split is practically necessary rather than a theoretical nicety. But its promotion model differs from what this document is asking: Kiro Crew promotes automatically and makes the result inspectable after the fact ("you decide what your crew carries forward" is a review step that happens post hoc, by the same user who is already trusting the tool). The open question here is whether promotion needs to be gated *before* a lesson can reach a different agent — particularly across roles, per [What must be separated](#what-must-be-separated) above — rather than left to after-the-fact inspection by whoever is already running the crew.
+
 ## Constraints
 
 - **The sandbox should remain ephemeral.** Cross-run learning should not imply persistent sandbox state.