Every multi-agent architecture eventually runs into the same design question: who’s in charge? Most teams answer it by building a central orchestrator, a service that assigns tasks, tracks state, and tells agents what to do next. It works fine in a demo. It works fine with ten agents. Then you scale to a few hundred, the orchestrator becomes the busiest, most fragile component in the system, and you’re debugging a bottleneck you built on purpose.
AWS has a reference architecture floating around called kiro-flock that takes a different approach. Instead of a central controller, agents coordinate through shared state in Amazon S3. No orchestrator process, no queue manager deciding who does what. Agents write their status as objects, read what other agents have written, and self-organize based on what they see in the bucket.
I’ve spent enough time building and running orchestration layers to be skeptical of anything that claims to remove the need for one. But the more I look at this pattern, the more I think the skepticism should be pointed at the orchestrator, not the alternative.
The Orchestrator Bottleneck#
A central orchestrator is a single point of failure by definition. If it goes down, every agent that depends on it stalls, even if the agents themselves are healthy. It’s also a scaling bottleneck. Every agent has to talk to it, which means connection limits, request queues, and lock contention all grow with fleet size. You end up spending more engineering effort scaling the thing that coordinates the work than the thing that actually does the work.
The instinct is to make the orchestrator highly available: add replicas, add a leader election protocol, add a database behind it. At that point you’ve built a distributed system to manage your distributed system. The complexity didn’t go away. It just moved up a layer.
What kiro-flock Actually Does#
The kiro-flock pattern treats S3 as the shared source of truth. Agents running on EC2 (or wherever) write small state objects describing what they’re doing, what they’ve claimed, and what they’ve completed. Other agents list and read those objects to decide their next move. There’s no central brain deciding who gets which task. The agents look at the bucket, apply a shared set of rules, and act.
This works because S3 gives you a few things for free that you’d otherwise have to build yourself: durability, virtually unlimited concurrent readers, and a flat namespace that scales without you thinking about it. You don’t provision capacity for “more agents reading state.” S3 just handles it.
Task claiming uses conditional writes (If-None-Match on object creation, for example) as a lightweight compare-and-swap. An agent tries to create a “claim” object for a task. If it succeeds, it owns the task. If it fails because the object already exists, another agent got there first. That’s a real coordination primitive, not just agents politely agreeing not to step on each other.
Trading Consistency For Resilience#
Here’s the tradeoff, and it’s a real one: S3 is eventually consistent for list operations in ways that matter here. A newly written object is strongly consistent for reads once written, but a ListObjects call right after a burst of writes isn’t guaranteed to reflect every object immediately in all conditions, and propagation across a large number of concurrent writers isn’t instantaneous. If your coordination logic assumes every agent sees the exact same bucket state at the exact same moment, you’re going to get duplicate task claims, orphaned work, and agents racing each other on stale reads.
A central orchestrator gives you strong guarantees about ordering and state because it’s one process holding one view of the world. Shared state through S3 gives up that guarantee in exchange for something else: no single point of failure, and horizontal scalability that doesn’t require you to scale a controller. As your agent fleet grows from dozens to thousands, that tradeoff starts looking a lot more attractive. Coordination guarantees matter less than staying up.
Debugging When Nothing Is a Single Truth#
This is the part people underestimate. With a central orchestrator, when something goes wrong, you look at one log stream and one state store. With S3 as your coordination layer, “what happened” is scattered across however many objects your agents wrote, and the order you read them in during a postmortem might not be the order they were actually written in from every agent’s perspective.
You need object versioning turned on, timestamps embedded in every state object (not just relying on S3 metadata), and ideally an event log shipped somewhere queryable, because reconstructing a timeline from bucket listings after the fact is painful. Eventual consistency doesn’t just change how the system behaves. It changes what your incident response looks like.
Where This Pattern Actually Fits#
Use S3-as-coordination when your agent fleet is large, your tasks are independent enough that a claim-based model works, and you can tolerate occasional duplicate work or brief coordination lag. Don’t use it when task ordering has to be strict, when agents need to negotiate in real time, or when you can’t afford even a few seconds of staleness in what agents believe about each other’s state.
A central orchestrator isn’t wrong. It’s just the wrong default for fleets that outgrow it. Before you build one, ask what you actually need: strict ordering and a single source of truth, or resilience and horizontal scale. You can’t cleanly get both, and pretending otherwise is how orchestrators become the thing you spend all your time firefighting.
Recommended Reading#
- Designing Multi-Agent Systems: Principles, Patterns and Implementation by Victor Dibia
- AI Agents in Action by Micheal Lanham
- AWS Certified Solutions Architect Study Guide: Associate SAA-C03 Exam, 4th Edition by Ben Piper & David Clinton
Featured image by Christian Lue on Unsplash