Scope Work an Agent Can Own: Four Tests, and Verifiability Is Load-Bearing
Managing agent work starts at intake, with one question: which tasks can an agent finish without a human relaying messages? Brex's answer is a published rule, and the load-bearing word in it is "verifiable." Brex needed to migrate gRPC client factories across 400+ services in its monorepo. The work was repetitive enough to describe once: for simpler services, an agent produced 100 to 200 lines of changes, one-shot, in about 30 minutes. That job is the template for what agents can own today. Brex's stated rule: "Scope the work tightly. This is for tasks that are tedious, well-defined, and common enough that nobody wants to own them manually. That category is larger than you'd expect, and it grows as the platform does."
The plumbing that scoping depends on (closed feedback loops, machine-checkable outcomes, decision gates) comes later in this section. Scoping decides which work ever reaches it.
Four tests qualify a task, and verifiability is the one teams skip
A task an agent can own without supervision passes four tests:
| Test | What it means | Failing example |
|---|---|---|
| Tedious | Nobody wants to own it manually | A novel product feature engineers compete for |
| Well-defined | The pattern can be described once, up front | "Improve the architecture" |
| Verifiable | A machine can check the result (tests, CI, type checks) | A UX judgment call |
| Common | It recurs, so the setup cost amortizes | A one-off script nobody will run again |
The verifiable test is the load-bearing one, because it determines whether the feedback loop can close without a human in it. Brex's diagnosis of agent failure was never model capability; it was that CI logs, review-bot comments, and stack traces existed but agents couldn't reach them, leaving engineers "passing notes." A task with machine-checkable success criteria lets the loop run agent to CI to fix to green without a messenger. A task without them puts the human back in the loop on every iteration, which is supervision, not ownership. Two pages later in this section build out that mechanism: closed feedback loops covers the plumbing, and verifiable outcomes defines what actually counts as machine-checkable.
Cognition frames the same boundary from the vendor side: Devin works best on tasks with "clear, upfront requirements and verifiable outcomes," and human review stays mandatory because "code quality is not straightforwardly verifiable."
The published successes all sit inside the category
Every production system running thousands of autonomous PRs is running them on migrations, test coverage, and cleanup, not on feature work. The numbers are large precisely because the scope is narrow:
- Airbnb converted 3.5K Enzyme test files to React Testing Library in 6 weeks against a 1.5-engineer-year estimate, 97% of files fully automated. Migration, hard validation loop, retry on failure.
- Spotify's Honk passed 1,500+ merged PRs by November 2025 and reached roughly 1,000 merged PRs every 10 days, driven by fleet-wide migration prompts.
- Stripe's Minions merge 1,300+ PRs per week, with Stripe's 3M tests as the verification loop.
- Uber's AutoCover raised developer-platform test coverage 10% and saved ~21,000 developer hours. Coverage is the most machine-verifiable outcome there is.
- Instacart's Olive has agents cleaning up dead code and expired experiments: tedious, common, and trivially verifiable.
This is also why Thoughtworks holding software engineering agents at Trial and Stripe running thousands of unsupervised PRs are both right: the supervision advice applies outside this category, and the autonomous numbers come from inside it. Verifiable outcomes makes that reconciliation in full.
The category grows with the platform, not the model
What an agent can own is a function of what its environment can verify, so every tool you connect moves the boundary outward. Brex says this directly: as they extend agent access to internal tool verification, test workload deployment, and browser-based checks for frontend changes, "the scope of what's delegable keeps expanding." A frontend change was unverifiable until the browser check existed; then it joined the category. The model did not get smarter that week. The environment got more connected.
This is why scoping is a platform investment, not a one-time triage. Each closed feedback loop (a new validator, a deployable test workload, a judge for diffs) converts a class of formerly human-supervised work into agent-ownable work. The same logic shows up in merge rates: Devin's went from 34% to 67% year over year, and Cognition's own framing attributes the gain to better-scoped delegation, not just better models. Build the verification, and the work follows. The per-task environment that carries those tools is the subject of one environment per task.
Scope discipline also runs in the other direction: refusing to let any single task grow too large. Intercom enforces it at the review gate. That half of the argument lives in scope discipline.
Where the field is honest about the limits
The published record is candid that this category does not yet include open-ended feature work. Birgitta Böckeler's experiments on autonomous code generation document constant intervention as the price of quality outside narrow scopes, and no published production system runs unsupervised agents on novel product features. The record is also largely silent on how teams maintain their task taxonomy over time: who decides a task class has become delegable, and on what evidence. Brex's "it grows as the platform does" is the closest thing to a published answer.
The practical move: start with your most boring backlog. Migrations nobody volunteers for, coverage gaps, dead code, dependency bumps with green-CI verification. Pass them through the four tests, route them through work intake, and treat every new validator you wire up as an expansion of the delegable set.