{"slug": "introduction-to-kiro-workflows", "title": "Introduction to Kiro Workflows", "summary": "Kiro has introduced Kiro Workflows, a feature that lets users orchestrate multiple agents through a structured, declarative JSON or YAML graph of ordered steps, parallel branches, and conditional loops. The Kiro Runtime executes each step in its own session in the background, passing results forward via output references so that a reviewer agent can evaluate work without inheriting the reasoning of the agent that wrote the code. Workflows are defined from five node types — step, sequence, parallel, repeat, and watch — of which only step actually invokes an agent, with inputs treated as interpolated template strings rather than validated types.", "body_md": "Kiro Workflows is a new Kiro feature that lets users orchestrate multiple agents by defining the flow in a structured, declarative language (JSON or YAML). The workflow organizes the work as a graph made of ordered sequences of agent steps, parallel branches, and loops with conditional stops.\n\nThe Kiro Runtime executes workflows in the background, running each step in its own session. This means a reviewer agent can evaluate the work without inheriting the reasoning of the agent that wrote the code. Every step passes its results forward through output references. Loops repeat until a condition is met (an approval verdict, for example), and the whole run reports its progress back to our main chat session, so we can let the work continue, answer an occasional question, or offer guidance mid-run.\n\nIn short, while a regular chat session forces the user to guide the model through each phase and remind it over and over of earlier decisions, a workflow captures that process once as a reusable recipe and lets the runtime execute it — turning \"implement..., now review..., now fix...\" into a single process you can refine and run again.\n\nA Workflow schema looks similar to this:\n\n```\n{\n    \"name\": \"\",\n    \"description\": \"\",\n    \"inputs\": {\n        # Values that are going to be interpolated when referenced. \n    },\n    \"steps\": [\n        {\n            \"type\": \"\",\n            \"id\": \"\",\n            \"steps\": [\n                {\n                    \"type\": \"step\",\n                    \"id\": \"\",\n                    \"agent\": \"\",\n                    \"prompt\": \"\",\n                    \"artifacts:\" {\n                        # Agent report as a file\n                    }\n                },\n            ]\n        }\n    ]\n}\n```\n\nThere are five node types in a Kiro workflow:\n\n`all`, `allSettled`, or `any`).` maxIterations` is reached), with an `onMaxIterations` behavior of `abort`, `continue`, or `pause`.` github-pr`) or a custom `command` handler.\nA small terminology note: only `step` actually runs an agent. The other four are structural or control-flow nodes — `sequence`, `parallel`, and `repeat` organize other nodes, and `watch` observes an external system without invoking a model. So if the question is specifically \"how many types of *agent steps* are there\", the answer is one (`step`); if it's \"how many node types is a workflow graph built from\", the answer is five.\n\nIn a Kiro workflow, `inputs` are template variables, not a typed schema.\n\nFor example, in the project the `inputs` are a map where each key is a variable name and the value is a type hint string — a human-readable description, not an enforced type:\n\n```\n\"inputs\": {  \"profile\": \"AWS SSO profile for credentialed phases (default: Walsen)\",  \"run_deploy\": \"whether to run `just deploy` (default: false)\"}\n```\n\nThat `\"whether to run ... (default: false)\"` string is documentation for whoever reads it; the runtime doesn't convert `run_deploy` into a boolean or validate it. At launch, whatever we pass as inputs is substituted into the step prompts wherever `{{run_deploy}}`, `{{profile}}`, etc. appear.\n\nSo the practical picture is:\n\n`\"prompt\"`, `\"file\"`, `\"string\"`, `\"whether to...\"`, a path description, a branch name. These are conventions you'll see in the bundled recipes (e.g. `goal: \"prompt\"`, `prd_path: \"file\"`, `max_iterations: ...`), but they're descriptive labels, not a validated type system.`workflowPath` with `inputs`, every value is a string (that's why `run_deploy` is passed as `\"false\"`, the string, not a JSON boolean). The runtime interpolates them as text into the prompts.`{{run_deploy}}` and the prompt tells the agent \"if this isn't `true`, don't deploy\". The agent interprets it; the runtime just hands over the string.\nCommon conventions for what inputs represent (not enforced types, just how they're typically used):\n\n`goal`, `prompt`, `research_directions`).` design_path`, `prd_path`, `report_path`, `workdir`, `spec_dir`, `worktree_path`).` branch`, `worktree_branch`, `mainline_branch`).` profile`, `max_iterations`).\nTwo caveats so this isn't misleading:\n\nStep outputs are something different from inputs. Besides launch inputs, steps reference each other through `{{step_id.output}}` and `{{previous.output}}`, and artifacts through `{{artifacts.<name>}}`. Those aren't declared in `inputs` — they're produced at runtime. The validator does check those structural references (that a referenced step runs earlier and produces output), while it doesn't validate the `inputs` type hints.\n\nFor recipe forms that take `inputs` at launch (a `workflowPath` or a `bundled://`/` agent://` recipe), keep the values short — paths, branches, one-line strings. The long task text goes in the recipe's step prompts (embedded when the workflow is created), not passed as a launch input.\n\nSo, to answer directly: there's no fixed set of input *types* that Kiro enforces — inputs are named string variables with descriptive type hints, and the \"type\" is really just a convention (prompt / path / reference / flag / scalar) that the step prompts give meaning to.\n\nThe registered agents available in Kiro — the set you can name in the `agent` field of a `step` node — are these nine built-in `wf-*`/reviewer agents:\n\n`wf-coder` — reads files, edits code, runs tests, makes commits; general implementation.`wf-planner` — investigates a codebase and produces an ordered implementation plan.`wf-design` — writes requirements and technical design documents for a feature.`wf-design-reviewer` — reviews technical designs looking for ambiguity, gaps, and unverified assumptions; mechanical verdict.`semantic_reviewer` — behavioral and narrative code review of a local diff or a PR; writes a review and a verdict.`wf-review-aggregator` — merges several review outputs into a single consolidated verdict.`wf-auto-researcher` — autonomous research subagent: runs experiments, benchmarks, commits improvements.`wf-pr-submitter` — opens a pull request from a branch and records the PR metadata.`wf-pr-responder` — responds to PR review comments and CI feedback.\nThere's also `wf-workflow-creator`, the agent that designs/saves workflow definitions, but you normally wouldn't put it in a step.\n\nFor one of my talks, I built a small project: an online Sudoku deployed on AWS Amplify with Lambda and DynamoDB as the backend.\n\nFor this project I wanted 2 things:\n\nFor anyone who wants to see the project, it's available [here](https://github.com/Walsen/observability-workshop).\n\nHere are the workflows in action: [https://youtu.be/zqEOtFmRC_I](https://youtu.be/zqEOtFmRC_I)\n\n*For English speakers, the video is in Spanish but you can activate the titles in English.*\n\nJust like when KiroCrew came out, Kiro Workflows has its flaws: it's hard to understand how to enable them or how to run them, and the documentation isn't that clear. Although it's as simple as telling Kiro \"run the workflow ....\".\n\nI've heard comments that it consumes a lot of tokens, but honestly that hasn't happened to me: the testing workflow took no more than 70 tokens, and the implementation one about 150, so I think that's very reasonable. It's also obvious that I haven't used it in the most correct way, just as far as intuition and Kiro have taken me.\n\nIt's a feature with huge potential: it lets you run flows in many ways, include them in automation, generate them dynamically, and much more.\n\nI think we need to wait, use them, and send the right feedback to the Kiro Team so it gets shaped around the market's real needs.\n\n[**Workflows (overview)**](https://kiro.dev/docs/workflows/) — The concept: graphs of agent steps, sequences, loops, and parallel branches; each step in its own fresh session.\n\n[**Author workflows**](https://kiro.dev/docs/workflows/authoring/) — How recipes are created (describe the outcome in chat, Kiro generates the graph, save it as a recipe to reuse it). This is where node types, `{{...}}` references, and inputs are covered.\n\n[**Workflow examples**](https://kiro.dev/docs/workflows/patterns/) — The shapes of the bundled recipes (and a note that the set of bundled recipes may vary between client versions).\n\n[**Run and manage workflows**](https://kiro.dev/docs/workflows/manage/) — Background execution, checkpointing, node state/outputs/artifacts, loop (repeat) progress, watch cursors, pause/resume.\n\nSupporting references:\n\nStart at [https://kiro.dev/docs/workflows/](https://kiro.dev/docs/workflows/) and the authoring page beneath it — that's the closest thing to a schema reference for the definitions we discussed (node types, inputs as `{{...}}` template variables, `{{step_id.output}}` references, the `wf-*` step agents).", "url": "https://wpnews.pro/news/introduction-to-kiro-workflows", "canonical_source": "https://dev.to/w4ls3n/introduction-to-kiro-workflows-2f8o", "published_at": "2026-10-03 22:53:45+00:00", "updated_at": "2026-10-03 23:07:51.017828+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["Kiro", "Kiro Workflows", "Kiro Runtime"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/introduction-to-kiro-workflows", "markdown": "https://wpnews.pro/news/introduction-to-kiro-workflows.md", "text": "https://wpnews.pro/news/introduction-to-kiro-workflows.txt", "jsonld": "https://wpnews.pro/news/introduction-to-kiro-workflows.jsonld"}}