Use AI Subagents Without Wasting Work

Use Subagents Without Turning Parallelism Into Waste

Use a subagent when the work is independent, bounded, worth isolating, and cheap enough to reconcile. Keep the work local when the task is small, tightly coupled to your current reasoning, or likely to create more coordination than execution.

The number of active agents is not a measure of useful progress.

E118 makes that argument through a custom setup. Dalton Anderson describes specialized agents for domain work, interface and documentation, quality assurance, and security. He also warns that agents spend context communicating with one another and can create a game of telephone.

The useful question is not how many agents can run. It is whether delegation improves the verified result.

flowchart TD
    A["Candidate task"] --> B{"Independent and bounded?"}
    B -- "No" --> C["Keep it in the main context"]
    B -- "Yes" --> D{"Isolation or specialization valuable?"}
    D -- "No" --> C
    D -- "Yes" --> E["Define artifact, sources, authority, and checks"]
    E --> F["Run subagent in chosen workspace mode"]
    F --> G["Reconcile, test, and review"]
    G --> H{"Total cost lower or result better?"}
    H -- "No" --> I["Use a simpler path next time"]
    H -- "Yes" --> J["Retain the delegation pattern"]

Parallelism has an admission cost

Before a subagent can do useful work, someone must define the assignment.

That assignment needs a reader or system outcome, source boundary, expected artifact, file or branch scope, authority, constraints, validation, and a return format. If the main agent has to explain the entire project to delegate a ten-minute task, the handoff may not be worth it.

Context isolation can be a benefit. It can also remove assumptions the subagent needed. A clean context should receive a clean specification.

Google's current subagent documentation says a subagent begins with separate context and can operate in inherited, shared, or branch-isolated storage. That protects the parent context from implementation detail. It does not transfer unstated intent.

Independence matters more than size

A large task is not automatically parallel.

Two agents changing the same interface contract can block one another. One agent researching a product and another editing conclusions based on that unfinished research creates avoidable rework. Several agents writing to the same files can turn speed into conflict.

Good parallel work has a stable boundary. One agent can inventory source files while another validates external links. One can inspect a frontend while another reviews a database migration, provided the shared contract is known. One can research current product documentation while the main agent preserves a raw transcript.

The work may still be small. Independence, not size alone, makes concurrency useful.

Isolation has a reconciliation cost

Google's projects documentation distinguishes local mode from new-worktree mode. Worktrees can keep parallel changes away from the active checkout and from one another.

That is valuable when agents would otherwise conflict or when a reviewable branch is the desired artifact.

An isolated result still has to return. Someone must compare assumptions, review the diff, run tests, resolve conflicts, and decide whether the change belongs in the main line.

The merge is not administrative cleanup. It is part of the task cost.

If the work cannot be reconciled safely, isolation postponed the conflict rather than solving it.

Specialization should change the result

A specialist agent earns its place when it brings a distinct toolset, instruction set, evaluation standard, or source domain.

A security reviewer can apply a threat model the implementation agent did not use. A browser-testing agent can inspect the rendered surface. A research agent can search current first-party documentation without filling the main context with every discarded result.

Renaming a general agent “security” does not create security expertise.

The assignment should name what the specialist will evaluate, which evidence it may use, and what kind of finding it must return. The main process should retain authority to accept, reject, or investigate the result.

Google's feature deep dive describes modular, specialized, generic, and dynamically defined subagents. It also says subagents inherit tool configurations and security permissions from the main agent.

Specialization should narrow the job. It should not silently broaden authority.

Communication spends context and introduces drift

Every message between agents is another representation of the work.

The source becomes an instruction. The instruction becomes an artifact. The artifact becomes a summary. The summary becomes a merge decision. Each transition can omit a caveat, change a name, or turn uncertainty into certainty.

This is why a returned result should carry evidence rather than only a conclusion.

A research agent should return the source routes and claim boundaries. A coding agent should return changed files and test results. A reviewer should identify the exact artifact and issue. A content agent should link the raw transcript and current external sources.

Shared evidence reduces the number of times the story has to be retold.

Authority can multiply faster than work

Subagents inherit safety configurations under current Google documentation. If the parent can write broadly, run commands, use external tools, and access sensitive data, delegation may make that authority active in several places at once.

The permissions documentation makes Deny, Ask, and Allow rules explicit. The parent project should be scoped before delegation begins.

Do not give a subagent a credential merely because the main agent has it. Decide whether that specific task needs the system and action. Publication, payment, outreach, deletion, and production changes remain distinct authority decisions.

Parallel execution should not become parallel consequence.

Verification decides whether the speed was real

A subagent can finish quickly and still return an unusable result.

Count the complete cycle: specification, setup, execution, monitoring, messages, reconciliation, tests, review, and correction. Compare that cycle with the direct path.

The result may still justify delegation even if it used more tokens or wall-clock coordination. Isolation may reduce risk. A specialist may catch a serious defect. Parallel research may improve coverage.

The point is to measure the value that mattered.

E115 supplies the adjacent warning about output theater. A large volume of visible activity can obscure whether the process improved the outcome.

A simple delegation rule

Delegate when four statements are true.

The task can be described without transferring the full live context. The artifact can be reviewed independently. The work benefits from isolation, concurrency, or specialization. The expected value exceeds the context, coordination, and reconciliation cost.

When one statement is false, keep the work in the main loop or change the task boundary.

The current Antigravity product page presents dynamic subagents as a core feature. The feature is powerful because it makes delegation available. Judgment still decides when to use it.

E120 expands the idea into persistent AI coworkers. E118 provides a disciplined starting point: bring a specialist into the room when the work needs one, then send the specialist home when the bounded task is complete.

Editorial and authority note

This essay is an operating framework, not a token benchmark, cost guarantee, model comparison, concurrency prescription, security design, reliability claim, or product default. Dalton's custom agent counts and runtime rules are not universal recommendations. Technical, cost, security, reliability, editorial, accessibility, and founder review remain required before publication.

AI assisted with research, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority.