A decision guide
Choosing your first AI agent use case
A focused exercise for choosing a first project your team can own, evaluate and operate.
Choose a responsibility small enough to understand
“Automate customer operations” is an ambition. “Prepare a draft response using these approved documents for this group of requests” is a starting scope. The second statement gives a team something it can observe, test and discuss.
A first project should create learning that helps the next decision. It needs enough real work to be meaningful and a boundary clear enough to recognise when the system has succeeded or failed.
Use five questions to compare the candidates
- Who owns the work? Identify a person who can explain normal cases, review exceptions and decide whether the result is useful.
- What starts and ends the task? Name the incoming event and the completed output. Avoid a scope that continues indefinitely across unrelated responsibilities.
- Is the necessary information available? Check actual access, permissions, quality and update ownership.
- What happens when the result is wrong? Identify review points and choose an initial boundary that the team can supervise.
- How will you evaluate it? Gather examples, agree the expected behaviour and compare the result with the current process.
Write a one-page use-case brief
Keep the brief concise enough that the process owner, a technical colleague and a reviewer can discuss the same document. Include the task, users, input sources, intended output, permitted actions and the main open questions.
| Brief field | Illustrative example |
|---|---|
| Task | Prepare a response draft to a product-support question. |
| Knowledge | The approved product guide and maintained support notes. |
| Action boundary | Draft only; a support colleague reviews and sends. |
| Exception | Ask for clarification when the product version is missing. |
| Evaluation | Review representative questions for correctness, evidence and useful handling of uncertainty. |
This example illustrates a scoping method. It is not a reported customer result.
Identify the work outside the AI component
The brief may reveal that source documents need an owner, record identifiers need to be consistent or access must be arranged. Put that work into the plan. Otherwise it can appear late as an unexpected dependency and make the pilot difficult to interpret.
Also identify who will use the output. A technically correct result that arrives in the wrong place or requires extra copying may not improve the workflow. The user journey is part of the use case.
Agree what the pilot should decide
Before implementation, write down the possible next steps. Evidence might justify a broader release, a smaller task, better source preparation or a different approach. Define who makes that decision and which observations they need.
Avoid committing to a fixed benefit before the baseline and scope are understood. Instead, establish which measures would be useful for this process: review effort, completion quality, exception frequency or time to a usable result.
Bring the brief to a discussion
If your team has several candidates, Open for AI consulting can help compare them and shape the first scope. If a task is already well defined, explore custom agent development.
Continue with From prototype to a business workflow to consider the operating requirements of a release.