A common way to run AI agents in parallel is to put a supervisor in the middle. It decomposes the work, delegates pieces to subagents, and gathers their results. That structure is easy to understand and verify, but every assignment and result also passes through the same context and queue.

kiro-flock is an AWS reference implementation that moves coordination from a central agent into shared state in Amazon S3. Kiro CLI agents running on Amazon EC2 do not connect directly to one another; they decide what to do next by reading shared logs.

Does removing the supervisor automatically make a multi-agent system easier to scale? The mechanism points to a more useful answer: the right architecture depends on how independently the work can proceed and where verification must happen.

Moving coordination into S3 removes the supervisor’s central queue

The shared environment in kiro-flock contains a direction file describing the common goal, an append-only log for each agent, and a work area for artifacts. No central process plans, assigns, or aggregates for the others. Each agent chooses one contribution from the common direction and the activity it can see nearby.

Every iteration starts a fresh Kiro CLI session. The agent reads the direction and a bounded set of peer logs, writes an artifact, and appends a record describing what it did, the result, and its next intent. Another agent reads that record in a later iteration and independently decides whether to follow it, challenge it, explore elsewhere, or become idle.

S3 is a practical shared store here because Amazon S3 provides strong read-after-write consistency for object PUT and DELETE operations in all AWS Regions. That property does not make the agents agree or make their artifacts correct. The design avoids competing writes by giving each agent its own log, then leaves convergence to the readers.

If one agent stops, only that agent’s loop stops. The tradeoff is equally direct: there is no central verifier arbitrating every intermediate result. This is more than a conventional scale-out change.

Self-organization fits work that can produce many independent contributions

A self-organizing cluster is a good match when many quasi-independent contributions can move one goal forward. Large codebase reviews, migrations of many modules toward a known target, parallel test generation, and design exploration value breadth and concurrency more than strict ordering.

A supervisor remains a better fit for strongly sequential procedures, changes that need approval at each handoff, and latency-sensitive interaction. Google Research’s comparison of agent architectures reported gains from coordination on parallelizable financial reasoning, but lower performance for every multi-agent variant on sequential planning. It also found substantially greater error amplification in an independent architecture without centralized checking.

Ring, mesh, and swarm change whose logs each agent reads

Showing every agent the same information can turn the first plausible idea into premature consensus. To control visibility, kiro-flock implements three algorithms that can be changed while a run is active, as described in the official repository.

• Amorphous (ring): Each agent reads 2R fixed neighbors, with R agents on either side. Per-agent context can stay constant as the total population N grows, while slower propagation gives alternative ideas time to develop.
• Mesh (full visibility): Every agent reads the latest record from every other agent. Agreement is faster, but context grows with N and early signals can collapse diversity.
• Swarm (recency): Each agent reads the K most recently active peers. Work can gather around current activity, but a K that is too small for N can pull too many agents into the same hotspot.

In a ring, the model for propagating one signal across the cluster is ceil(N / 2R) iterations. With N=100 and R=2, that is 25 iterations; at the sample’s default 30-second interval, propagation alone is about 12.5 minutes. It is a planning estimate, not a guarantee of completion time or quality.

A run can begin in a ring to broaden exploration, switch to swarm when a direction forms, and finish in mesh when alignment matters more than diversity. Topology is therefore an allocation of diversity, context size, and convergence speed—not just a diagram.

Fresh sessions keep old assumptions out of durable shared state

Starting a new session for every iteration may look wasteful. Keeping the conversation history, however, lets an agent carry its first interpretation forward after its neighbors have moved on. kiro-flock treats this drift as a control problem: durable state lives in the shared logs and artifacts, and every new session reconstructs the current situation from them.

That does not remove failure modes. Switching to mesh too early can cause groupthink; a small K in swarm can create hotspots; and failing to archive a previous run can make stale artifacts look current. Shared-state coordination requires explicit control of visibility and run-level data boundaries, not just session memory.

Removing centralized verification also means the final artifact needs a separate gate. A code migration can end with a complete test run; a set of designs can end with human or independent review. Self-organization changes where verification happens. It does not make verification optional.

Set permissions, stop conditions, and cost limits before trying kiro-flock

As of August 12, 2026, the official kiro-flock README requires an AWS account with CDK bootstrapped, Node.js 20 or later, Python 3, AWS CLI v2, Kiro CLI, and an eligible Kiro subscription. The setup begins by copying the configuration template, selecting a Region and profile, and running the script.

cp install.config.template install.config
# Set REGION and PROFILE in install.config
./setup.sh

The setup deploys S3, EC2, AWS Lambda, Amazon API Gateway, Amazon Cognito, and related resources, and stores the Kiro API key in AWS Systems Manager Parameter Store. Kiro CLI headless mode runs without a person available to approve tool calls, so permissions must be granted in advance. Its documentation recommends allowing only the needed tool categories with --trust-tools instead of broadly trusting every tool.

This is an educational reference sample, not a production system. The README explicitly assumes one operator experimenting in a dedicated AWS account. Its production-hardening list includes narrower per-cluster S3 permissions, restricted agent egress, stronger authentication, monitoring, input validation, and data classification. Those controls need to be designed before moving the sample into a shared or production environment.

Removing an always-on orchestrator or message broker does not remove cost. The cost surface includes Kiro usage, one or more EC2 instances for agents, S3 storage and requests, Lambda and API Gateway for the control plane, and Amazon Bedrock for post-run analysis. A first experiment should use an isolated environment and define AWS Budgets alerts, a maximum iteration count, idle shutdown behavior, and cleanup steps before the cluster starts.

A self-organizing cluster is a different coordination model, not a universal supervisor replacement

kiro-flock shows that strengthening a central supervisor is not the only way to coordinate more agents. For many quasi-independent contributions where diversity matters, shared state and local visibility can remove a central queue and a single process failure from the execution path.

For work dominated by ordering, intermediate approval, or strict correctness, centralized verification is both a bottleneck and a safety mechanism. In practice, the decision comes down to three steps: determine whether the work truly decomposes, choose topology to control visibility, and place an explicit final gate outside the cluster. That turns self-organization from an experiment in adding agents into an architecture choice.

Source

• Title: Scaling patterns for self-organizing multi-agent clusters with Kiro
• URL: https://aws.amazon.com/blogs/architecture/scaling-patterns-for-self-organizing-multi-agent-clusters-with-kiro/