Kiro Workflows vs Cursor Projects: two different bets on structured AI development

In 2026, two major tools moved into the structured AI development space from different directions. Kiro, Amazon's spec-driven IDE, shipped Workflows - a set of named lifecycle recipes that run agent tasks in sequence with human-approval gates. Cursor, the dominant AI-first editor, shipped Projects - a coordinator-plus-subagents model that delegates a large body of work to an AI that plans and dispatches it on cloud VMs.

Both are now "structured AI development" tools. But what they mean by structure is very different, and the tradeoffs have real consequences for teams choosing between them.

Kiro Workflows: preset recipes, spec-first, Bedrock-billed

Kiro is built on Code OSS (the open-source base behind VS Code) and runs on Amazon Bedrock. Its core thesis is spec-driven development: before an agent writes code, it produces a spec - a structured artifact that captures requirements, edge cases, and implementation intent. You review the spec; the agent builds from it.

Kiro Workflows (IDE 1.2, September 30 2026) extend this with named, sequenced multi-step pipelines. Three recipes ship out of the box:

• investigate - reads the codebase and produces an analysis
• feature-pipeline - spec, then design, then implementation, with gates between each step
• publish-pr - formats, tests, and opens a pull request

Each recipe runs in a background cloud session and shows its nested steps in a Workflows panel with status, timing, and intervention options. Workflows pause on input - when a step needs human review or a decision before continuing. CLI 2.34.0 (October 23) extended this with MCP tools that can present a form or link when they need more information mid-workflow.

Recent releases added more depth. Kiro Crew 0.9.0 (October 16) introduced crewmate profiles, token usage tracking, and remote crews as live windows - the first concrete team layer on top of the workflow machinery. Cross-session persistent memory (IDE 1.4.0, October 19) carries repo conventions and prior corrections between sessions, reducing the "re-explain the codebase" friction for returning agents.

Where Kiro Workflows is strong:

• Structured hand-off points. Each recipe has defined steps with explicit pause-for-input gates. You know when an agent expects your review and what it expects you to review, which is more predictable than watching an agent run and hoping it stops at the right moment.
• Spec as source of truth. The spec artifact is a first-class thing - reviewable, revisable, passed to subsequent agents as context. For teams where "what we are building" needs to be documented and agreed on, the spec model has real value.
• AWS distribution and Bedrock model breadth. Kiro supports the full Claude family via Bedrock plus other models. For teams in the AWS ecosystem or with multi-model requirements, this is relevant.
• Familiar environment. Code OSS means VS Code habits transfer. Teams that do not want to adopt a new editor surface can extend what they already know.

Where Kiro Workflows adds friction:

• Preset recipes, not your process. The three bundled workflows are Kiro's view of how development should go. If your team's actual flow is different - different stage order, different review criteria, different hand-off moments - you are adapting to Kiro's model, not encoding your own.
• Bedrock billing, not your Claude subscription. Kiro's interaction-based pricing (Free: 50/month; Pro: $19/month for 1,000; Pro+: $39 for 3,000) is separate from any Claude Code or Anthropic subscription you already pay for. Teams that run heavy agentic sessions accumulate two parallel cost structures.
• No visual design stage. Kiro's design surface is text-based specs. There is no step that renders a visual prototype, collects annotations, or gates implementation on a reviewed design. Spec-in, code-out.

Cursor Projects: AI-directed delegation, cloud-by-default, still beta

Cursor Projects (September 10 2026, BETA) is a different model. A coordinator agent plans the work and breaks it into pieces - then delegates each piece to subagents that implement it. The coordinator does not write code itself. It manages. Subagents run in their own isolated context windows; finished work comes back as pull requests for you to review.

The execution model is cloud-by-default. Each Project runs on its own machine in Cursor's cloud infrastructure - a VM that clones your repo, installs dependencies, and stays alive when your laptop is closed. A local agent spins up only when a step specifically needs your machine. This means parallelism is not limited by your hardware, and work continues while you are away from the computer.

Since Cursor 2.5, subagents run asynchronously - the coordinator keeps working while subagents are in progress. Subagent nesting is hard-capped at two levels (main coordinator, L1 subagents, L2 subagents; no deeper). Cursor's own documentation recommends a flat main-to-specialists dispatch rather than deep hierarchies. Cloud Agents support only one level of nesting.

Where Cursor Projects is strong:

• Cloud-scale parallelism. Running subagents on cloud VMs means parallelism is not bounded by your laptop. For genuinely large bodies of work - migrations, large refactors, multi-component features - the ceiling is higher than a local runner can offer, and closing your machine does not stop progress.
• AI-directed decomposition. You describe the outcome; the coordinator decides how to break down the work. This reduces the overhead of decomposing large features into agent-sized tasks yourself.
• Existing Cursor integration. For teams already on Cursor, Projects is an additional tab rather than a new tool. Editor context, model routing, and billing stay in one place.

Where Cursor Projects adds friction:

• Cloud-by-default data residency. Code is cloned to Cursor's cloud VMs by default. For teams on sensitive codebases or under data-residency requirements, this needs explicit evaluation.
• Cost scales linearly with parallelism. Running five subagents uses roughly five times the tokens - Cursor's own framing. Token-by-token billing through Cursor's cloud agent pricing means parallel cost multiplies with subagent count. A spend limit is required before launching the first cloud agent.
• Less predictable planning. The coordinator decides how to decompose the work. You review PRs when subagents finish, but you do not necessarily see the plan before execution starts. For teams that want to sign off on the approach before agents begin building, this is a gap.
• Still in beta. Mechanics and pricing may change. GA timing is not confirmed as of this writing.

Which to pick

Both are genuinely useful, and the right choice depends more on your team's working style than on raw capability. Kiro's recipe model maps well to teams that operate inside structured VS Code conventions and want explicit checkpoints between steps. Cursor Projects fits teams that are Cursor-native and want to delegate large multi-component work at cloud scale. For a broader view of where these and other approaches land relative to each other, which agentic coding patterns actually scale covers the tradeoffs across supervised single-agent, parallel runners, skills frameworks, and gated lifecycle approaches.

The process layer both leave open

Kiro Workflows offers structured recipes. Cursor Projects offers AI-directed delegation. Both are more structured than running a single agent without guidance. But in both cases, the structure is defined by the tool, not by your team. Kiro's stages are Kiro's view of how development should go. Cursor's coordinator decides how to decompose the work. Neither gives you a way to encode your own development process - your stage names, your approval criteria, your visual design step, your specialist review gate - as the thing that runs every time.

That is what defract is built around: running your process on Claude Code. Story, design, architecture, implementation, review, release - with a visual design stage where you annotate a prototype before implementation starts, and specialist review agents that check each other's work before you sign off. Whether the preset-vs-authored tradeoff matters depends on how opinionated your team is about its process. If Kiro's or Cursor's recipes fit your workflow, the preset model is simpler. If they don't, why AI coding agents need hard stage boundaries and spec-driven development explained are useful reads on why the structure of the process matters as much as having one at all. Detailed comparisons of each tool are at defract vs Kiro and defract vs Cursor.