Agent Scoping

Agent Scoping

Decide what deserves to be built. Most requests for an agent should be answered with a different agent, a fix upstream, or nothing.

When to use

• Somebody asks for an agent, a skill, or an automation
• Planning an AI roadmap for a GTM team
• A previous build failed and the next one is being scoped

Inputs

• Reads: workspace/audit/systems-audit.md
• Needs from user: the task in the form of what a person does today, how often, how long it takes, what a bad output costs, and who would use it

Workflow

1. Run the refusal test first

Four questions. A no on any of them means do not build it yet, and say why.

Is the input reliable? An agent on top of a broken data layer produces confident, well-written, wrong output faster than a human could. If the audit put the data plane below 3, fix that first. This is the most common reason to refuse.

Is there a written quality bar? If nobody can say what good looks like, the agent cannot be evaluated, and unevaluated output gets trusted by default. Write the rubric first. See eval-spec-authoring.

Is the task repeated? Under roughly weekly, and the maintenance cost exceeds the saving. Do the thing manually.

Is somebody accountable for using it? Not "the team would benefit." A named person whose work changes. Without one, adoption will be near zero regardless of quality.

2. Classify the work, because the class determines the build

The last row is a rule, not a preference. Anything that sends an email, spends money, or writes to the CRM gets a human approval step until it has a long track record.

3. Score the candidates

When there is a list of possible builds, score each 1 to 10 on three dimensions, out of 30.

Highest total wins. The confident thing you can ship this month usually beats the ambitious thing nobody will maintain. Ease is where teams lie to themselves, because it is scored on build time and paid on maintenance time.

4. Write the brief

AGENT / SKILL:        <name>
The task today:       <what a person does, step by step>
Frequency:            <per week>
Time now:             <minutes per run>
Class:                <from the table above>
Reads from:           <context portfolio modules, data files, systems>
Guardrails:           <spend, conflict checks, refusals, escalation>
Human gate:           <where, or explicitly none and why>
Success threshold:    <measurable, e.g. correction rate under 30% at week 4>
Kill criterion:       <what makes us stop, stated now>
Accountable user:     <name>
Owner:                <name>

The kill criterion is the field that matters most and the one always left blank. Without it, a failing agent stays in the repo forever because nobody has authority to remove it. Write it before building, when you are still honest.

5. Name what you are not building

Every scoping session should produce a short list of the things considered and refused, with reasons. It stops the same request arriving three more times, and it is the most reused artifact from this skill.

Output

• Writes: workspace/agents/<name>/brief.md
• Uses: templates/agent-brief-template.md
• Prints: the refusal test results, the class, the score if there were candidates, the brief, and the not-building list

Rules & quality bar

• Refusal test before anything else. A no is a valid and common output
• Never build on a data plane scored under 3. Route to the data layer and say so
• Deterministic work is not an agent. Write a script
• Anything that sends, spends, or writes to a system of record gets a human gate
• Kill criterion is mandatory, written before the build
• A named accountable user, or do not build
• Build on the third repetition, not the first

Related skills

• Requires: gtm-systems-audit for the data plane score
• Hands off to: context-portfolio, then skill-authoring, then agent-guardrails
• See also: docs/build-surface.md for choosing the primitive