Multi-Agent UI: One Conversation, Named Threads, Visible Work

The top-level conversation should be the manager

On a multi-agent screen, the first thing a user scans is not the agent count; it is the place where the request entered and the answer will return. They do not want a swarm; they want one accountable teammate. Make the top-level conversation the manager, each thread an addressable work unit, and the hidden work visible.

Anthropic shipped a redesigned Claude Code Projects beta on September 17, 2026, with a coordinator directing parallel agent threads. The pattern is useful even outside coding: it turns parallel work into a surface a person can inspect.

In that redesign, a user can run multiple agents inside one project, with common memory, objectives, and stored files or artifacts. The project should hold the decisions later threads need, not just a chat log of what happened after the work started.

Threads need names, boundaries, and a visible handoff

A thread needs a visible boundary. In Claude Code Projects, each thread runs as its own cloud session, with a separate branch and repository copy. A user who can see what a thread owns can judge whether the split is sane.

Names make steering possible. In the same setup, threads have names, which lets a user redirect a running thread before it finishes. A named thread invites correction; an unnamed process invites anxiety.

The coordinator is the part that makes the split feel intentional. The Claude Code Projects coordinator scopes a request, assigns work, manages parallel threads, checks outputs, and puts the final result together. If your product cannot show that chain, the user has to invent it.

Shared memory, conflicts, and cost are trust signals

In the September 17, 2026 redesign, all threads share a memory pool that can retain project decisions, with examples including a release moving to Friday, a dropped export, or the person to consult before changing billing. Those decisions are the kind of context a user expects a manager to remember.

When two Claude Code Projects threads modify the same code, the overlap is treated as a merge conflict similar to another pull request. A visible conflict lets users distinguish a normal engineering event from a silent overwrite.

In the beta, users can check project-specific usage and choose model and effort levels for the coordinator chat and worker threads, though running several full sessions can reach usage limits faster. Invisible cost and effort make users assume the worst and stop delegating.

Claude Code Projects threads currently run in the cloud, and support for running them on a user's machine with local tools and code is coming very soon. For many teams, that distinction changes security review, data handling, and budget planning before the first thread is launched.

An accountable multi-agent surface passes a one-minute audit

Use this list as a one-minute audit. Each item should be testable in your current UI without an engineer explaining the backend.

• One top-level conversation owns the request and final answer. The user sees one place where the manager receives the ask and returns the result.
• Each thread has a name and visible scope. The user can tell what it is doing and redirect it before it finishes.
• The coordinator shows scoping, delegation, review, and assembly. The handoff from request to output should be inspectable, not implied.
• Shared memory carries decisions, not just chat history. Stored context includes choices, dropped work, and people to consult.
• Concurrent edits appear as merge conflicts, not silent overwrites. Overlap surfaces as a normal review event.
• Model and effort selection is visible per layer. The coordinator and each worker thread expose the model and effort used.
• Project usage is visible before limits are hit. The user sees project consumption, not only a failure message.
• Cloud/local execution and cost limits are explicit. The surface says where work runs and what the user can spend.