Agent Systems · core
Agent Scope Control
Bounded task decomposition, allowed edit roots, budgets, change-size limits, and escalation when evidence invalidates the plan.
Mental model
Scope is a runtime invariant, not a sentence in a prompt. Convert the goal into a bounded change surface, measurable completion condition, and explicit escalation triggers. Each observation may narrow or revise the plan, but expanding authority requires a deliberate decision.
How to study Agent Scope Control
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use OpenAI — Harness engineering, Anthropic — Building effective agents to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Agent Scope Control with Coding Agent Systems, Agent Observability, Agent Permissions & Sandboxing. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Enforce runtime scope and escalation and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Patch-size controls, allowed edit roots, task queues, budget enforcement, blast-radius limits, and agent escalation policies.
Common mistakes
- Treating an ambitious goal as permission to mutate unrelated systems
- Continuing after evidence contradicts the plan instead of replanning
- Using token or time limits without a semantic completion or escalation condition
Learn from primary sources
- OpenAI — Harness engineering (article)
- Anthropic — Building effective agents (article)
Practice and explain it back
Enforce runtime scope and escalation
Implement scopeDecision(contract, observation). contract contains allowedRoots, maxFiles, and objective. observation contains touchedFiles, objectiveSatisfied, and planInvalidated. Return 'continue' only while every file is inside an allowed root, file count is within budget, the objective is incomplete, and the plan remains valid. Return 'complete' only when the objective is satisfied within scope. Return 'escalate' for any scope breach or invalidated plan.
Expected evidence: A semantic scope gate that distinguishes continue, complete, and escalate.
Open the interactive drill →Review prompts
- Why is a token or time budget insufficient scope control, and which semantic conditions should make an agent continue, complete, or escalate?
Build evidence
Build a Complete Coding-Agent Harness
Build a repository-local harness that can take one bounded engineering task from initialization through implementation, verification, durable handoff, and explicit termination without relying on hidden machine state or chat memory.
- A fresh isolated workspace can bootstrap and prove readiness from repository-local commands
- Instruction scopes, allowed edit roots, capabilities, budgets, and escalation triggers are explicit and mechanically inspectable
- The run persists goal, progress, evidence, blockers, and the next safe action across a forced restart
- A checker gathers independent evidence and can reject an unsupported maker claim
- The lifecycle terminates only as complete, blocked, failed, cancelled, or escalated with durable evidence
Automate and Evaluate a Maker-Checker Loop
Automate a bounded loop in which a maker attempts one task, an independent checker evaluates explicit acceptance criteria, failures return actionable evidence, and the orchestrator stops on success, escalation, cancellation, or budget exhaustion. Compare it with a baseline harness on a frozen task suite.
- Maker and checker roles have separate inputs and the checker ignores unsupported self-reported success
- The loop has explicit goal, task and retry budgets, durable state, and semantic termination criteria
- A frozen evaluation suite measures success, unsafe actions, cost, latency, retries, and human interventions
- At least one component ablation isolates whether instructions, tools, verification, or retry policy caused the observed change
- Release or rejection follows a declared multi-objective gate rather than pass rate alone