The Bounded Task Principle: Why Constrained AI Agents Outperform Open-Ended Ones
Claude just found 22 vulnerabilities in Firefox in two weeks — including 14 high-severity ones.
People are talking about model capability. They're missing the real lesson.
It worked because the task was bounded.
Defined scope. Defined output format. Defined success criteria. The agent wasn't asked to "improve Firefox security" — it was given specific parameters, a specific surface area, and a clear definition of what a finding looks like.
That's the principle. And it applies to every agent you build.
Why Vague Tasks Break Agents
Most agents fail not because of model quality — but because the task spec is under-defined.
When a task can mean five different things, an agent picks one interpretation. Often the wrong one. Then it optimizes hard for that interpretation while the user wanted something else entirely.
Symptoms of a vague task spec:
- Agent loops longer than expected
- Output looks "reasonable" but misses the point
- Different runs produce wildly different results
- Agent asks clarifying questions at the wrong time (mid-task, not before)
The Four Fields of a Bounded Task
Add these four fields to every task definition — whether it's in a prompt, a current-task.json, or a SOUL.md instruction:
{
"scope": "What is in bounds. Be explicit about what is NOT in scope.",
"output_format": "Exactly what the result should look like.",
"done_when": "Observable condition that defines completion.",
"success_criteria": "How a human will evaluate whether the output is correct."
}
Scope prevents the agent from doing too much. It answers: "What are the edges?"
Output format prevents interpretation drift. It answers: "What does done look like structurally?"
Done when prevents infinite loops. It answers: "When should the agent stop?"
Success criteria closes the feedback loop. It answers: "How will we know it worked?"
The Firefox Example Applied
Here's how the Anthropic/Firefox audit maps to these four fields:
Scope: Firefox source code — specific modules, not the whole web
Output format: Structured vulnerability reports with severity, description, reproduction steps
Done when: All in-scope modules reviewed, or X hours elapsed
Success criteria: Human security engineer can reproduce and confirm each finding
Notice what isn't in there: "make Firefox more secure." That's an aspiration, not a task spec. The bounded version is what produced 22 actionable findings.
Constraint Is the Capability
This runs counter to how most people think about agents. They assume more capability = better results. So they give the agent more tools, wider scope, longer context windows.
The opposite is usually true.
A well-constrained agent with a bounded task:
- Spends less time reasoning about what to do
- Produces more consistent outputs
- Fails faster when something is wrong (instead of drifting)
- Is dramatically cheaper to run
The agents that perform best in production aren't the ones with the most tools. They're the ones with the clearest task definitions.
The 3-Minute Audit
For any agent you're running today:
- Can you state the scope in one sentence? (If not, the scope is too vague)
- Can you describe what the output looks like before the agent runs? (If not, the format isn't defined)
- Can you tell — without ambiguity — when the agent should stop? (If not, you don't have a done condition)
- Would you know if the output was wrong? (If not, you don't have success criteria)
If you can't answer all four, tighten the task spec before adding any new tools or capabilities.
The battle-tested configs for bounded task patterns — including current-task.json templates and SOUL.md escalation rules — are in the Ask Patrick Library.