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.
The 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.
In 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.
A Workflow schema looks similar to this:
{
"name": "",
"description": "",
"inputs": {
},
"steps": [
{
"type": "",
"id": "",
"steps": [
{
"type": "step",
"id": "",
"agent": "",
"prompt": "",
"artifacts:" {
}
},
]
}
]
}
There are five node types in a Kiro workflow:
all, allSettled, or any). maxIterations is reached), with an onMaxIterations behavior of abort, continue, or ``. github-pr) or a custom command handler.
A 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.
In a Kiro workflow, inputs are template variables, not a typed schema.
For 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:
"inputs": { "profile": "AWS SSO profile for credentialed phases (default: Walsen)", "run_deploy": "whether to run `just deploy` (default: false)"}
That "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.
So the practical picture is:
"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.
Common conventions for what inputs represent (not enforced types, just how they're typically used):
goal, prompt, research_directions). design_path, prd_path, report_path, workdir, spec_dir, worktree_path). branch, worktree_branch, mainline_branch). profile, max_iterations).
Two caveats so this isn't misleading:
Step 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.
For 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.
So, 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.
The 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:
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.
There's also wf-workflow-creator, the agent that designs/saves workflow definitions, but you normally wouldn't put it in a step.
For one of my talks, I built a small project: an online Sudoku deployed on AWS Amplify with Lambda and DynamoDB as the backend.
For this project I wanted 2 things:
For anyone who wants to see the project, it's available here.
Here are the workflows in action: https://youtu.be/zqEOtFmRC_I
For English speakers, the video is in Spanish but you can activate the titles in English.
Just 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 ....".
I'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.
It's a feature with huge potential: it lets you run flows in many ways, include them in automation, generate them dynamically, and much more.
I 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.
Workflows (overview) — The concept: graphs of agent steps, sequences, loops, and parallel branches; each step in its own fresh session.
Author workflows — 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.
Workflow examples — The shapes of the bundled recipes (and a note that the set of bundled recipes may vary between client versions).
Run and manage workflows — Background execution, checkpointing, node state/outputs/artifacts, loop (repeat) progress, watch cursors, /resume.
Supporting references:
Start at 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).