Build1 publisher2 min readPublished
Kiro Workflows give each agent step its own session so reviewers judge code without the writer's reasoning
Kiro Workflows define multi-agent coding runs as JSON or YAML graphs of five node types that the Kiro Runtime executes in the background. The runtime enforces loops and joins, but inputs reach agents as untyped text, so a deploy flag is only as safe as a model's reading of it.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The watch node polls an outside system, such as a GitHub pull request or a custom command handler, without invoking a model.
- Parallel branches run concurrently and rejoin under one of three join policies: all, allSettled or any.
- A repeat node loops until a stop condition such as an approval verdict is met or maxIterations runs out, then aborts, continues or pauses as configured.
- Progress from the background run flows back to the user's main chat, where they can answer an occasional question or steer the work mid-run.
- Launched through workflowPath, every input value is a string, so a deploy flag arrives as the text "false" and never as a JSON boolean.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A deploy gate in a workflow is an instruction to the agent, so whether a credentialed deploy runs depends on a model reading a string correctly, with no runtime check behind it.
- capability Teams get a reviewer whose only view of the change is the published output, so its verdict is not anchored on the writer's own justification for the code.
- cost Waiting on CI or a pull request review can sit in a watch node, so idle stretches of a long run do not spend model calls.
- decision Every review loop needs an explicit choice at the iteration cap, and setting continue lets a run proceed without the approval verdict the loop was built to obtain.
Session isolation is only useful if the handoff between steps is narrow. In Kiro the handoff is a declared output. Each step passes its results forward through output references [4], and the schema lets a step declare artifacts, such as an agent report written to a file [16]. A reviewer step sees what the writer produced, without the reasoning the writer used to get there [3]. A single chat cannot give that separation. The walkthrough describes chat as the user guiding the model through each phase and reminding it, over and over, of earlier decisions [17].
The account comes from a community walkthrough on dev.to, built on the author's own project and the recipes bundled with Kiro [18]. The specifics below are one user's description of runtime behaviour.
Four of the five node types never invoke a model [1]. Ordering, concurrency, joins and iteration caps belong to the runtime [7][9][10]. I think that split is right. The parts of a multi-agent run that must behave predictably stay with the runtime. The iteration cap is where a team has to make a real choice. For a review loop I would set onMaxIterations to pause [10]. Abort ends a run that may be one fix from approval, and continue moves past the approval verdict the loop existed to get.
Data is where enforcement stops. Inputs are template variables, and the value beside each key is a human-readable hint, not an enforced type [11]. The runtime does no enum validation, no required or optional check, and no number parsing [13]. At launch it substitutes the passed strings into prompts wherever a placeholder such as {{run_deploy}} appears [11].
The example project shows what that means for a deploy. Its inputs include an AWS SSO profile for credentialed phases and a run_deploy flag described as whether to run `just deploy`, default false [15]. The deploy step's prompt tells the agent not to deploy unless the value is `true`, and the agent decides what the string means [14]. A boolean that a model has to interpret is a firm suggestion with a type hint attached. Until the runtime can check a flag itself, I would keep credentialed steps out of agent sessions. In the example, what stands between an agent and `just deploy` is its reading of the string "false" [12][14].
What to watch
- Whether Kiro's own reference documentation confirms string-only inputs or adds typed, validated inputs that the runtime checks before a step runs.
- Whether the watch node's custom command handler can act as a deterministic gate in front of credentialed steps such as a deploy.
- Whether output references can be scoped per step, controlling exactly which artifacts a reviewer agent is allowed to read.