Every agent framework I've used in the last two years has the same hidden assumption baked in: you're sitting at a terminal, watching the agent work, ready to intervene. That's fine for demos. It's a bottleneck in production. AWS just open-sourced Kiro Crew, a system for running multiple coding agents asynchronously across sessions, tools, and tasks, and I think the architectural choice matters more than the feature list suggests.
This isn't a Kiro ad. I've been building multi-agent systems with my own AgentReview project in C#/.NET and MCP, so I've got opinions on where the hard problems live.
The Real Problem with Synchronous Agent Workflows
When you run a coding agent synchronously, you're modeling it after a pair-programming session. One task, one context window, one human waiting for output. That works fine when the task is small and the feedback loop is tight. It breaks down the moment you have ten open tickets, three ongoing migrations, and a PR queue that doesn't sleep.
The pattern I kept running into with AgentReview was that agent fan-out is easy. Spinning up multiple agents to review different files in parallel is a few lines of orchestration code. What's hard is task lifecycle management: knowing when an agent is blocked, when it's done, when its output is stale because the underlying code changed, and how to resume a session that got interrupted. Synchronous frameworks punt all of that to the user. You're the scheduler.
Kiro Crew's bet is that the scheduler should be the system. Making agents asynchronous by default shifts the mental model from "run this agent and wait" to "assign this task and check back." That shift is the difference between a script and a service.
What Asynchronous Buys You (and What It Costs)
The use cases AWS highlights (incident investigation, ticket triage, migrations, PR monitoring) share a common property: they can make meaningful progress in the background without a human in the loop at every step. An agent triaging a batch of GitHub issues doesn't need you watching. An agent running a migration script against a staging schema doesn't need you present. The output can wait in a queue until you're ready to review it.
The gain is throughput. Instead of one agent doing one thing while you wait, you get a pool of agents working through a backlog while you do other work. I'd have loved this during some of the bulk data operations I've built, things like the admin tool I wrote that ultimately cut our monthly support tickets by 90%. A lot of that work was manual triage and transformation that could have been agent-assigned with the right scaffolding.
But the cost is real: async agents need durable state. If an agent is mid-task when the process restarts, you need to resume it, not restart from scratch. That means persistent task queues, checkpointing, and idempotent tool calls. None of that is unsolved, and none of it is free. If you've ever built a reliable background job system in any language, you know that "run this asynchronously" is 10% of the work and "handle every failure mode" is the other 90%.
On the .NET side, I'd reach for something like Hangfire or Azure Service Bus for the queue layer, with explicit state checkpoints written to SQL Server or Cosmos DB at task boundaries. The agent logic itself stays stateless, and the persistence layer carries the context. That's the same pattern Kiro Crew describes, just implemented at a different level of the stack.
Multi-Agent Task Assignment: The Coordination Tax
Kiro Crew lets you assign different tasks to different agents, which sounds straightforward until you ask: what happens when two agents need to touch the same file? Or when one agent's output is another agent's input, but the first one isn't done yet?
This is the coordination tax, and it's where most multi-agent frameworks quietly break down. In AgentReview, I handled it with strict lane discipline: each agent owns a defined scope and writes to a dedicated output channel. Synthesis happens in a separate step, after all agents have completed. It's a simple rule, but it eliminates an entire class of race conditions.
I did some research on how Kiro Crew handles this, and the documentation is honest that workspace-level coordination is still an open problem. That's the right answer. You either serialize access, which kills your parallelism gains, or you design tasks so their scopes don't overlap, which requires upfront work from whoever is assigning tasks. Kiro Crew gives you the infrastructure; the task decomposition is still on you.
I don't hold that against them. Any framework that claims to solve task decomposition automatically is overselling. The right move is to document the constraint clearly and let engineers design their workflows accordingly.
The Bet Behind the Features
What interests me about Kiro Crew is the architectural stance more than any specific feature. AWS is betting that async-first, multi-agent task execution is where serious coding workflows are headed, and I think that bet is right. Synchronous, single-agent sessions are going to feel like blocking I/O once teams start building at scale.
If you're deciding whether to adopt something like Kiro Crew or build your own scaffolding, here's how I'd think about it. If your team assigns more than five distinct coding tasks per day that could plausibly run in parallel, the async model pays off fast. If your tasks have clean scope boundaries (one agent per service, one agent per ticket), you'll avoid the hardest coordination problems. And if you need durability across restarts, invest in the persistence layer before you invest in the agent logic. The agents are the easy part.
I'm planning to run some benchmarks on my DGX Spark with a similar async agent pool pattern (multiple model instances running in parallel against a backlog of tasks) to see how throughput scales with unified memory versus swapping. I'll write that up when I have numbers worth sharing. For now, pull Kiro Crew down and read the source even if you never deploy it. The design decisions in an open-source agent framework are some of the best documentation we have for what works in this space.