The intuition behind using multi-agents or sub-agents with Kiro is straightforward: more agents working in parallel means faster output. It is a reasonable assumption, and Kiro makes it easy to act on. As of version 0.8, Kiro supports synchronous sub-agents across the IDE, CLI, and ACP clients. Kiro agents can also invoke other agents, giving you access to two common multi-agent topologies that fit the majority of needs [1]. However, picking the right topology pattern is less about capability and more about understanding where each pattern breaks down. A 2026 research paper makes the failure mode precise, and the number is worth knowing before you split a task across multiple agents [2].
Two Patterns, Two Trade-offs
Kiro includes the Maker-Evaluator sub-agent topology by default, with Hub-and-Spoke easily accessible [1]. Both are well-suited to specific tasks, but neither is a general-purpose upgrade over a single agent.
Maker-Evaluator is a two-node loop: one agent produces output, a second evaluates it. When the same agent plays both roles, the pattern is called reflection. The main agent spawns a sub-agent and is blocked until the sub-agent completes. The main agent then decides whether to re-invoke based on the evaluation result.
This pattern fits iterative quality work: code review, coder-plus-tester automated turns, document generation with a writer-editor pair, and security auditing. Its token cost does not compound across iterations the way Hub-and-Spoke does across spokes, and failure recovery is simpler because the loop state is centralized.
Two failure modes are worth calling out before you wire up this pattern.
1. Runaway loop. Without a termination condition, the loop will not stop on its own. The best mitigation is a hard iteration cap of three turns.
2. Quality degradation. Quality gains flatten after roughly three turns, which Sartori’s research explains directly [2]. Using an adversarial evaluator with explicit, written rejection criteria and a defined standard rather than an implicit one will help maintain quality.
Hub-and-Spoke is a star topology where one central hub agent decomposes a task, delegates subtasks to up to four spoke agents, and aggregates their results. Spokes do not communicate with each other in this topology. The hub holds the full picture; spokes operate in isolation.
This pattern works well where tasks are genuinely independent: a planner agent decomposing requirements, a coder agent implementing them, a tester agent validating the output. It also suits orchestrator-plus-specialist setups where each spoke owns a distinct domain.
The costs for this topology are real and compound quickly. The hub is a single point of failure: if it loses context or produces a malformed delegation, the entire workflow stalls. Kiro credit costs also accumulate across every spoke independently and count toward your total usage in parallel. Those sub-agent spokes are not free. File writes are a concern when multiple spokes write to the same files, causing collisions.
Three mitigation strategies are worth building in from the start.
1. Accommodate parallel writes. Git Worktrees isolate parallel write paths so spokes do not overwrite each other’s changes, at the cost of disk space.
2. Optimize inter-agent communication. Terse hub-to-spoke messages, sometimes called caveman mode, can reduce token overhead.
3. Use persistent external memory. A “Document As You Go” pattern of structured session logs gives agents access to shared context that would otherwise be lost between invocations.
The Multi-Agent Coordination Gap
Think of two developers building the same feature in separate rooms with no way to talk to each other. Even with a perfect written spec, they will make small, incompatible decisions: one uses a list, the other uses a dictionary. Merging their work is harder than if one person had built the whole thing.
This is precisely what Sartori 2026 [2] set out to measure, and the results may surprise you. With a full specification, a single agent succeeded 89% of the time. Two agents working in parallel succeeded only 58%. With almost no specification at all, the single agent dropped to 56%, and the two-agent split dropped to 25%. The gap never closed, regardless of how detailed the spec was.
A better spec helps both approaches equally. It does not close the gap between them. The 25-to-39 percentage point penalty is structural: it comes from the agents not sharing decisions, not from the quality of the instructions.
This is why the Maker-Evaluator loop has a ceiling around three turns. Every additional iteration is two agents coordinating again, each time incurring that same overhead. More turns do not compound quality; they compound cost.
The Decision
Think of pattern selection as a per-task trade-off rather than a project-wide default.
Hub-and-Spoke is the right choice when tasks are genuinely independent, when parallelism matters more than accuracy on any individual task, and when the hub can synthesize partial outputs without needing agents to share state. If those conditions are not met, you absorb the coordination penalty without the parallelism benefit.
Maker-Evaluator is the right choice when iterative quality improvement is the goal, when the iteration count is bounded at three turns, and when the evaluator is independent of the implementor. An evaluator agent that shares context with the implementor absorbs the full coordination gap without providing independent verification.
A single agent remains the right choice when the task requires shared context across steps, when the codebase contains implicit invariants that agents cannot reliably infer, or when correctness is the primary constraint and the coordination penalty is unacceptable.
Three practical anchors apply regardless of which pattern you choose. Kiro allows custom agent definitions that specify model, tools, and context per sub-agent; use this to constrain scope rather than expand it. The intent document, or steering file, is the only persistent state between stateless agent sessions; without it, context resets on every invocation. For Maker-Evaluator specifically, write the termination condition before you wire the loop, because the model will not determine when enough is enough on its own.
Multi-agent is not a free upgrade. Hub-and-Spoke trades accuracy per task for parallelism. Maker-Evaluator trades compounding latency and a hard quality ceiling for iterative improvement. Sartori’s data makes the cost explicit: 25 to 39 percentage points of coordination overhead, present at every specification level, recoverable only by concentrating context in a single agent [2]. Knowing when not to split is the decision that makes the other two patterns worthwhile.
Ready? Build your first Kiro Agent in 15 Minutes
References
[1] J. Wasowski, After Analyzing 17 Multi-Agent Topologies - 7 Anti-Patterns That will Burn Your Budget, 2026 https://medium.com/gitconnected/after-analyzing-17-multi-agent-topologies-7-anti-patterns-that-will-burn-your-budget-28cc6909621c
[2] C. Sartori, The Specification Gap: Coordination Failure Under Partial Knowledge in Code Agents, 2026 https://doi.org/10.48550/arXiv.2603.24284
