How to scope an AI agent task

“Fix the page.” “Research this.” “Make it better and ship it.” These requests can be perfectly understandable between people who share a moment, yet still be unsafe instructions for an agent that can inspect files, call tools, and change external state. The missing information is not always more background. It is the shape of the task.

A bounded task answers five questions before execution: what outcome should become true, what is inside and outside the job, what the agent may do, what will count as evidence, and when it must stop. That small frame gives the agent room to reason without asking it to guess where its authority ends.

§1Scope before you optimise the prompt

Prompt polish cannot repair a missing decision boundary. A beautifully worded request can still leave the agent unsure whether to diagnose or fix, whether to edit one surface or every related surface, whether to publish or prepare a draft, and whether “done” means a file changed or a user-visible result works.

The broader guidance points in the same direction. The NIST AI Risk Management Framework begins by mapping purpose, context, requirements, scope, and human oversight before measurement and management. OpenAI’s practical guide to building agents treats clear instructions, defined tools, guardrails, and handoff conditions as foundations for reliable action. This page translates those system-level ideas into a task-level working method.

§2Start with an observable outcome

An activity is not an outcome. “Review the navigation” describes effort. “A first-time reader can reach the guide library from the header and every destination resolves” describes a state that can be observed.

Use one main outcome. Supporting checks can be plural, but several competing outcomes usually mean the request should become separate tasks. A clear result also makes partial completion honest: the agent can report which part became true and which part did not.

§3Draw the boundary in both directions

“Only change the article ending” is stronger than “work on the article.” It names the included surface. The matching exclusion—“do not alter the global navigation or visual system”—prevents a locally useful task from turning into a site-wide redesign.

A practical boundary has three parts:

• In scope: the surfaces, records, or decisions this task owns.
• Out of scope: tempting adjacent work that should remain unchanged.
• Sources of truth: the documents, manifests, live states, or rules that outrank assumptions.

Sources of truth belong inside scoping because two correct edits to two different copies can still produce the wrong result. If the agent cannot identify the authoritative source cheaply, orientation becomes the first subtask.

§4Separate scope from authority

Scope says what the task concerns. Authority says which actions the agent may take. An agent can be allowed to inspect a complete system while being authorised to edit only one file, or allowed to prepare a release while being required to ask before publishing it.

Write authority as verbs:

• May: read, compare, edit, build, test, draft.
• Must ask before: deleting, spending, publishing, messaging, or changing an irreversible external state.
• Must not: expose private material, invent facts, broaden the request, or bypass a failed safety check.

The goal is not to make every action require permission. It is to make the meaningful boundary explicit so the agent can move quickly inside it and pause at the edge.

↑ contents

§5Choose evidence before execution

If proof is decided after the work, it tends to favour whatever the agent already produced. Decide the claim and its evidence together. A content change may need the rendered page and working destinations. A data change may need a count and a sample. A behaviour change may need a real interaction rather than a source-code assertion.

The useful sequence is claim → evidence → method:

1. State what must be true.
2. Name what a reviewer would accept as proof.
3. Choose the lightest reliable way to produce that proof.

The compact acceptance contract helps define this relationship, while the narrow verification pass keeps the first check focused on the path that actually changed.

§6Write stop conditions for uncertainty

Agents need a success condition, but they also need a principled way to stop short of success. Without it, uncertainty can become confident improvisation: the wrong source is edited, a missing fact is invented, or a release proceeds after a required check fails.

Useful stop conditions are specific and recoverable:

• stop if two sources of truth conflict;
• stop if the only fix would expand beyond the named scope;
• stop before a gated external action;
• stop after a defined number of failed attempts;
• return the evidence gathered, the blocker, and the smallest decision needed next.

A good stop does not discard progress. It leaves a clean decision point that a person or another agent can continue.

§7Match the brief to the risk

Not every task needs a page of instructions. A reversible wording edit may fit in five lines. A task that touches money, personal data, production state, or external communication needs tighter authority, stronger evidence, and earlier human confirmation.

The brief should become more precise as reversibility falls and impact rises. Length is optional; explicit decisions are not.

§8Turn one loose request into a runnable task

Consider the request: “Improve the documentation landing page and publish it.” The intent is understandable, but the task is not yet bounded. A runnable version might say:

This version does not prescribe every implementation step. It preserves room for judgment while making completion, drift, and escalation visible.

↑ contents

§9Assemble the brief from the right existing tools

A new template is not needed for every variation of the method. Combine the existing artifact that matches the uncertainty in front of you:

• Use the compact acceptance contract when the outcome and proof are still vague.
• Use the public-safe task packet when working context must be separated from publishable material.
• Use the source-of-truth orientation packet when the correct editable source is not yet known.

Add authority and stop conditions directly to the task. If that same addition proves useful across several tasks, then it may deserve a durable project rule rather than another near-duplicate public template.

§10Keep the next question, not another task

Once a boundary works repeatedly, copying it into every prompt creates a new maintenance problem. The next useful question is: when should a successful task boundary become a durable project rule?

That question is recorded here, not automatically queued. It should become a page only if repeated work shows that readers need the distinction between one-off task scope and lasting operating context.