This guide is for CTOs, founders and product owners preparing an agent project for an outside team. OutsourcingVN is operated by Netbase JSC, which builds AI agents and workflows, so it is written by a supplier; the scope it describes protects the buyer whoever does the build. It is a spoke of the AI agent development services guide, which covers the whole engagement, and of the AI workflow automation buyer's guide.
Contents
- Why does an agent project need a different scope?
- How do you scope an AI agent project, step by step?
- What goes on an agent scope sheet?
- What does a worked agent scope look like?
- Which mistakes make agent estimates unreliable?
- How does Netbase take a scoped agent into delivery?
- How this guide is sourced
- Common questions
- Bring your first task
Why does an agent project need a different scope?
An ordinary software scope describes features and screens. An agent scope has to describe behaviour that the model chooses at run time. Anthropic's "Building effective agents" defines agents as systems where the model dynamically directs its own process and tool use, which means the scope cannot list every path; it has to bound the paths instead. It also warns that the autonomous nature of agents means higher costs and the potential for compounding errors.
Three consequences follow. The scope must name what the agent may touch, not only what it should produce. It must define success with test cases, because two runs on the same input can take different routes. And it must say where the agent stops, because an agent that keeps trying can spend money and make changes long after a person would have asked for help. If the task does not actually need that freedom, the agent versus workflow automation guide shows how to scope a fixed workflow instead, which is simpler to estimate.
How do you scope an AI agent project, step by step?
-
Write the task as one job
One sentence a new employee would understand: "Answer order-status enquiries from the support inbox and draft a reply." If the sentence needs "and also", split it into two agents or two phases.
-
Draw the boundaries
List what the agent must never do, the systems out of reach, the customer groups excluded and the work deferred to a later phase. The software project scope boundaries guide shows how to write each edge with an owner.
-
Map tools and permissions
For each tool, record what it reads or changes, the account it runs under and whether a person must confirm. OWASP's LLM06 entry advises limiting the extensions an agent may call, and the permissions they hold, to the minimum necessary; the tool permissions guide has a full template.
-
Collect the evaluation cases
Take real, unselected cases from history, including awkward ones, and write the expected outcome for each. AI workflow evaluation and testing explains how to size and maintain that set.
-
Place human checkpoints
Decide which actions need approval before they happen, which are reviewed afterwards and which are sampled. OWASP advises requiring a person to approve high-impact actions before they are taken; human-in-the-loop AI workflows covers queue design.
-
Set stopping conditions
Anthropic's guide describes agents pausing for human feedback at checkpoints or when they meet blockers, and stopping conditions such as a maximum number of iterations. Write the limits: steps per task, tool calls, time and what happens on each limit.
-
Agree acceptance
State the thresholds on the evaluation set, the operating checks and who signs. The software acceptance criteria method applies unchanged: one criterion per behaviour, evidence and a named decision-maker.
(opens the full-size diagram in a new tab)
What goes on an agent scope sheet?
The scope sheet is the single page a supplier estimates from. Each row is a decision the buyer owns; leaving one blank moves that decision to the supplier, usually at the worst moment.
| Scope item | Written as | Fits when you can answer |
|---|---|---|
| Task | One sentence, one job | Who does it today, and how often |
| Inputs | Channels, file types, systems read | Where each input comes from |
| Outputs | Drafts, records changed, messages sent | Who receives each output |
| Exclusions | Actions, systems and cases out of scope | What would cause harm if done |
| Tools | Name, scope, account, consent rule | Which system enforces each limit |
| Evaluation set | Real cases with expected outcomes | Who labels them and how many exist |
| Checkpoints | Before, after or sampled review per action | Who reviews, and how fast |
| Stop rules | Step, call and time limits, and escalation | Who is told when the agent stops |
| Acceptance | Thresholds, operating checks, signer | Who can say no |
What does a worked agent scope look like?
A mid-sized distributor wants an agent for supplier invoice queries. The example is illustrative and describes no client.
The first request reads: "An AI agent that handles all supplier emails." Scoping narrows it. The task becomes "answer supplier questions about invoice payment status and request missing documents". Exclusions are written down: the agent never changes bank details, never promises a payment date and never answers disputes, which go to a named accounts person. Tools are a read-only lookup of invoice status through the finance user's own role, a document request template and a draft-reply tool; there is no send tool in the first phase.
The evaluation set is 150 real emails from the last quarter, labelled by the accounts team, including disputes and fraud attempts that ask to change bank details. Checkpoints: every draft is reviewed before sending in phase one, and sampled review is considered only after the thresholds hold for a month. Stop rules: five tool calls per email, then escalate. Acceptance: an agreed proportion of drafts sent unchanged or with minor edits, zero bank-detail changes, and every dispute routed to a person.
That sheet is something a supplier can estimate and a buyer can test. "All supplier emails" was neither.
Which mistakes make agent estimates unreliable?
- Scope by demo. A prompt that worked on five examples is treated as the specification; the evaluation set arrives after the contract, and so does the disagreement.
- Permissions left to the build. Nobody decides which account the agent runs under until integration, when the only account available is an administrator's.
- No exclusions. The agent is never told what it must not do, so the edge cases are discovered in production.
- Checkpoints everywhere. Every read requires approval, reviewers stop reading, and the checkpoints that matter lose their value.
- No owner for stopping. The agent hits a limit and nobody is notified, so tasks silently fail.
Before approval, the AI workflow governance questions add the organisational side: who owns the agent, what record it leaves and how it is switched off.
How does Netbase take a scoped agent into delivery?
Netbase's delivery lifecycle runs discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. A scope sheet like the one above is the output of the discovery step and the input to the milestones that follow.
Agent work touches business systems, so the engineering controls matter as much as the scope. Security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
How this guide is sourced
The agent definition, the cost and compounding-error warning, checkpoints and stopping conditions come from Anthropic's "Building effective agents". The minimum-extensions, minimum-permissions and human-approval advice comes from OWASP LLM06 (2025 edition). Netbase statements are approved claim-register entries, reviewed as the methodology describes. The distributor example is illustrative.
Plan the next step for your project
Common questions
Detailed enough that each row of the scope sheet has an answer or a named owner. Blank rows can be filled in a paid discovery, but the estimate should say which rows were blank.
Yes, through the same change process as any project: a new tool, a new action or a new channel updates the permission map, the evaluation set and the estimate together.
Enough real cases to cover the common paths and the known risky ones. Size depends on the task; the cases should come from history rather than be written to pass.
The person who owns the business task today, with security and the system owners signing the permission map.
When the tools touch live systems, usually yes. The AI Workflow Blueprint is a scoped engagement that produces the scope sheet, permission map and test plan before build.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed after it.
Bring your first task
If you are deciding whether to build or buy an agent for order, catalogue or support work, the build versus buy guide for ecommerce operations agents applies this scope to packaged tools as well. AI Workflow Automation is the service that builds the agent once the scope is agreed.
OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with the task in one sentence and the systems it would touch, and a person will reply with the scope questions still open.
Related services and solutions
AI workflow automation with evaluation and human control
One operating workflow automated, with an agreed way to judge it and a person on uncertain cases.
Learn More