DEV Community

yehe-ai
yehe-ai

Posted on

Amp Spaces: One Agent to Coordinate Them All — What Changes When You Stop Managing Threads

On November 6, Amp launched spaces — a new way to work with coding agents that flips the usual multi-agent workflow on its head. Instead of you creating and organizing threads, a space is a conversation with a single agent whose job is to spawn and coordinate agents for you.

That sounds like a small interface change. It isn't. It moves the human out of thread management entirely.

From threads to a captain's chair

If you've used a coding agent for anything bigger than a one-off fix, you know the pattern: one thread per task, tabs multiplying, and you acting as the dispatcher — deciding what gets its own thread, what's done, what needs a follow-up. The agent does the work; you do the coordination.

Amp's answer is to put one agent in charge of that coordination. You talk to the space agent. It breaks the work down, spawns threads, and reports back. Amp's own description of the feeling is telling: you operate with a bird's-eye view but can still dive into the weeds when necessary. "It's more like sitting in the captain's chair than down in the trenches."

To start one, you hit the + in the Spaces section of the sidebar, set a title and a project, and tell your agent what to work on. The space agent takes it from there.

How Amp is actually using it

The announcement is more convincing than most launch posts because Amp has been dogfooding spaces for weeks, and it gives three concrete examples.

Spaces were built in a space. Tim, Lewis, Nicolay and the rest of the team shared a space called "Spaces v1", dropped feedback, bugs, and new ideas into the chat, and the agent delegated each item into threads. When the team needed to talk, they used comments to chat and tagged in Amp when they were ready. The product shipped out of its own workflow.

A feature launch, run from one space. Lewis ran the launch of service accounts from a single space. From there, he could roll out the feature, monitor X, Slack, and bug reports for issues, fix incoming bugs, and send out emails and refunds to affected users. The space kept monitoring user issues and system health for the rest of the week. That's not a coding task — it's an operations shift, coordinated by one conversation.

Recurring security reviews. Will gave a space a standing goal: review recent changes for security issues. Its first run split the codebase into 16 areas, reviewed each in its own thread, cross-checked every finding in another thread, and kept a summary artifact in the space for Will to review and track. The supervised first run filed 14 issues.

One detail worth noting: the team says they naturally moved communication into the space instead of Slack — taking video calls and discussions there. The space became the room where the work happened, not just a log of it.

Why this pattern matters

Multi-agent systems keep running into the same wall: spawning agents is easy, coordinating them is the actual work. Every framework has its own answer — orchestrators, handoffs, shared memory, message buses — but most of them still make the human the orchestrator, or bury the orchestration in config the human has to maintain.

Spaces takes the opposite bet: the coordinator is just another agent, and you talk to it in natural language. The coordination logic lives in the conversation, not in a YAML file. That has real advantages:

  • Delegation stays conversational. You describe outcomes and the space agent figures out the thread topology. You don't maintain a task graph.
  • Context stays in one place. The space holds the running conversation, the threads, and the summary artifacts, so a teammate can join mid-flight and catch up by reading the space.
  • Long-running work gets a home. A launch or a weekly security review isn't a thread that scrolls away — it's a persistent space with a standing goal.

The honest caveats

This is a launch announcement, not a benchmark. A few things to watch before treating spaces as the new default:

  • The coordinator is a single point of failure. If the space agent misunderstands the goal or misjudges which thread owns what, the error propagates to every thread it spawns. The security review example worked because the first run was supervised — that supervision step is doing real work.
  • No independent evidence yet. Everything we know about spaces comes from Amp's own team, on Amp's own codebase. The pattern may generalize well to other teams and codebases, or it may be tuned to how Amp's engineers already work.
  • Coordination has a cost. Every thread the space agent spawns is more model calls and more context. For a small, well-defined task, a single thread is still cheaper and simpler. Spaces make sense when the work is genuinely parallel or long-lived.

Where to start

If you use Amp, the lowest-risk way to try this is to copy the security review pattern: pick a bounded, repeatable goal with a clear artifact at the end — a review, an audit, a migration checklist — and give the space a standing goal with a supervised first run. You get the coordination benefit with a human checkpoint built in, and the summary artifact tells you quickly whether the coordinator is earning its keep.

The bigger question spaces raises is about where the human sits in agent workflows. For two years the answer has been "in the loop, managing threads." Amp is betting the answer becomes "in the chair, managing goals." If the coordinator agent is reliable enough, that's a better job for everyone — including the agents.

Source: Amp, Spaces, published November 6, 2026.

Top comments (0)