Introduction to Kiro Workflows 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. 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": { Values that are going to be interpolated when referenced. }, "steps": { "type": "", "id": "", "steps": { "type": "step", "id": "", "agent": "", "prompt": "", "artifacts:" { Agent report as a file } }, } } There are five node types in a Kiro workflow: all , allSettled , or any . maxIterations is reached , with an onMaxIterations behavior of abort , continue , or pause . 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.