Task Is the Atomic Unit of Work Your Subagents Need

Subagents are not new. People have been wiring agents to call other agents for a while: a planner, a researcher, a writer, a reviewer. The pattern is old enough that the bad version is already a cliché. Five prompts in a trench coat, passing half-structured text to each other and calling it architecture.

So why do they suddenly feel different?

Part of the answer is that the interaction model is changing. Agent tools are shifting from prompts to goals. Instead of telling the model what to do next, you describe an outcome and let the runtime keep working until it believes the objective has been achieved. It’s a meaningful shift from prompting to delegation.

But neither subagents nor goals are the breakthrough.

What’s actually changed is the question they force you to answer:

What is the task?

A goal names the destination. “Modernize this service.” “Migrate this monolith to microservices.” Those are perfectly reasonable goals. They’re terrible units of execution. The work still has to be decomposed into pieces with bounded scope, clear authority, evidence, and a promotion rule. Goals tell the system where it’s trying to go. Tasks define what can safely be delegated.

Not the project. Not the feature. The task, as a unit small enough to define, inspect, retry, validate, and promote. That unit is what this whole piece is about, because subagents only become useful once it’s clear.

‍The atomic task

Most agent systems fail because the work is too mushy. The instruction is broad, the context is huge, the tools are over-permissioned, the output standard is implicit. The agent has no clean way to know when to stop, when to ask for help, or when to hand the work back. Then the team wonders why the result is hard to trust.

The more useful abstraction is an atomic task. It has an objective, the context that objective needs, and the tools that objective allows. It has constraints and stop conditions, an expected output shape, and evidence requirements. And it has a validator and a promotion rule that decide whether the work is accepted.

That last part is what people skip. They start with "we need a researcher and a coder and a reviewer." Maybe. But the role name matters far less than the task the role owns. A subagent earns its keep when it's the runtime for a well-formed atomic task, and not before.‍

The bad version

The bad version is easy to build. One agent plans the feature, another implements it, a third reviews it, a fourth writes tests. You pass the whole transcript around because including everything feels safer.

It demos well. In production it breaks the same way every time. The planner makes an assumption and never writes it down as one. The implementer treats it as fact. The test writer tests the happy path the implementation implies. The reviewer sees a plausible diff and misses the bad premise underneath it.

Everyone "did their job." The system still failed. That's the gap between assigning agents and designing work.‍

The good version

The good version starts with the smallest useful unit of delegation. "Modernize this service" is too big. Even "migrate this endpoint" is probably too big. Something like this is closer:

-Objective: replace one deprecated authentication helper in one service. 

-Context: the current helper, the replacement API, the call sites in this service, the auth tests, the migration note. 

-Allowed tools: read the repo, edit files in this service, run targeted tests. 

-Stop conditions: if the helper crosses a service boundary, stop. If a test needs external credentials, stop and report. If behavior is ambiguous, stop and ask. 

-Evidence: changed files, tests run, test output, remaining call sites, assumptions, rollback note. 

-Promotion rule: a human can approve if tests pass, no cross-service behavior changed, and every in-scope call site is migrated.

Now the subagent has a real job. It isn't "the coding agent," it's the agent executing this task. And because the task is defined this tightly, it can be retried, compared, audited, or handed to a different model. The subagent is replaceable. The task boundary is the durable thing.‍

What this looked like in practice

We ran a version of this on a legacy modernization engagement, a vertical software company moving off an aging codebase. The first instinct was to scope by feature: migrate billing, migrate reporting. Those tasks failed the way the bad version always fails, too broad to inspect and too tangled to retry.

So we cut smaller. One deprecated dependency, one bounded module, the call sites in scope, and a hard stop the moment the work reached across a system boundary. The evidence wasn't a transcript. It was a generated regression suite, a few hundred tests the agent wrote and ran against the change, plus a manifest of what it touched and the assumptions it made. A reviewer could promote the work by reading that instead of re-reading everything the agent did. At that scope, a few days of agent-run work produced about a sprint's worth of change. The throughput was real, but the throughput isn't the point. The promotable unit is.

The lesson that carried past that one codebase wasn't about code. It was about boundaries. The task that hides its failure best is the one that quietly reaches across the system of record. It looks done, and it isn't. Once the rule is that the system of record stays the record and the agent only builds against it, those failures stop hiding.‍

Why this changes the architecture

When the task is the unit, the roles change shape. The planner stops being a chatbot that writes a nice list and becomes a decomposer, breaking a large objective into pieces small enough to execute and inspect. The worker runs exactly one task inside a constrained context instead of acting as a general-purpose builder. The validator checks one thing: does the evidence meet the acceptance rule. The critic hunts for what the others miss, the unstated assumption, the scope drift, the thin evidence, the task that should never have been issued at all.

The promotion gate is what ties it together. Without it you have automation with extra model calls. With it, every task has a path from attempted to accepted.

‍‍

What breaks at scale

The hard problems aren't the ones people demo. They show up when you run many tasks in parallel. Two agents touch adjacent files. One task depends on an assumption another task just invalidated. A worker succeeds technically but produces evidence too thin to promote. A validator rejects output for a reason the planner should have caught first. A task retries forever because no one encoded the stop condition.

At that point the question isn't whether your model is smart. It's whether your work system has the basic mechanics:

• Can tasks declare dependencies?
• Can they reserve files, services, records, or workflow objects?
• Can they fail cleanly?
• Can they retry without corrupting state?
• Can a human read the evidence without reading the whole transcript?
• Can the system tell "failed" from "blocked" from "should never have been attempted"?

This list will look familiar to anyone who's operated Temporal, or any durable workflow system. Dependency graphs, reservations, clean retries are old problems. What's new is that failures here are semantic, not just infrastructural: a retried task doesn't just re-run, it can re-reason its way to a different wrong answer.

We haven't solved all of these, and neither has anyone else. But two of them are where most of our engagement time actually goes.

On evidence: we treat readable evidence as a hard requirement, not a nice-to-have. A task closes with an artifact, not a log. A generated regression suite, a changed-file manifest, an assumptions list, the test output. The same things a senior engineer would demand in a pull request, and nothing more. When that artifact is good, promotion runs as a gate: tests pass, no out-of-scope files touched, every in-scope call site migrated. The day a reviewer reaches for the transcript to trust the work is the day you learn the evidence requirement was too thin, and the fix lives in the task design, not the model.

On reservation: this is where parallel runs corrupt themselves, and the honest answer is that some of it is enforced and some of it is still discipline. The boundary we hold hard is the system of record. The record stays the record, the agent builds against it, and a task that would write across that line stops and escalates instead of reaching through. File and service contention is closer to convention than to a real lock today. Tasks declare what they touch, and the planner avoids issuing two that fight over the same thing. Closing the distance between "declared" and "enforced" is one of the more interesting problems still in front of us.

Once work splits into atomic tasks like this, you need scheduling, state, evidence, validation, and promotion. That's why subagents are starting to feel less like a prompt trick and more like infrastructure, and not because every workflow needs a swarm.‍

What to build first

Don't start with a multi-agent platform. Start with one workflow and one kind of task, say a low-risk code change in a bounded service. Define the task shape, the allowed tools, the evidence, the validator, the promotion rule. Then run ten of them.

Ten real attempts will teach you more than any architecture debate. You'll see whether the planner scopes too broadly, whether workers need more context or less, which evidence humans actually read, and whether validation catches real problems or just adds noise. Add more task types only after that.‍

The shift

Subagents aren't the breakthrough. The breakthrough is treating agentic work as atomic tasks you can package, schedule, inspect, validate, and promote. That's why the unit matters so much. Make the unit "an agent" and teams obsess over personalities, prompts, and tool menus. Make it "an atomic task" and they design scope, context, constraints, evidence, and acceptance instead.

That's the line between a demo that looks autonomous and a system that survives production. The frontier isn't more agents. It's better-understood work.