article · cross business
When not to use an AI agent
Recognize five situations where an AI agent is a poor first project, choose a concrete alternative, and record what must change before reconsidering.
The direct answer
Do not start with an AI agent when the task lacks a stable purpose, usable information, an accountable owner, or a recoverable outcome. A simpler process can solve the immediate problem and make a later experiment easier to evaluate. Choosing not to build is a valid decision.
A business example
Synthetic example: A small service team wants an agent to handle every request arriving in a shared inbox. The team has conflicting refund instructions, no agreed escalation owner, and only occasional requests for each service. Connecting a model would leave those disagreements unresolved. The useful first project is a current reply library and a named daily reviewer.
This example describes a planning decision, not an observed improvement or a customer result.
Five no-fit situations and alternatives
| Situation | Why an agent is a poor first choice | Concrete alternative | Condition for reconsidering |
|---|---|---|---|
| The work is rare or changes every time | Setup and maintenance may exceed useful recurring work. | Use a written checklist and perform the task manually. | Measure a repeatable task over a defined period. |
| Fixed rules already cover the decisions | Model choices add uncertainty without a demonstrated need. | Use form validation, a template, or ordinary automation. | Identify a specific language task that rules cannot handle adequately. |
| Sources conflict or access is not approved | A fluent answer cannot settle policy or grant permission. | Have an owner approve a small source set and remove unauthorized fields. | Resolve conflicts and document approved access. |
| No one can review or maintain it | Errors and backlogs have no accountable response. | Assign an owner, backup, review time, and manual procedure. | Demonstrate the team can review representative outputs. |
| A wrong action is hard to reverse | Testing a few examples cannot remove the consequence. | Keep the action with a qualified person; trial read-only summaries if appropriate. | Obtain task-specific review and a bounded recovery design. |
Explain what would change the decision
A no-build decision should name the missing condition and its owner. “AI is risky” is too broad to guide work. “The service owner must resolve the conflicting cancellation instructions before any draft can cite them” identifies a useful next action.
Do not turn this table into a score where strengths cancel blockers. A high volume of requests does not compensate for missing access permission. Clear instructions do not compensate for nobody being responsible for failures.
Limits and non-example
An internal draft still requires checks: it can mislead a colleague or expose information to a service that should not receive it. Calling a workflow “human reviewed” does not help if the reviewer lacks the original source or cannot stop an action.
This guide is a first-project filter, not a determination that a task can never use AI. Conditions can change, and specialist review may be necessary for consequential processes.
Make a no-build note
Write the task, the blocking condition, the simpler alternative, the person responsible, and the evidence needed to reconsider. Set a review date only if someone will actually gather that evidence. For the inbox example: use approved reply templates until the policy owner resolves contradictions and the team has measured review capacity.
Sources and scope
This is original editorial planning guidance. The five situations are decision prompts, not a validated assessment or measured failure-rate model. The example is synthetic.
Next step
Complete the challenge library for one task and preserve the decision in the workflow brief. Suggest a correction.
Change notes
Foundation draft prepared October 20, 2026. No public publication or successful live-tool test is claimed.
Next learning step: One-page workflow brief