Build an agent when the task is ready for one.
A promising agent project has a recurring task, usable evidence, and a result that someone can check. Work through these questions before choosing a model or expanding the feature list.
By Oğuz Erol
Can you describe the outcome without saying “AI”?
Define the job in business terms. “Prepare a source-linked account brief before a sales meeting” is a useful outcome. “Add an intelligent assistant” leaves the actual responsibility undefined. Name the input, recipient, expected output, and conditions that mean the task is complete.
Choose a first scope that can finish independently. An account brief can be reviewed as a document. Managing all customer communication combines identity, permissions, messaging rules, and commercial decisions before you know whether the first step is useful.
Is interpretation the part that needs help?
Examine the manual work before assigning it to an agent. If people mainly copy structured values between systems, a conventional integration may solve the problem. An agent is more relevant when varied inputs require context, investigation, or a choice between permitted next steps.
For a meeting brief, interpretation might mean separating a confirmed delivery issue from a speculative remark in a note. The system needs a way to preserve that distinction, rather than turning every sentence into an asserted fact.
Are the records and permissions available?
Identify which system owns each important fact. Check that the intended integration can read the required records and that the information may be used for this task. Missing access or unclear record ownership is a project dependency, not something a prompt can repair.
Begin with the smallest useful permissions. A brief-writing agent might read approved account notes and produce a draft without changing the CRM. If later phases require writes, define those operations and their approval requirements separately.
Can someone distinguish a good result from a plausible one?
Collect examples before development: a normal request, a sparse record, conflicting notes, and a case that should be escalated. Write down what a correct output contains and what it must never infer. Review the supporting evidence as well as the final wording.
- Every important claim points to a usable source.
- Unknown values remain unknown.
- The output follows the format its recipient needs.
- The process stops or hands off when evidence or permission is missing.
Who will review exceptions and operate the process?
Assign someone to unresolved cases, access problems, and corrections. Decide how a failed run becomes visible and what information the handoff includes. An unattended process still needs an owner, a pause mechanism, and an agreed recovery route.
Keep the initial review workload explicit. If every output needs extensive rewriting, investigate whether the task, source material, or acceptance criteria need to change before adding more autonomy.
What would justify continuing?
Run a limited pilot against the examples and a small set of new tasks. Compare completed work, review effort, errors, and operating cost with the current process. Measure the whole sequence, including corrections, rather than counting generated answers.
Proceed when the outcome is useful and the remaining risks are understood. Narrow the scope when one step performs well and another does not. Pause when the evidence is unavailable or nobody can own the exceptions. A clear decision to wait can save a project from automating an unresolved process.