Scope Rules: When a Problem Actually Needs an Agent

These rules decide whether a problem should be an agent at all, versus a script, a fixed workflow, a single LLM call, or a human process with light AI assistance.

Most early project pain is mis-scope: an agent where deterministic automation would be cheaper and more reliable, or a brittle script where mid-run tool choice is actually required.

How to Use This List

Apply the fit table first; only then choose architecture and models.
Require a written goal and out-of-scope list before any multi-turn loop is approved.
Re-run this checklist when someone proposes "just make it an agent" for a feature that already has a stable path.
Record the decision in a short ADR or ticket comment so the next engineer does not re-litigate it from scratch.

Agent Fit at a Glance

Signal	Prefer agent	Prefer non-agent
Path known end-to-end	Rarely	Script, workflow, or pipeline
Mid-run tool choice depends on observations	Yes	Fixed DAG / if-else workflow
Needs natural language understanding only once	Maybe single LLM call	Not a multi-turn agent
Actions are irreversible or high stakes	Only with human gates	Strong automation + approvals
Success criteria are crisp and testable	Yes, if branching remains	Still may be a script if path is fixed
Problem is "chat with docs" only	Often RAG Q&A, not agent	Retrieval + answer, no tool loop

Fit Rules (When an Agent Wins)

Require branching that cannot be fully pre-encoded. If every branch is already known, encode it in code or a workflow tool instead of paying for a model to rediscover it each run.
Require mid-run observation that changes the next action. Agents earn their keep when tool results, page contents, or test failures legitimately alter the plan.
Require a goal that is checkable. "Improve the codebase" is not a goal; "open a PR that makes pytest pass on package X" is.
Require tool use beyond one predetermined API call. A single function call wrapped in an LLM is usually just tool-calling chat, not a multi-step agent product.
Prefer agents when partial progress can be resumed or inspected. Long research or coding tasks benefit from visible intermediate state; pure one-shot transforms do not.

Non-Fit Rules (When to Refuse an Agent)

Refuse pure format conversion and extraction with fixed schemas. Deterministic parsers or one LLM structured-output call beat a loop.
Refuse problems whose only uncertainty is copy tone. Drafting email text rarely needs tool loops; use a single generation with review.
Refuse high-stakes irreversible actions without a human or policy gate. Payments, deletes, production deploys, and legal filings need bounded tools and approvals, not open autonomy.
Refuse "agent" branding for scheduled jobs with fixed steps. Cron plus scripts remains the right shape for known periodic work.
Refuse multi-agent designs when a single bounded agent is unproven. Complexity compounds; scope one agent first.

Goal and Boundary Rules

Write a one-sentence goal that a stranger could grade pass/fail. If two reviewers would disagree on done, the agent will thrash.
List out-of-scope actions explicitly. "Do not email customers," "do not modify billing," and "do not browse outside allowlisted domains" belong in the brief.
Cap the tool inventory to the goal. Extra tools are extra failure modes and prompt-injection surface.
Define the human escalation path as part of scope. "Stop and ask" is a feature, not an admission of defeat.
Separate research scope from execution scope. An agent allowed to read should not silently gain write powers mid-project.

Autonomy and Risk Rules

Match autonomy level to reversibility. Draft-only and suggest-only modes first; unsupervised execution only after evals and gates exist.
Budget blast radius before intelligence. A weaker model with tight tools beats a frontier model with shell and prod credentials.
Prefer read-only prototypes. Validate goal fit and stopping before enabling write tools.
Treat cost as a scope constraint. If the business case cannot tolerate multi-turn token burn, redesign as fewer steps or non-agent automation.
Revisit scope after the first production week. Real usage reveals hidden branches; shrink or expand tools deliberately, not by accretion.

Decision Cheatsheet

Question	If yes	If no
Is the happy path fully known and stable?	Script / workflow	Continue
Must next actions depend on live tool results?	Agent candidate	Single LLM or script
Is success objectively checkable?	Continue	Clarify goal before building
Are side effects reversible or gated?	Continue	Add gates or refuse autonomy
Can a cheaper non-agent meet the SLA?	Prefer non-agent	Agent with bounds

FAQs

Is every system that calls tools an agent?

No.

A single predetermined tool call from an LLM is tool-using chat.

An agent typically loops: observe results, decide again, act again, until a stop condition.

Can an agent still be the right choice if most runs follow one path?

Yes, if the long tail of branches is expensive to encode and rare cases matter.

Measure how often the long tail appears before paying agent complexity forever.

How detailed should the out-of-scope list be?

Detailed enough that a new engineer would not grant a dangerous tool "just in case."

Name systems and action types, not only vague "be careful" language.

What if stakeholders demand an agent for marketing reasons?

Ship agent UX if needed, but implement a bounded workflow underneath when the path is fixed.

Do not accept unbounded loops to satisfy a label.

How do scope rules interact with stopping rules?

Scope defines what "done" means; stopping rules enforce exit when done, failed, or timed out.

Without scope, stop checks have nothing crisp to evaluate.

Is RAG alone enough to call a product an agent?

Usually no.

Retrieval-augmented answering is often a single-shot or short pipeline unless it also plans multi-step tool use.

When is a workflow builder (n8n, Zapier, graphs) better than an agent loop?

When steps and branches are known, need reliability, and should be edited by operators without prompt archaeology.

How should we scope coding agents versus business agents?

Same fit rules: checkable goals, tool necessity, reversibility.

Coding agents often have strong oracles (tests); business agents need explicit success checks you invent.

What is a good first agent scope for a team new to agents?

Read-heavy, low-blast-radius tasks with clear done checks: ticket triage suggestions, internal research drafts, or test-failure summarization - not unsupervised prod changes.

Can scope change mid-run?

Only through an explicit replan or human approval.

Silent scope expansion is how agents wander into unrelated tools and data.

How do I document a "not an agent" decision?

One paragraph: problem, why path is fixed, chosen non-agent shape, revisit trigger if branches explode.

Do scope rules apply to personal agents with shell access?

Especially yes.

Personal shell agents have high blast radius; start read-only and allowlist commands.

Why Fundamentals Rules Prevent Early Agent Project Failures - why scope is the first bound.
The Core Agent Fundamentals Rules: A Quick-Reference List - condensed row form of these rules.
Stopping-Condition Rules Every Agent Must Implement - exits once scope defines done.
Common Fundamentals Mistakes New Agent Builders Make - mis-scope patterns to avoid.
AI Agent Fundamentals Rules Best Practices - checklist including scope items.

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Most early project pain is mis-scope: an agent where deterministic automation would be cheaper and more reliable, or a brittle script where mid-run tool choice is actually required.

How to Use This List

Apply the fit table first; only then choose architecture and models.
Require a written goal and out-of-scope list before any multi-turn loop is approved.
Re-run this checklist when someone proposes "just make it an agent" for a feature that already has a stable path.
Record the decision in a short ADR or ticket comment so the next engineer does not re-litigate it from scratch.

Agent Fit at a Glance

Signal	Prefer agent	Prefer non-agent
Path known end-to-end	Rarely	Script, workflow, or pipeline
Mid-run tool choice depends on observations	Yes	Fixed DAG / if-else workflow
Needs natural language understanding only once	Maybe single LLM call	Not a multi-turn agent
Actions are irreversible or high stakes	Only with human gates	Strong automation + approvals
Success criteria are crisp and testable	Yes, if branching remains	Still may be a script if path is fixed
Problem is "chat with docs" only	Often RAG Q&A, not agent	Retrieval + answer, no tool loop

Fit Rules (When an Agent Wins)

Require branching that cannot be fully pre-encoded. If every branch is already known, encode it in code or a workflow tool instead of paying for a model to rediscover it each run.
Require mid-run observation that changes the next action. Agents earn their keep when tool results, page contents, or test failures legitimately alter the plan.
Require a goal that is checkable. "Improve the codebase" is not a goal; "open a PR that makes pytest pass on package X" is.
Require tool use beyond one predetermined API call. A single function call wrapped in an LLM is usually just tool-calling chat, not a multi-step agent product.
Prefer agents when partial progress can be resumed or inspected. Long research or coding tasks benefit from visible intermediate state; pure one-shot transforms do not.

Non-Fit Rules (When to Refuse an Agent)

Refuse pure format conversion and extraction with fixed schemas. Deterministic parsers or one LLM structured-output call beat a loop.
Refuse problems whose only uncertainty is copy tone. Drafting email text rarely needs tool loops; use a single generation with review.
Refuse high-stakes irreversible actions without a human or policy gate. Payments, deletes, production deploys, and legal filings need bounded tools and approvals, not open autonomy.
Refuse "agent" branding for scheduled jobs with fixed steps. Cron plus scripts remains the right shape for known periodic work.
Refuse multi-agent designs when a single bounded agent is unproven. Complexity compounds; scope one agent first.

Goal and Boundary Rules

Write a one-sentence goal that a stranger could grade pass/fail. If two reviewers would disagree on done, the agent will thrash.
List out-of-scope actions explicitly. "Do not email customers," "do not modify billing," and "do not browse outside allowlisted domains" belong in the brief.
Cap the tool inventory to the goal. Extra tools are extra failure modes and prompt-injection surface.
Define the human escalation path as part of scope. "Stop and ask" is a feature, not an admission of defeat.
Separate research scope from execution scope. An agent allowed to read should not silently gain write powers mid-project.

Autonomy and Risk Rules

Match autonomy level to reversibility. Draft-only and suggest-only modes first; unsupervised execution only after evals and gates exist.
Budget blast radius before intelligence. A weaker model with tight tools beats a frontier model with shell and prod credentials.
Prefer read-only prototypes. Validate goal fit and stopping before enabling write tools.
Treat cost as a scope constraint. If the business case cannot tolerate multi-turn token burn, redesign as fewer steps or non-agent automation.
Revisit scope after the first production week. Real usage reveals hidden branches; shrink or expand tools deliberately, not by accretion.

Decision Cheatsheet

Question	If yes	If no
Is the happy path fully known and stable?	Script / workflow	Continue
Must next actions depend on live tool results?	Agent candidate	Single LLM or script
Is success objectively checkable?	Continue	Clarify goal before building
Are side effects reversible or gated?	Continue	Add gates or refuse autonomy
Can a cheaper non-agent meet the SLA?	Prefer non-agent	Agent with bounds

FAQs

Is every system that calls tools an agent?

No.

A single predetermined tool call from an LLM is tool-using chat.

An agent typically loops: observe results, decide again, act again, until a stop condition.

Can an agent still be the right choice if most runs follow one path?

Yes, if the long tail of branches is expensive to encode and rare cases matter.

Measure how often the long tail appears before paying agent complexity forever.

How detailed should the out-of-scope list be?

Detailed enough that a new engineer would not grant a dangerous tool "just in case."

Name systems and action types, not only vague "be careful" language.

What if stakeholders demand an agent for marketing reasons?

Ship agent UX if needed, but implement a bounded workflow underneath when the path is fixed.

Do not accept unbounded loops to satisfy a label.

How do scope rules interact with stopping rules?

Scope defines what "done" means; stopping rules enforce exit when done, failed, or timed out.

Without scope, stop checks have nothing crisp to evaluate.

Is RAG alone enough to call a product an agent?

Usually no.

Retrieval-augmented answering is often a single-shot or short pipeline unless it also plans multi-step tool use.

When is a workflow builder (n8n, Zapier, graphs) better than an agent loop?

When steps and branches are known, need reliability, and should be edited by operators without prompt archaeology.

How should we scope coding agents versus business agents?

Same fit rules: checkable goals, tool necessity, reversibility.

Coding agents often have strong oracles (tests); business agents need explicit success checks you invent.

What is a good first agent scope for a team new to agents?

Read-heavy, low-blast-radius tasks with clear done checks: ticket triage suggestions, internal research drafts, or test-failure summarization - not unsupervised prod changes.

Can scope change mid-run?

Only through an explicit replan or human approval.

Silent scope expansion is how agents wander into unrelated tools and data.

How do I document a "not an agent" decision?

One paragraph: problem, why path is fixed, chosen non-agent shape, revisit trigger if branches explode.

Do scope rules apply to personal agents with shell access?

Especially yes.

Personal shell agents have high blast radius; start read-only and allowlist commands.

Why Fundamentals Rules Prevent Early Agent Project Failures - why scope is the first bound.
The Core Agent Fundamentals Rules: A Quick-Reference List - condensed row form of these rules.
Stopping-Condition Rules Every Agent Must Implement - exits once scope defines done.
Common Fundamentals Mistakes New Agent Builders Make - mis-scope patterns to avoid.
AI Agent Fundamentals Rules Best Practices - checklist including scope items.

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Scope Rules: When a Problem Actually Needs an Agent

Search Documentation

Scope Rules: When a Problem Actually Needs an Agent