Running three agents at once: how senior engineers work now

The most productive senior engineers we work with no longer do one thing at a time. They run multiple coding agents in parallel: two or three delegated workstreams advancing in the background while they hold the design and review work only they can do. It is a genuinely different way of working, closer to running a small team than to programming, and it is where the large productivity claims of the agent era stop being marketing and start being observable.

It is also easy to do badly. Parallelism multiplies whatever process you already have, including the flaws. This note covers the working setup, what it demands, and where it falls apart.

The mechanics: worktrees and isolation

The setup is unglamorous. Each agent gets its own git worktree: a separate checkout of the repository on its own branch, so three agents never share a working directory or trample each other’s files. One terminal tab or session per stream. The agent tools themselves matter less than the isolation discipline, and every serious one supports this shape now.

Task isolation matters as much as filesystem isolation. Parallel streams should touch different modules, or at minimum different files. Two agents editing the same service is not parallelism, it is a merge conflict with extra steps. The operator’s first skill is picking three tasks that genuinely do not intersect.

What running parallel agents demands

Clean task definition is the entry fee. A task you could hand a competent contractor with no follow-up questions, scope, acceptance criteria, pointers to relevant code, is a task an agent can carry end to end. Vague tickets produce agents that stall or, worse, guess. This is the same discipline as writing tickets agents can execute, applied three at a time.

Fast verification is the second requirement, and the one teams underestimate. With three streams landing, you are the merge point, and everything waits on checks. A test suite that runs in minutes keeps the system flowing; a forty-minute pipeline turns parallelism into queueing. The jump from conversational AI use to real delegation already demanded trustworthy verification. Parallelism triples the load on it.

The third demand is on you: your attention becomes a review queue. The job shifts from writing code to sequencing checkpoints, reading diffs, and making accept-or-redirect calls. Done well, it is high-focus work. Done carelessly, it is rubber-stamping at triple speed, and the queue you cleared this morning becomes the incident you own next week.

Where it breaks

Three failure modes account for most of the wreckage we see.

Shared state. Lockfiles, generated code, database schemas, global configuration: the files every stream touches. Two agents bumping dependencies simultaneously will burn more time in conflict resolution than the parallelism saved. Route all shared-surface changes through a single stream, always.

Flaky tests. A two percent flake rate is an annoyance at human throughput and a crisis at agent throughput: with dozens of runs a day it fires daily, and an agent that hits a spurious failure will earnestly try to fix code that was never broken. Fix the flakes before scaling the streams. Nothing corrupts agent work faster than a verification signal that lies.

Unclear ownership. When a parallel change breaks production, "the agent did it" is not an accountability model. Every stream needs a named human owner who reviewed it, merged it, and answers for it. The moment ownership blurs across three simultaneous streams is the moment to drop back to two.

Start with two, not five

The honest onboarding advice: parallelism is a skill with a rate limit, and the limit is your review capacity, not the agents. Start with two streams, one risky and one routine. Keep checkpoint notes per stream, because human context-switching is the real overhead and half-remembered state is how mistakes slip through. Add a third stream only when review is consistently keeping pace and your verification is fast enough that you never wait on it. The engineers who thrive at three streams got there in months, through process, not talent.

Parallel work rewards teams that invested in the boring foundations: task templates, fast tests, clean review tiers, honest ownership. That is not a coincidence, and it is why we treat parallel work as a later stage of the agentic engineering rollout rather than the starting point. Get one stream trustworthy first. The second and third are then mostly free, and that is where the delivery numbers get interesting.