Before you buy a model or connector, decide what should disappear, stay human, require approval, or stop.

Most AI automation projects begin with the wrong question.

Someone asks which model to use. Then come the connector, the prompt, the demo, and eventually a workflow that moves faster while producing the same confusion as before.

That is not transformation. It is a broken process with a faster engine.

The first AI implementation decision is not which tool to buy. It is what the work should look like after unnecessary steps, duplicate reviews, avoidable handoffs, and unclear ownership have been removed.

Start with the work, not the software

Every workflow contains different kinds of work:

  • steps that should disappear;
  • steps that need a consistent template;
  • bounded tasks AI can handle;
  • judgment that should remain with a person;
  • decisions that require explicit approval; and
  • actions that should stop because the risk exceeds the value.

Most teams skip this sorting exercise. They take the existing process, add an AI step somewhere in the middle, and call the result transformation.

The predictable outcome is more review, more exceptions, and more cleanup. AI can draft an answer, summarize a case, or route a request. It cannot make a badly designed workflow coherent by itself.

The five-question workflow redesign screen

Before selecting a model, agent, connector, or automation platform, answer five questions.

1. What outcome are we actually trying to produce?

“Use AI to improve support” is not an outcome. “Resolve routine billing questions within one business day, with fewer escalations” is closer.

Name the customer or employee result, the current cycle time, the cost of failure or rework, and the metric that will prove improvement.

If the team cannot describe the outcome, it is not ready to automate. It is shopping for software to solve an undefined problem.

2. Which steps should vanish or become standard?

Map the current workflow one step at a time. For each step, choose one disposition: keep it, remove it, standardize it, delegate it to AI, or reserve it for human judgment and approval.

This is where the real savings usually appear. A duplicate data-entry step may cost more than the task the AI was supposed to perform. A vague approval loop may create delay without improving quality. A form may collect information nobody uses.

Do not automate the mess merely because the mess is familiar.

3. What is the smallest safe automation boundary?

Define the boundary in plain language:

  • what AI may read;
  • what it may draft;
  • what it may change;
  • what it may send or publish;
  • what event forces it to stop;
  • who reviews the result; and
  • how the work is recovered if something goes wrong.

The boundary should be narrower than the full business process. A useful first pilot might let AI classify an incoming request and prepare a suggested reply. It does not need permission to change a customer record, issue a refund, or send a message without review.

Capability is not authorization. A user's access is not automatically permission for an AI system to act on the user's behalf.

4. Where does judgment remain human?

The goal is not to remove people from every step. It is to make human attention count where it matters.

Keep exceptions, ambiguous cases, sensitive decisions, and irreversible commitments visible to a named person. If “someone will review it” is the control, the workflow does not have a control. Name the reviewer, define what they check, and state what happens when they reject the output.

5. What evidence will tell us whether it worked?

Generation counts are not business results. Neither is a time estimate produced by the system itself.

Measure what survives review: turnaround time, correction rate, escalation rate, reviewer burden, customer outcome, capacity actually redeployed, or another metric tied to the stated goal.

If the process generated 500 drafts but staff had to rewrite 450 of them, the system did not create 500 units of value. It created 500 review events.

A simple example: support triage

Imagine a small service business handling customer support through a shared inbox.

The current process looks like this: an employee opens every email, copies details into a spreadsheet, forwards some messages to a manager, searches old replies, drafts a response, waits for approval, sends the answer, and manually updates a second tracker.

A weak automation project puts AI into the drafting step. The business still has duplicate entry, unclear routing, two trackers, and an approval bottleneck. It may produce drafts faster, but the queue remains.

A redesigned workflow might look different:

1. AI reads the incoming message and extracts the standard fields. 2. The system classifies the request against a short, maintained set of categories. 3. Routine requests receive a draft using an approved response pattern. 4. Missing information triggers a clearly defined follow-up. 5. Refunds, complaints, unusual requests, and sensitive cases stop in a human review queue. 6. The final disposition and reviewer decision are recorded in one system.

The important improvement is not the draft. It is the removal of duplicate work and the separation of routine handling from judgment-heavy exceptions.

Four decisions before the pilot

Once the workflow is redrawn, the next step should be one of four decisions:

  • Redraw when the outcome is unclear, the inputs are unstable, or unnecessary steps dominate the process.
  • Standardize when the workflow is valuable but inconsistent and needs defined inputs, outputs, and ownership.
  • Pilot when the task is bounded, the reviewer and stop rule are named, recovery is possible, and the proof metric is clear.
  • Do not automate when the judgment or risk cannot be bounded economically.

That last option is not a failure. Refusing to automate a process that cannot be safely controlled is good operations.

The operator's rule

Do not buy the tool until you can draw the work without it.

If you cannot show which steps disappear, which remain human, where approval happens, and what evidence will prove the result, you are not choosing an automation. You are adding another moving part to an existing problem.

Redraw first. Standardize what remains. Automate the smallest safe boundary. Then measure what the business actually gained.

Put this into practice

Use the [Cortex AI Workflow Redesign Screen](../products/freebies/cortex-ai-workflow-redesign-screen-2026-09-01.md) to map one workflow before you compare tools. Pair it with the [AI Workflow Permission Release Card](../products/freebies/cortex-ai-workflow-permission-release-card-2026-08-28.md) when the pilot will read from or act on business systems.