Choose the first website Agent task by comparing a few candidates, then select one that has a clear source, an accountable owner, limited permissions, and a test you can judge. The aim is not to automate the biggest-sounding business process. It is to choose a specific visitor need you can define and verify before you expand the scope.
This guide is a pre-build decision worksheet, not a full deployment checklist. Its examples are illustrative planning exercises, not customer stories or measured results. For a broader discussion of what distinguishes Agents and chatbots, see AI Agent vs Chatbot.
Step 1: Write down candidate tasks
List two or three specific visitor needs. Describe what the visitor wants, rather than beginning with a broad goal such as “automate support” or “increase sales.”
Possible retail candidates include explaining a published return policy or answering general questions about a product category. Possible service-business candidates include explaining what to prepare for an initial consultation or telling visitors what information to include in a service request. Treat these as prompts, not recommendations: your own visitor questions and approved business information should determine the candidates.
Write each candidate as a short sentence:
- Visitor need: What is the person trying to find out or do?
- Possible Agent task: What single response or next step might help?
- Boundary: What related request would be outside this task?
For example, “Explain the published return policy” is narrower than “resolve return problems.” The broader phrase might cover an explanation, an order-specific eligibility decision, or an exception request. Those cases could require different information or permissions. Keep them separate while comparing candidates.
Step 2: Compare candidates with readiness gates
Use the worksheet below for each candidate. Mark each item ready, not ready, or unclear. These labels are a planning method, not a product score.
| Check | Ready means you can name… | If not ready |
|---|---|---|
| Visitor need | One recognizable question or request | Narrow the task or collect examples of the questions people ask |
| Source | The approved page, policy, or dataset that supports the answer | Find, approve, or complete the source before selecting this task |
| Source owner | A person or role responsible for checking that source | Assign an owner who can maintain it |
| Permission boundary | What the Agent may explain, ask, or initiate, and what it must not decide | Reduce the task to an explanation or a clearly bounded next step |
| Acceptance test | Questions to ask and a standard for judging each response | Write the expected answers and pass conditions first |
| Human route | The person or team for requests outside the task | Decide who should take those requests |
A useful selection rule is to prioritize a candidate with fewer unclear answers, not one that sounds more ambitious. If a task depends on a source you cannot identify, or an action you cannot authorize, mark it not ready and compare another candidate. That is a reason to defer the task, not to let the Agent fill in missing business rules.
Step 3: Name the source and its owner
For each candidate, write down exactly what information supports the answer. A retail policy explanation might rely on the current returns policy. A service-preparation answer might rely on an approved checklist or service description. Then name the person or role who checks that information when the business changes.
Do not treat a file attachment as proof that its contents are ready to answer questions. Attaching a file does not prove its contents have been indexed. A source must finish processing before its content can be used in answers. If you plan to rely on uploaded material, make source readiness part of your selection check. The knowledge base feature is a starting point for reviewing source options.
If a candidate requires exact totals from structured data, state which dataset and calculation the task depends on. Supported indexed spreadsheet and database datasets can be filtered, sorted, counted and aggregated over their complete saved rows. Incomplete row coverage is rejected instead of returning an exact total from partial data. A task that asks for a total needs a different acceptance test from one that explains a policy. The worksheet in four checks before your Agent answers from a spreadsheet offers additional prompts for that kind of evaluation.
Step 4: Separate explaining from acting
For every candidate, complete these two lines:
- May: What is the Agent allowed to explain, ask, or direct the visitor to do?
- Must not: What decision, promise, approval, or change is outside the task?
For a retail policy task, a possible boundary is “may explain the published policy; must not approve an exception.” For a service-business preparation task, it might be “may list the information requested in the checklist; must not promise a price or appointment.” These are examples to adapt to your actual rules.
Use a smaller scope if you cannot describe the permission clearly. For example, explaining how to request a return is different from deciding whether a particular order qualifies. If eligibility depends on individual order information or business judgment that the Agent cannot reliably access or apply, leave that decision with staff. Similarly, describing what information helps prepare a quote is not the same as calculating or guaranteeing one.
This step is about your business policy as much as your Agent setup. Before selecting a task that involves an action, confirm that your actual tools and process support it and decide what confirmation or human review is required. Do not infer that a website chat installation connects to business systems or grants permission to take an action.
Step 5: Build a small acceptance test
Write down the expected response before you try the candidate. Test at least three kinds of question:
- In-scope question: A straightforward request the source should answer.
- Incomplete question: A request missing a detail that matters to the answer.
- Out-of-scope request: A request that tests a permission boundary or asks for information the source does not provide.
For each, record the question, the answer or behavior you expect, and what would count as a failure. A retail policy test might check whether the response matches the approved policy and whether a request for an exception stays outside the Agent’s authority. A service-preparation test might check whether the response lists only details found in the approved checklist and avoids promising a quote when none is stated.
Use the same prompts when you review a correction. If the response fails, record whether the problem is the source, the task boundary, or the instruction. For more guidance on checking questions that go beyond the available information, see what your Agent should say when its knowledge has no answer.
Worked worksheet: choose between two retail candidates
This is an illustrative planning exercise, not a report about a real shop. Imagine a retailer comparing these tasks:
- Candidate A: Explain the published return policy. Source: the current policy. Owner: the role responsible for maintaining that policy. Permission: explain the policy, but do not approve exceptions. Test: ask a routine policy question and an exception request; check that answers follow the policy and do not approve the exception.
- Candidate B: Decide whether a particular order qualifies for a return. Source: order-specific details and the business’s eligibility rules. Owner: the role that handles return decisions. Permission: make or withhold an eligibility decision. Test: provide cases with different order details and compare each decision with the business’s rules.
The selection question is not “Which task could be more valuable?” It is “Can we name and verify the information, permission, owner, and pass condition for this task now?” If Candidate B lacks an approved way to access the needed information or an authorized decision rule, mark it not ready. Candidate A may be the clearer first candidate if its policy source, owner, and test are all defined. That is a decision based on the worksheet assumptions, not a claim about what every retailer should choose.
Copy-ready decision worksheet
Complete this once per candidate, then select one:
- Candidate task:
- Visitor need:
- Included questions or requests:
- Excluded questions or requests:
- Approved source:
- Source owner:
- May explain, ask, or initiate:
- Must not decide, promise, approve, or change:
- Human route for excluded requests:
- Test questions:
- Expected response or behavior for each test:
- Pass standard:
- Unresolved issue, if any:
- Decision: Select / Defer
After you select a task, keep its acceptance standard visible during setup. Owners can ask the Architect to change wording in Agent instructions in conversation. Those instruction changes remain drafts until the owner publishes them. Recheck the affected tests after an instruction change; do not confuse revised wording with a corrected or updated source.
Make one decision before expanding scope
Choose one candidate only when you can state its visitor need, source and source owner, action limits, human route, and acceptance test. If one of those is still unclear, defer that candidate or reduce its scope. Once the chosen task meets your written standard, use what you learn to decide whether a separate task is ready for its own review.
A completed first-task decision
For a fictional furniture shop, compare “explain care instructions” with “change a delivery address.” Care instructions have a public source, one content owner, and no account write. Address changes need customer verification, an order connection, and an authorized operator for exceptions. Choose care instructions for the first release while the second integration is built.
Record the decision as: source owner, shop manager; source, approved care sheet; release questions, wood finish, cleaning product, and an absent material; escalation, damaged items. The buyer guide helps compare tools for this job, and the ecommerce guide separates catalog answers from order operations.