I’ve been running parallel Claude Code agents as part of my daily engineering workflow at HOAi. Instead of one agent doing everything sequentially, I split work across agents that each handle a different slice.
I want to share some of the lessons I’ve learned. They apply whether you use the CLI, Conductor, Orca, or any other tool that supports multiple agent sessions.
Design the work, then hand it off
With parallel agents, your job changes from writing code to designing work.
When I work on an ambiguous problem, I don’t know what I want to build yet. Before I start coding, I work through the following steps:
- Design what I’m building. I use the agent as a thinking partner. It asks me socratic questions, challenges my premises, and forces me to pick an approach.
- Challenge the scope. Am I thinking big enough? Should I cut to the essentials?
- Lock in the architecture. Nail down data flow, edge cases, and file-level details.
- Implement with parallel agents. With a clear spec in hand, I break the work into parallel tasks, each with a focused slice.
I use gstack skills for the first three steps: /office-hours for design, /plan-ceo-review for scope, /plan-eng-review for architecture. I also use the superpowers brainstorming skill.
One job per agent
Once you’ve designed the work, break it into slices. Each agent should own one slice. Ideally, you should be able to describe each agent’s job in one sentence. When agents work on independent problems, no coordination is needed. For example, agent A works on the settings page in project 1 while agent B works on the notification service in project 2.
If you need complex coordination rules between agents, that often means the decomposition is wrong. Redraw the boundaries so each agent owns a distinct piece.
Isolate agent environments
When multiple coding agents work on the same code, isolate their working directories using git worktree. This way, each agent works on its own copy of the code.
Sometimes isolating files isn’t enough. Agents also need isolated runtimes. In this case, you can run each worktree inside its own Docker container, local cluster, or remote dev machine so each agent gets its own backend, its own database, and no port collisions.
You can also run multiple Claude Code sessions inside a single worktree. They share the filesystem and see each other’s changes in real time. This is harder to get right because the agents can step on each other, so parallel worktrees are usually the better default.
When I do run multiple agents in one worktree, I keep the coordination simple: plan first, then let a main agent launch subagents on isolated pieces of the work. Claude Code makes this very easy with workflows.
Track progress on disk
If you are working on a complex problem, it could take the agent hundreds of turns to solve it. To prevent the agent from losing track of what it was doing, use loop tools like /goal and /ralph-loop.
These tools give agents a progress file and periodically prompt the agent to check its progress, update status, and continue. The progress file survives context compaction because it lives on disk. When compaction happens, the agent re-reads the progress file and picks up where it left off.
Let tools manage notifications
After delegating work to an agent, work on something else. Don’t wait for it to finish. Use a tool that notifies you when an agent finishes or needs input. For example, Conductor and Orca.
Conductor is a Mac app that gives you a clean dashboard where you can see what every agent is doing and review diffs inline. It handles worktree creation, setup scripts, and PR flow for you.
Orca is open source and works across macOS, Windows, and Linux. What I like about Orca is how it organizes information. Split panes let me watch multiple agents at once, the file browser makes it easy to see what each agent is touching, and workspaces keep everything grouped so I’m not drowning in tabs. Orca also has a CLI that lets you start workspaces programmatically, which means an agent can spin up new workspaces on its own.
If you prefer staying in the terminal, cmux (an agent-friendly terminal multiplexer) handles notifications across multiple sessions.
Persist context in the codebase
When a session ends, a lot of context gets lost, including the reasoning behind code changes. It is helpful to store it as part of the diff.
For example, you can commit decision logs to docs/decision-logs/. When I make a non-obvious choice (why this approach over that one, what tradeoffs I accepted), I write it down. Future agents and future me will need it when maintaining or extending the work.
You can also commit plans to docs/plans/. If I designed the work with /office-hours or /plan-eng-review, I commit the output. Plans become part of the codebase’s institutional memory. When a new agent picks up related work months later, it can read the plan instead of reverse-engineering intent from the code.
Getting started
If you’re new to parallel agents, start with two worktrees on independent tasks. Get comfortable with the flow. Running agents is the easy part. Breaking work into pieces that agents can own independently takes practice. If you get that right, the productivity gain follows naturally.