# The work should decide where AI belongs > A practical way to assess a workflow before choosing an automation, agent, or model. Published: 2026-07-14 Updated: 2026-07-14 Category: Assessment AI projects often begin with a tool: a model someone wants to try, an agent a team has seen demonstrated, or an automation platform that promises a quick result. That is understandable. Tools are visible. The operating work they are meant to improve is usually scattered across inboxes, spreadsheets, calls, and unwritten judgment. But starting with the tool reverses the decision. The useful question is not *Where can we put AI?* It is *What work needs to become more reliable, and what kind of system would improve it?* ## Start with the operating work A workflow is more than its happy path. It includes who starts it, what information arrives, which decisions are routine, where judgment is required, and what happens when something is incomplete or wrong. Before choosing a system, map five things: 1. **The trigger.** What event starts the work—a form, a call, a new lead, a request, or a scheduled review? 2. **The inputs.** What information must be present, and which sources are approved? 3. **The decisions.** Which choices follow stable rules, and which depend on context or accountability? 4. **The handoffs.** Where does ownership move from one person or system to another, and is [escalation designed as part of the product](/journal/escalation-is-a-product-feature)? 5. **The exception path.** Who takes over when confidence is low, data is missing, or a boundary is reached? This map creates a much better brief than a list of desired AI features. It also makes the cost of the current process visible: repeated data entry, unanswered requests, long waits, dropped follow-ups, and decisions that arrive without enough context. > A useful AI brief names the work, the boundaries, and the owner of every exception before it names a model. ## Choose the smallest system that closes the gap Not every workflow needs an agent. Some need a dependable automation: move validated information, update a record, send the next message, and notify a person when a rule is not met. An agent becomes useful when the work includes an interaction—answering a call, asking follow-up questions, finding an approved answer, or gathering enough information for a person to decide. Even then, the agent is one part of an operating system. It still needs permissions, sources, records, monitoring, and an escalation path. The same principle applies across the common ways [generative AI supports business operations](/journal/generative-ai-for-business-operations). Sometimes the right answer is not to build yet. If the process changes every week, ownership is unclear, or no one agrees on what a good outcome means, adding AI can make the confusion move faster. The first improvement may be to simplify the process and define the decision rights. ## Assess frequency, consequence, and variability Three dimensions help determine whether a workflow is ready. ### Frequency Work that happens often creates enough evidence to design and improve against. A task performed twice a year may be important, but it rarely provides the volume needed to justify a dedicated system. ### Consequence The cost of a wrong action determines how much control is required. A mistaken internal tag is different from an incorrect customer commitment. Higher-consequence work needs narrower permissions, stronger review, and faster human takeover. ### Variability Stable inputs and repeatable decisions are easier to automate. Highly variable work may still benefit from AI, but the role may be to prepare, summarize, or recommend rather than act. Together, these dimensions lead to a practical allocation of responsibility: - Let the system handle frequent, low-consequence, repeatable steps. - Let it prepare information for variable or higher-consequence decisions. - Keep people responsible for judgment, approval, and exceptions. ## Define evidence before implementation A project is easier to govern when the proof of value is agreed in advance. That proof should describe an operating result, not a model score alone, and it should connect directly to [what the team will measure after launch](/journal/what-to-measure-after-launch). Useful measures might include response time, completion rate, qualified handoffs, exception volume, correction rate, and the amount of manual work removed without reducing service quality. Each measure should have an owner and a baseline. This matters because a technically impressive system can still fail operationally. It may answer quickly but create more cleanup. It may complete tasks but route the hardest cases poorly. It may save time for one team while adding review work for another. ## The decision comes before the build Assessment is not a delay added to an AI project. It is the stage that makes a responsible build possible. It identifies where the system can act, where a person must stay involved, and what evidence will justify widening—or tightening—its autonomy after launch. When the work decides where AI belongs, the result is usually smaller, clearer, and easier to operate. That is a strength. The goal is not to place AI everywhere. The goal is to build a system people can rely on where the work actually needs it.