Multi-agent workflows: parallel runners vs profile-switching

“How do I run multiple AI coding agents?” turns out to mean two different things.

Pattern A — parallel. Five agents at once. One on each git worktree. You’re working on five things simultaneously and want to come back to a stack of pull requests. This is what Claude Squad, Conductor, and Tide Commander are good at.

Pattern B — serial. One agent at a time, but a long-lived context per project. You’re working on one thing, but it’s the same one thing tomorrow morning, and you’d like the agent to remember what it learned yesterday. This is what Ringlet’s profiles are good at.

Both are useful. Most teams need both. This article is about which one to reach for when, and how they compose.

What parallel runners do well

Parallel runners assume that each task is independent and roughly sized to “one PR.” A new feature, a refactor, a bug fix. You start the runner, hand each agent a different task, walk away, come back to diffs you review and merge.

The mechanic is git worktrees. Each agent gets its own copy of the repo at a fresh branch. They can’t conflict because they’re on different filesystem paths. The orchestrator monitors them, surfaces output, and shows you the diffs.

This works really well when:

You’re a senior developer with a backlog of small, well-specified tasks.
You’re willing to review each diff carefully before merging.
You’re paying for the tokens it takes to run five agents at once.

It works less well when:

The task is exploratory (“what’s actually going on here?”). One agent thinking carefully beats five agents flailing.
You need long-running context. Each worktree restart is a context restart.
Tasks aren’t independent. If they all touch the same file, the merge is its own problem.

What profile-switching does well

Ringlet’s model is different. Each profile is a long-lived bundle: agent + provider + history + workspace. The agent is the same agent you’d use without Ringlet; the profile just means it remembers what it was doing last time.

The mechanic is HOME isolation. Each profile has its own ~/.claude (or ~/.codex) so the agent’s conversation history, project memory, MCP setup, and trust grants survive across sessions and don’t leak between profiles.

This works really well when:

You work on a small number of projects, intensely, for days or weeks at a time.
You want the agent to remember what you discussed yesterday and pick up where you left off.
You care about cost across projects and need to attribute spend correctly.
You want different providers (or different accounts at the same provider) for different work.

It works less well when:

The task is “do these five things in parallel.” That’s not what serial profiles are for.
You don’t care about long-term memory and just want each task to be fresh.

A worked example

You’re an engineer working on three things this week:

Refactor the auth layer in client-acme/api. A several-day project. You’ll come back to it across many sessions. The agent should remember what you’ve already tried.
Triage 20 small bug reports across two repos. Each takes 5–30 minutes. They’re independent.
Experiment with a side project at home. Personal account, different provider.

The right tool layout:

A Ringlet profile for the auth refactor. Long-lived. Anthropic-backed (you want Sonnet for this). Lives in ~/Projects/client-acme/api.
Claude Squad inside a Ringlet profile for the bug triage. The profile binds Claude Squad’s environment to the same client-acme account; Claude Squad spawns five agents on five worktrees and you review them as they finish.
A separate Ringlet profile for the side project. Personal account, MiniMax provider (cheap, you’re paying out of pocket).

ringlet profiles create claude acme-auth        --provider anthropic --key-alias acme
ringlet profiles create claude acme-bugs        --provider anthropic --key-alias acme
ringlet profiles create claude personal-toy     --provider minimax   --key-alias personal

# Long-running refactor: a regular Ringlet session
ringlet profiles run acme-auth

# Bug triage: Claude Squad inside the bugs profile
ringlet profiles run acme-bugs -- claude-squad

# Side project: minimax-backed
ringlet profiles run personal-toy

Three profiles, two patterns, one mental model. Costs land on the right accounts; histories stay separate; the parallel runner does its job inside one profile without polluting the others.

Why this is the right composition

The orchestration layer (Ringlet) and the parallel-runner layer (Claude Squad / Conductor) sit at different heights in the stack. Ringlet owns the agent’s environment — credentials, history, workspace. The parallel runner owns which tasks are running on which worktrees right now.

You wouldn’t ask npm to manage your test runner’s task parallelism, and you wouldn’t ask your test runner to manage your dependency tree. Same logic here.

Concretely, what each layer does:

Layer	Responsibility
Ringlet	HOME isolation, credentials, provider binding, cost tracking, hooks
Claude Squad / Conductor	Git worktree allocation, task queue, parallel monitoring
The agent (Claude Code, Codex, …)	The actual code generation, tool use, agent loop

When you compose them — a parallel runner inside a Ringlet profile — each layer does its job. The runner gets the agent’s environment from Ringlet; Ringlet doesn’t have to know about parallelism; the agent doesn’t have to know about either.

What about the times you don’t need a runner?

Most of the time, honestly. The “five worktrees, five tasks” pattern is real, but it’s not most engineers’ default day. Most days are: open a project, ask the agent for help, iterate, commit, move on.

For that, profiles are enough. The agent is one agent. The runner is just you.

The shape we see in practice: engineers create 3–5 long-lived profiles (work, personal, one or two clients), use them serially most of the time, and reach for a parallel runner once a week or so when the task fits.

The honest answer on Ringlet + Claude Squad together

Claude Squad is excellent at what it does. We use it. Running it inside a Ringlet profile is the right setup if you need both — the profile gives Squad the right credentials and provider, Squad does the parallel orchestration on top.

We’d recommend installing both:

# Ringlet for credentials, providers, cost, history
curl -fsSL https://raw.githubusercontent.com/neul-labs/ringlet/main/install.sh | sh

# Claude Squad for parallel task running
brew install smtg-ai/tap/claude-squad

Inside a Ringlet shell:

ringlet profiles run work
# Now in the work profile's env:
claude-squad init
claude-squad task add "Refactor src/auth to use OAuth"
claude-squad task add "Fix the JSON parse bug in src/parse"
claude-squad task add "Add e2e test for /signup"
claude-squad run

Three Claude Code instances spin up. Each is on a separate git worktree. Each inherits the work profile’s Anthropic key. Cost lands on the work account. Diffs land in three branches. Review, merge, move on.

That’s the multi-agent workflow we recommend in 2026: profiles for the long-running stuff, a parallel runner inside a profile when the task fits.