How to Scope an AI Agent Project

A workable AI agent scope identifies one business outcome, the decisions required to reach it and the authority the system receives. “Build an agent for our leasing team” is a direction. “Prepare an evidence-linked response to a commercial property enquiry using approved availability and policy data, with a leasing manager approving commercial commitments” is a scope that can be investigated.

This guide is for business sponsors, product owners and delivery partners deciding what belongs in the first release. It uses an illustrative commercial leasing enquiry assistant. The goal is to produce a boundary document that a buyer, engineer and operational reviewer interpret the same way, before estimating effort or selecting a platform.

Find a complete unit of value

A scope should be small, but it must still complete something useful. “Summarise enquiries” may be too small if staff must reopen every attachment to know what to do next. “Handle all leasing” is too broad because it combines interpretation, availability, negotiation, contract preparation and external commitments.

For the example, choose the unit “prepare a review-ready enquiry response”. It begins when an authorised team receives an enquiry. It ends when a reviewer has a draft containing the customer's stated needs, supported property options, missing information and evidence references. Sending the response or reserving a unit is outside this first boundary.

Specify the receiving role. A senior leasing manager can interpret a nuanced recommendation differently from a new coordinator. The same output may be useful to one and unsafe for the other. If several roles need different workflows, identify one initial user group instead of describing everyone as an undifferentiated user.

Separate the outcome from the proposed mechanism

Write the desired improvement without mentioning a model: reduce the effort required to assemble a justified response while preserving review quality. Then list the work that creates that effort. Some delays may come from an outdated availability spreadsheet, unclear pricing ownership or missing enquiry fields. An agent cannot solve the underlying ownership problem by writing more confidently.

Compare the scope with better search, a structured intake form and fixed rules. The meaningful question is whether variable language, ambiguous requests or evidence selection create enough work to justify model-directed behaviour. Use the automation comparison when a deterministic solution remains plausible.

A scope can also combine approaches. A form captures required contact details, ordinary code filters unavailable units, and a model interprets narrative preferences. This separation makes the uncertain component testable and prevents the agent label from absorbing every requirement in the surrounding application.

Draw the authority boundary explicitly

List verbs rather than features. Reading, comparing, recommending, drafting, saving, notifying, reserving and changing prices have different consequences. “Integrates with CRM” does not reveal whether the system may read an enquiry, overwrite customer data or contact a prospect.

For every permitted action, identify the actor, target, conditions and evidence of success. A draft may be saved to a designated review area. A reservation requires a different authorisation path. Do not grant broad write access merely because it is convenient during development; authority should follow the agreed task.

Also define when the agent must stop. Conflicting availability records, a request outside the supported property portfolio or a price concession should trigger a specific handoff. “Escalate when unsure” is insufficient unless the team knows who receives the case, what information accompanies it and what the user sees while waiting.

Use a scope boundary sheet

The following illustrative sheet can be adapted during a scoping workshop. It records a decision, not an assertion that the corresponding integration already exists.

Boundary sheet for a commercial leasing enquiry assistant

Dimension	First-release boundary	Excluded or deferred
Entry point	Enquiries assigned to the commercial leasing review queue	Unsolicited monitoring of all staff communications
Customer need	Extract stated location, area, intended use and timing	Infer unstated budget or identity characteristics
Evidence	Approved availability, permitted property records and current response policy	Unverified listings treated as authoritative stock
Decision	Rank supported options with reasons and missing information	Promise suitability, negotiate terms or decide legal eligibility
Action	Save a draft and evidence links for the assigned reviewer	Send offers, reserve premises or change commercial terms
Completion	Reviewer can accept, amend or reject a traceable draft	Assume acceptance because a draft was generated

Keep an adjacent assumption register. For example, “availability data includes an update timestamp” is an assumption until inspected. “The system must reject stale availability” is a requirement. Confusing the two can produce an apparently complete scope whose critical dependency has never been verified.

Make the data boundary as precise as the action boundary

Name the source owner, access route, permitted fields, refresh mechanism and relevance to the task. A folder called “property data” may contain withdrawn listings, old price sheets and material restricted to another team. The scope must distinguish approved sources from everything that happens to be accessible.

Specify the identity used for retrieval and whether results depend on the individual user's permissions. Decide whether uploaded attachments are retained, how long case state persists and how corrections propagate. These are scoping decisions even if specialists later implement the detailed controls. Data residency or regulatory requirements should be assessed for the actual organisation and processing arrangement, not inferred from an Arabic interface.

For multilingual work, describe the input and output combinations: Arabic enquiry with English property records, English enquiry requiring an Arabic draft, or mixed-language attachments. “Supports Arabic” does not define whether names, areas, dates and technical terminology must survive translation unchanged. The requirements checklist turns these boundaries into verifiable obligations.

Define success with denominators and exceptions

A useful acceptance statement names the population. For example: “For the agreed supported enquiry categories, reviewers can identify the source for each proposed property attribute and any unsupported field is marked for clarification.” This is more testable than “provide accurate recommendations”.

Define how cases enter the evaluation sample and which categories remain excluded. Count all assigned cases when reporting completion, including cases escalated because evidence is missing. Record a separate quality measure for completed drafts. Otherwise, a system can improve its apparent accuracy simply by refusing difficult work.

Measure the review process rather than assuming automation equals saved time. Include reading, checking, correction and handoff effort. Compare against the same task done without the agent, with similar case complexity. Savings remain a hypothesis until observed; an illustrative business case must not be presented as a delivered result.

Set a launch-blocking rule for consequential errors separately from ordinary quality targets. A request for evidence clarification is different from exposing another customer's information. The evaluation guide explains how to preserve that distinction in the test set and report.

Expose dependencies before estimating

List the decisions and access that another team must supply. In the leasing example, the property team owns availability, commercial leadership approves response wording, IT controls the source connection and operations assigns reviewers. Give each dependency a named owner and a date for resolving the uncertainty, without treating that date as guaranteed delivery.

Separate an integration that has documentation from an integration that has been exercised with permitted credentials and realistic records. Confirm the available test environment, rate limits, error responses and support contact. A read-only pilot may be viable while write access is unresolved, but that is a deliberate scope choice rather than a hidden shortcut.

Use the timeline framework to model the dependency chain after the boundary is agreed. Estimating an undefined agent usually produces a number that conceals assumptions instead of helping a buyer decide.

Control changes by what they alter

Not all additions are equal. Supporting another property description format may expand data coverage. Sending a draft automatically expands authority. Adding a second business unit may change access boundaries and operating ownership. Assess the changed risk and evidence requirement, not just the amount of interface work.

A practical change record contains the requested behaviour, affected users and systems, new failure modes, revised acceptance cases, owner and effect on delivery. Preserve the original scope so the team can explain why estimates changed. Avoid labelling consequential additions as “small enhancements” before their effect is understood.

Close the scoping stage with unresolved questions visible. A sound scope can contain a bounded investigation, such as checking whether availability freshness is reliable enough for the proposed response. It should not claim certainty where the evidence is absent. The project brief template provides a format for handing the agreed boundary to prospective delivery teams.

Resolve disagreement with contrasting cases

Before signing off, ask each stakeholder to classify a small set of boundary cases independently. One enquiry asks for a unit already listed as available. Another requests a concession that has no approved rule. A third names an area ambiguously. A fourth contains a property outside the portfolio. If the sponsor expects automatic responses while the reviewer expects drafts, the disagreement will surface more clearly in cases than in a feature list.

Record the agreed disposition: prepare, clarify, escalate or reject as outside scope. Include the reason and the authority needed to change that disposition. These cases become a compact communication tool for developers, reviewers and suppliers, and can later seed acceptance tests. They also make exclusions understandable to users rather than leaving them as contractual language.

This exercise supports an early proceed-or-pause decision. NIST places a contextual go/no-go decision within its mapping guidance; the cases here are a proposed practical method, not a NIST certification or prescribed checklist. See the AI RMF Core.

Open for AI scopes custom AI agent development around actual workflows and agreed permissions. To review the boundary of a proposed agent project, bring a redacted input, the output a reviewer would accept and a list of actions you currently allow people to perform. That is enough to start separating useful first-release work from later ambitions.