For a long time I worked in a single lane. I would start one task in Claude, watch it, wait for it, then start the next, while a queue of other things I could have been doing piled up in my head. It felt productive because I was busy, but I was serializing work that had no reason to be sequential, running one job at a time on a machine that could have been running five.
Background agents broke me out of single-lane thinking. They let you launch several independent jobs at once and watch them from one screen, so you are supervising a fleet rather than nursing a session. This guide is what they are, how they differ from subagents, and how to run a group of agents without it turning into chaos.
What background agents are
A background agent is a Claude job that runs on its own while you do other things, including starting other agents. Instead of one session you sit and watch, you have several running at once, each working its own task, reporting back as it finishes or when it needs you. You are no longer the bottleneck between one task ending and the next beginning.
The shift is from doing to directing. With one session, you are effectively pair-working with Claude on a single thing. With background agents, you are more like a manager with several reports out on assignments: you set them going, check in, unblock, and collect results, but you are not standing over any single one of them.
Parallel, not sequential
The core value is simple: work that used to happen in a line now happens at the same time. Three research tasks, a drafting job, and a list cleanup do not have to wait for each other; you start them together and they run concurrently. The wall-clock time to get all of it done drops from the sum of the parts to roughly the length of the longest one.
This matters most exactly when you have a pile of independent work, which in GTM is often. A stack of accounts to research, a batch of drafts to generate, several lists to clean, none of these depends on the others, so forcing them through one session in sequence is leaving most of your throughput on the table.
The throughput math
It helps to see the arithmetic, because it is the whole argument. Five independent tasks that each take twenty minutes are a hundred minutes in a single lane and about twenty minutes as a fleet, because they overlap. You did not make any one task faster, you stopped making them wait for each other. On a pile of independent work, that is the difference between an afternoon and a coffee break.
The catch is that the math only holds when the tasks are truly independent and when you can actually supervise the fleet. Add a dependency and the parallelism breaks; add more agents than you can watch and the time you saved running them you lose reviewing them. The sweet spot is a handful of independent jobs you can oversee at a glance, which is most of a GTM morning's work.
One screen to watch the fleet
Running many agents is only manageable if you can see them all in one place, and that is the other half of the feature: a single view of the fleet, what each agent is doing, which have finished, which are waiting on you. Without that, parallelism is chaos; with it, you supervise the group at a glance and dive into the one that needs attention.
The mode this puts you in is triage, not immersion. You scan the board, see that two are done and one is blocked on an approval, handle the blocked one, and move on. You are managing exceptions rather than watching every step, which is what lets one person oversee five jobs without losing the thread of any of them.
The one-screen view is also what keeps a fleet honest about cost and correctness. Because you can see everything at once, you notice the agent that has been spinning too long, the one that finished suspiciously fast, the one waiting on an approval you missed. A fleet you cannot see is a fleet you cannot trust, and the shared view is what turns many agents from a liability into an asset.
Background agents vs subagents
These two are easy to confuse and worth separating. Subagents are workers a single job fans out to, one research task splitting fifty accounts across fifty clean contexts, and they merge back into that one job's result. Background agents are separate jobs entirely: different tasks, running in parallel, each its own piece of work with its own outcome.
The way to keep them straight: subagents are about scaling one job, background agents are about running many jobs. You might even combine them, several background agents, each of which fans out to subagents internally. But the distinction is the level: within a job, or across jobs.
TipUse subagents to scale a single big job, background agents to run several separate jobs at once. If the pieces merge into one result, that is subagents; if they are distinct tasks, that is a fleet.
What to run in parallel
The right work for a fleet is a set of independent tasks that do not need each other's output. In a GTM week that is most of the pile: research this set of accounts while you draft follow-ups for yesterday's calls while you clean an imported list. Each is its own job with its own finish line, so they run happily side by side.
The tasks that do not belong in a fleet are ones that depend on each other, where the second needs the first's result. Those want to be sequential, or a single job with steps, not parallel agents guessing at what the others produced. Parallelism is free only when the work is genuinely independent, the same rule as subagents.
Guardrails for a fleet
A fleet needs guardrails a single session does not, because you are watching each agent less closely. Set permissions per agent to match its task: the research agents get read access, the one that updates the CRM gets a tighter leash and your approval on writes. You are not there to catch every action on every agent, so the permissions have to do more of the work.
The other guardrail is not over-parallelizing. More agents means more cost and more to supervise at once, and past some point you are not managing a fleet, you are drowning in one. Run as many as you can genuinely oversee and afford, not as many as you can launch. A handful you watch beats a dozen you have lost track of.
- Set permissions per agent: reads for research, tight limits and approval for anything that writes.
- Cap how many run at once to what you can actually supervise and afford.
- Keep each agent's task independent, so no agent is guessing at another's output.
- Know which agents can act versus only read, so an unattended write never surprises you.
Where it goes wrong
The first trap is cost, which multiplies quietly with a fleet: five agents cost roughly five times one, and a fleet left running racks up spend while you are not watching. Keep an eye on how many are going and use cheaper models for the routine ones, the same cheap-workers logic as subagents.
The second is losing the thread, launching more agents than you can supervise, so results pile up unreviewed and a bad run slips through. And the third is unattended writes across a fleet: with many agents acting at once, an unguarded write tool is many chances to do the wrong thing, not one. Watch the fleet size, review the outputs, and gate the writes.
- Cost multiplying with the fleet, especially agents left running unwatched.
- Launching more than you can supervise, so results go unreviewed and bad runs slip by.
- Unguarded write access across many agents, multiplying the chance of a wrong action.
- Parallelizing dependent work, so agents guess at outputs they should have waited for.
The GTM version
Background agents are how one GTM operator gets the throughput of a small team on independent work. Monday morning, instead of grinding through tasks in a line, you launch a fleet: one researching the week's new accounts, one drafting follow-ups from Friday's calls, one cleaning the list marketing just handed over, one pulling a competitive update. They run together, you triage from one screen, and by mid-morning the pile that would have taken all day is mostly done or waiting for a quick review.
The reframe is to stop thinking in a single lane. Your independent work does not have to queue behind itself. What are the three or four GTM tasks on your plate right now that have no reason to wait for each other?
How to set it up
Line up independent tasks
Pick tasks that do not depend on each other, research these accounts, draft those follow-ups, clean that list. Independence is what makes parallel safe; dependent work should stay sequential.
Launch them as background agents
Start each as its own background job so they run at once rather than in a queue. Check the docs for the current way to launch and manage them, since this is an evolving surface.
TipRun only as many as you can genuinely supervise and afford. A handful you actually watch beats a dozen you have lost track of.
Set permissions per agent
Match each agent's leash to its task: read access for research, tight limits and your approval for anything that writes to the CRM or sends to a person. You will be watching each one less closely, so the permissions carry more of the safety.
Triage from one screen
Watch the fleet in one view, handle the agents that are blocked or finished, and review outputs before acting on them. You are managing exceptions, not every step, which is what lets one person oversee several jobs.
Frequently asked questions
What are background agents?
Claude jobs that run in parallel, each on its own task, while you do other things. You launch several at once and watch and steer them from one screen instead of babysitting a single session.
How do they differ from subagents?
Subagents are workers a single job fans out to and merges back. Background agents are separate jobs running in parallel, each its own task and outcome. Subagents scale one job; background agents run many.
What is the benefit over one session?
Throughput. Independent tasks run at the same time instead of in a queue, so the total time drops from the sum of the tasks to about the length of the longest one. One operator does the work of several at once.
What work should I run in parallel?
Independent tasks that do not need each other's output: research a set of accounts while drafting follow-ups while cleaning a list. Dependent work, where one needs the first's result, should stay sequential.
How do I keep a fleet safe?
Set permissions per agent to match its task, cap how many run at once to what you can supervise, keep tasks independent, and gate any write actions. You watch each agent less, so the guardrails do more.
Do background agents cost more?
Yes, cost scales with the fleet, roughly the number of agents times a single one, and agents left running add up. Watch the fleet size and use cheaper models for routine agents to keep it sane.
Can I combine them with subagents?
Yes. You can run several background agents, each of which fans out to subagents internally. The distinction is the level: across jobs is background agents, within a job is subagents.
What is a good first GTM use?
A Monday-morning fleet: one agent researching new accounts, one drafting follow-ups from recent calls, one cleaning an imported list, one pulling a competitive update, all running together while you triage from one screen.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.