The short answer
Choose a business process for an AI agent when the work repeats, depends on judgment or unstructured information, has a clear owner, and can be tested against a known good result. Start with one bounded decision path. If you cannot define success, inputs, permissions, and escalation, the process is not ready yet.
Which process is actually worth turning into an agent?
The best first process is rarely the biggest one. It is the smallest recurring unit of work where better execution changes an operating result. Think about qualifying an inbound request, reviewing a document before approval, preparing a weekly exception report, or routing a support case. Each has a beginning, a useful outcome, and a point where a person can inspect the result.
OpenAI's practical guide recommends agents for workflows where deterministic automation struggles, especially complex decisions, difficult rule sets, and heavy use of unstructured data. That is a useful boundary. If the job is a fixed sequence with stable rules, ordinary software or a workflow automation may be cheaper, faster, and easier to audit. Calling every automation an agent only makes the system harder to operate.
My filter is direct: an agent should absorb judgment-shaped work, not vague responsibility. 'Handle customer success' is vague responsibility. 'Read a renewal request, collect the account facts, identify the policy exception, draft a recommendation, and stop for approval' is a process. The second version gives you something you can test.
Does the workflow repeat often enough to teach you anything?
Frequency matters because every run creates evidence. A task that happens once a year may still be valuable, but it is a poor first build if you cannot collect examples, observe failures, or improve the instructions quickly. A weekly process gives you feedback. A daily process gives you more. Volume alone is not the point; the point is whether enough comparable cases exist to learn what good execution looks like.
Look for repeated inputs, repeated decisions, and repeated corrections. If an operator keeps rewriting the same type of response, checking the same fields, or applying the same exceptions, there is probably a workflow hiding inside the habit. The useful artifact is not a polished process diagram. It is a set of real cases showing what changed the decision and why.
Do not start by asking employees what they do in general. Ask for the last five times they completed the task. Compare the inputs, actions, exceptions, and final outcomes. General descriptions hide judgment. Specific cases expose it.
Can you name the decision, the inputs, and the stopping point?
A process becomes buildable when you can state four things without hand-waving: what starts the work, what information is available, what decision or action must happen, and what ends the run. Missing any one of those creates an agent that keeps asking for context, acts on incomplete information, or never knows when it is done.
Anthropic separates predefined workflows from agents that dynamically direct their own tool use. It also recommends starting with the simplest solution that works because agentic systems trade additional cost and latency for flexibility. That distinction matters before you buy or build anything. You may need a fixed workflow with one language-model step, not an autonomous agent.
Write the process in one sentence: 'When X arrives, use A and B to decide Y, take action Z within these limits, then record the result or escalate.' If the sentence needs five different outcomes and twelve systems, split it. A narrow process is not less ambitious. It is the only version you can accept or reject with confidence.
Where should a human keep control?
Choose the approval boundary before choosing the model. An agent that gathers facts, compares policy, and drafts a recommendation has a different risk profile from one that issues a refund, changes a customer record, or sends a message. The technical demo may look similar. The operating consequence is not.
NIST's AI Risk Management Framework organizes risk work around governing, mapping, measuring, and managing. For a first business agent, that translates into practical questions: who owns the process, who can change its rules, how performance is measured, which failures matter, and what happens when confidence is low. Governance is not a document you add after deployment. It is part of the workflow design.
Keep approval where an error creates money movement, legal commitment, customer harm, irreversible data change, or a promise made in the company's name. Let the agent prepare the decision first. Once its evidence is consistently good, you can expand permissions one action at a time. Autonomy should be earned by observed behavior, not granted because a model looked impressive in a demo.
What evidence proves the process is ready?
A workflow is ready for a first implementation when you have real examples, a responsible owner, accessible inputs, explicit exceptions, and an acceptance test. The acceptance test can be simple: given these twenty historical cases, does the system collect the right facts, choose the permitted path, cite the evidence it used, and escalate the cases that fall outside policy?
Do not measure readiness by whether the agent produces fluent text. Fluency is cheap. Measure whether it reaches the right operating state without skipping required checks or taking an unauthorized action. A useful test set includes normal cases, edge cases, incomplete inputs, conflicting instructions, and at least one case where the correct result is to stop.
This is also where company knowledge becomes concrete. Policies, examples, product details, and operator judgment should be connected to specific decisions. Uploading a folder of documents is not training an agent on the business. The system needs to know which source governs which step, how current it is, and what to do when sources disagree.
A practical scorecard for your first candidate
Score each candidate from zero to two on six questions: does it recur; does it consume meaningful operator time; does it use judgment or unstructured information; can you access representative cases; can you bound its permissions; and can one person own the outcome? A strong candidate scores at least nine and has no zero on ownership, evidence, or permissions.
Then apply one veto question: would a deterministic rule or ordinary integration solve the problem cleanly? If yes, use that. Agents are useful when the process needs interpretation, contextual judgment, or flexible tool selection. They are not a prize for choosing the most sophisticated architecture.
Finally, estimate the cost of a wrong answer before the value of a correct one. Low-consequence preparation work is a better first deployment than high-consequence execution. Research, triage, reconciliation, and draft preparation often create value while keeping a person at the final boundary.
What should you avoid automating first?
Avoid processes with no stable owner, no examples, constantly changing policy, inaccessible source data, or outcomes that nobody reviews. The agent will not fix operational ambiguity. It will execute the ambiguity faster and make responsibility harder to locate.
Also avoid broad roles disguised as workflows. 'Be my AI employee' is not a scope. Neither is 'run sales' or 'manage operations.' A role contains many processes with different data, permissions, failure costs, and acceptance tests. Pick one process, expose its decisions, and connect only the tools required for that process.
Do not automate a broken handoff just because it is repetitive. If two teams disagree about who owns the handoff, settle that first. Software can route work. It cannot create accountability that the company refuses to define.
Limitations
This selection method does not prove that an agent will create positive return. It identifies a process that can be implemented and evaluated without hiding the operating risk. You still need to measure cycle time, correction rate, escalation quality, operator effort, and the business outcome that justified the work.
The scorecard also favors processes with observable history. New workflows, rare investigations, and high-value strategic decisions may deserve AI support, but they need a different validation plan and tighter human control. Some work should remain advisory because the cost of independent action is too high.
One more limit: source quality becomes system quality. If policies conflict, records are stale, or examples encode bad decisions, a capable model can still produce the wrong operating result. Clean ownership and current knowledge are not setup chores. They are part of the product.
Turn one process into a buildable map
The next step is not choosing a vendor. Take one candidate and map its trigger, inputs, decisions, exceptions, tools, approval boundary, final record, and acceptance cases. That map tells you whether you need a fixed automation, a model-assisted workflow, or an agent with controlled tool access.
This is the builder judgment most teams skip. The model is replaceable. A clear process, usable company knowledge, explicit permissions, and tests tied to real work are the assets that survive model changes. Start there, and the technology choice becomes much less dramatic.