Lecture 07. Drawing a Clear Task Boundary for Agents

You tell Claude Code "add user authentication to this project," and it starts modifying the database schema, writing routes, changing frontend components, and — by the way — refactoring the error-handling middleware. Two hours later you check: 12 files modified, 800 new lines of code, and not a single feature working end-to-end.

You can't eat everything in one bite — this saying applies especially to AI agents. Agents have an inherent "let me just do a bit more" impulse — they see related things and just handle them right there, like someone going to the store for a bottle of soy sauce and coming home with a full cart. The problem is, humans overbuying just wastes money; an agent doing too many things at once means none of them get done properly.

Anthropic's engineering blog "Effective harnesses for long-running agents" states this clearly: when prompts are too broad, agents tend to "start many things at once" instead of "finishing one thing first." OpenAI's Codex engineering practices found the same thing — tasks without clear scope control see completion rates drop sharply. This isn't a model problem — it's a harness problem. You haven't drawn the boundary.

Attention Is a Finite Resource

This isn't a metaphor — it's math. Suppose an agent's context capacity is C and it kicks off k tasks concurrently. Each task receives an average of C/k reasoning resources. When C/k drops below the minimum threshold needed to complete a single task, none of them get completed. Your stomach has a limit — stuff in ten dumplings at once and you won't digest all of them, you'll just get indigestion ten times over.

Claude Code's actual behavior makes this clear. Ask it to "add user registration" and it might:

Create a User model
Write the registration route
Notice email verification is needed, so add a mail service
See that passwords need hashing, so bring in bcrypt
Notice error handling is inconsistent, so refactor the global error middleware
See the test file structure is messy, so reorganize the directories

After six steps, each one is half-done. There's no end-to-end verification, half-finished code compounds in complexity, and the next session tasked with cleanup gets completely lost. It's like someone cooking six dishes at once — each is on the stove but none has made it to a plate. All of them burn.

Anthropic's empirical data directly supports this: agents using the "small next step" strategy (the equivalent of WIP=1) show a 37% higher task completion rate than agents using broad prompts. More interestingly, the number of lines of code an agent generates correlates weakly negatively with actual feature completion rate — write more code, finish fewer features. You can't eat everything in one bite, proven by data.

The WIP=1 Workflow

Core Concepts

Overreach: The agent kicks off more tasks than optimal in a single session. This is quantifiable — working on 5 features with 0 passing end-to-end is overreach.
Under-finish: The ratio of tasks that pass end-to-end verification, out of all tasks kicked off, falls below a threshold. Code that's written but doesn't pass tests is under-finishing.
WIP Limit (Work-in-Progress Limit): From the Kanban method. Core idea: limit the number of tasks in progress at the same time. For agents, WIP=1 is the safest default — finish one before starting the next. It's like a buffet — don't stack your plate, finish one plate before going back for more.
Completion Evidence: The verifiable condition a task must satisfy to move from "in progress" to "done." Without this, the agent substitutes "the code looks fine" for "behavior passes tests."
Scope Surface: A DAG structure where each node is a unit of work and edges are dependencies. State is limited to four values: not_started, active, blocked, passing.
Completion Pressure: The constraining force the harness exerts through WIP limits and completion-evidence requirements, forcing the agent to finish the current task before starting a new one.

Overreach and Under-Finish Are Symbiotic

These two problems aren't independent — they amplify each other. Overreach dilutes attention, diluted attention causes under-finishing, and the leftover half-finished code increases system complexity, which further drives overreach in the next task. A vicious loop.

In Kanban terms: Little's Law tells us L = lambda * W. If work in progress L is too high (doing too many things at once), lead time W for each task inevitably increases. For agents, this means each feature takes longer from start to verified completion, and the probability of failure rises.

This is also an old problem in the human world — Steve McConnell documented in Rapid Development that scope creep is the leading cause of project failure. But humans at least have the intuition of "I've done enough already." Agents don't. Generating the next idea costs the model almost no extra tokens — writing "let me also fix this while I'm at it" is essentially free — but each additional modification dilutes the agent's attention. It's like a buffet where each extra plate has near-zero marginal cost, but your stomach still has a limit.

How to Do It Right

1. Enforce WIP=1

This is the most direct and effective method. In your harness, state clearly to the agent: only one task is allowed to be in "active" state at any given time. In Claude Code's CLAUDE.md or Codex's AGENTS.md, write:

## Work Rules
- Work on one feature at a time
- Only start the next feature after the current one passes end-to-end verification
- Don't "also refactor" feature B while implementing feature A

It's like eating at a buffet — one plate at a time, finish it before going back for more.

2. Define Clear Completion Evidence for Every Task

Done isn't "code was written" — it's "behavior verification passed." In your feature list, every item needs a verification command:

F01: User Registration
 Verification: curl -X POST /api/register -d '{"email":"test@example.com","password":"123456"}' | jq .status == 201
 Status: passing

3. Externalize the Scope Surface

Use a machine-readable file (JSON or Markdown) to record all task states. Any new session can read this file and immediately know: which task is active? What behavior counts as done? What verification has passed?

4. Track the Verified Completion Rate

The harness should continuously track VCR (Verified Completion Rate) = verified tasks / kicked-off tasks. Block new task activation when VCR < 1.0.

Real-World Case

A REST API project with 8 features, two strategies compared:

Buffet mode (no constraints): The agent kicks off 5 features concurrently in session 1. Produces ~800 lines across 12 files. End-to-end test pass rate: 20% — only user registration works. The remaining 4 features: database schema created but missing auth logic, routes defined but returning the wrong response format. It's like someone cooking six dishes at once, with only one barely edible. By the end of session 3, only 3 of 8 features are complete.

One-plate mode (WIP=1): The agent only works on user registration in session 1. Produces ~200 lines across 4 files. End-to-end tests: 100% pass. Commits a clean, verified implementation. By the end of session 4, 7 of 8 features are complete (the 8th blocked by an external dependency).

Result: less total code (800 vs 1200 lines) but more efficient code. Completion rate: 87.5% vs 37.5%. Eat one bite at a time, and you actually end up eating more.

Key Takeaways

WIP=1 is the safest default setting for an agent harness — finish one, then start the next; don't try to parallelize. You can't get full in one meal.
Completion evidence must be executable — "the code looks fine" doesn't count; "curl returns 201" does.
The scope surface must be externalized as a file — not just mentioned in conversation, but recorded in a machine-readable format in the repo.
Overreach and under-finish are symbiotic — solving one solves the other.
"Do less but finish it" always beats "do more but leave it half-done" — agent lines of code and feature completion rate correlate negatively. Quality always beats quantity.

Exercises

Atomize a Task: Pick a broad request (e.g., "implement a user management system") and break it into at least 5 atomic units of work. For each unit, specify: (a) a single behavior description, (b) an executable verification command, (c) dependencies. Check whether the breakdown satisfies the WIP=1 constraint.

Comparison Experiment: Run the same project twice — once with no constraints, once with WIP=1 enforced. Compare: verified completion rate, total lines of code, effective code ratio.

Completion Evidence Audit: Review the output of a recent agent run, classify each code change as "completed behavior," "unfinished behavior," or "scaffolding." Add the missing verification commands for each unfinished behavior.