What Should You Automate With AI? Start With the Workflow, Not the Model

A task demo is not an operational win

AI can turn a rough brief into code, copy, analysis, or a prototype. That proves generation, not a faster product or operations loop. If the customer problem is fuzzy, the handoff changes halfway through, or nobody knows whether the result is acceptable, faster generation just gets you to the wrong answer sooner.

For example, AI drafts a support reply. A person still has to find the account context, check policy, correct the category, send the message, and record the exception. The task got faster. The request did not. The demo simply moved the work downstream.

The practical answer is simple: do not automate the easiest task. Automate the smallest end-to-end workflow whose output you can accept and measure, and whose failures you can recover from.

Building speed and iteration speed are different jobs

A product team does not learn because it produced more artifacts. It learns when a customer signal becomes a decision, the decision becomes a bounded change, the change reaches a user, and the observed result informs the next decision.

Building is one step in that loop. AI can compress research synthesis, option generation, specification, scaffolding, testing, and evidence collection. Product judgment still has to decide which customer problem matters, what tradeoff is acceptable, what scope is worth approving, and what the result actually means.

The same distinction applies to business operations. Generating a response is fast. Resolving the request, recording what happened, routing the exception, and making the next run better is the workflow.

Run the AI Workflow Fit Test before choosing a tool

Repetition and time cost are useful first filters. They are incomplete. They do not tell you whether the whole loop can be owned, reviewed, or recovered when it fails.

The AI Workflow Fit Test is the five-question screen I would use before approving a pilot: user job, workflow friction, AI boundary, acceptance evidence, and business test. If one answer is vague, the workflow is not ready. Tighten it before comparing models or buying another platform.

Choose work that is repeated, bounded, verifiable, and recoverable

Frequency matters because a workflow that rarely runs cannot repay much setup or maintenance. It is not enough. The best first candidate also has a clear boundary, a result that can be checked without redoing all the work, and a failure that can be contained.

The five-question test tells you what to inspect. These four traits tell you how to route the candidate: automate, augment, constrain, or wait.

Build the smallest end-to-end MVP

A quick MVP is not a chatbot beside the workflow. It is the thinnest complete path from a real trigger to an accepted business result. The goal is to learn whether the operating loop works before you add autonomy, integrations, or scale.

For the first version, I would constrain it to one request type, one source of context, one AI action, one reviewer, one accepted output, and one durable record. That is narrow enough to keep a failure cheap and visible while still exposing the real design problems.

A real workflow can reject the work

I use the same pattern in the system behind this site. A rough article request does not go straight into drafting. It gets one discovery outcome, one business outcome, a search-intent decision, an authority check, a bounded brief, an editorial review, visual QA, and a durable publication record.

One planned article stopped before the draft because the point was broad and the proof was weak. That was the workflow doing its job. A system that can only generate has no way to protect the business from confident waste.

This does not prove that the same design will improve every process. It demonstrates the mechanism: explicit ownership, observable gates, a reject state, and enough recorded evidence to make the next decision.

The right boundary changes with the workflow

The framework stays the same across a solo business, a product team, and an operations function. The ownership line does not. These three scenarios show where I would start and what I would keep human.

Measure accepted work, not generated output

Prompts sent, drafts generated, and hours spent inside an AI tool are activity metrics. They can rise while the workflow gets worse. The useful unit is accepted work that moves the next decision or customer outcome.

Set a small baseline before the pilot, then compare the same workflow after it. You do not need a perfect ROI model to learn. You need a stable unit, a visible review burden, and a stopping rule.

Do not automate yet if nobody can own the result

Some workflows should wait. If the process changes every week, the quality bar lives in one person's head, or nobody owns the exceptions, automation will create a faster argument instead of a better system.

Use AI as decision support while you clarify the process. Ask it to organize evidence, surface options, or prepare a review. Keep the consequential action human until the workflow earns more ownership.