Before asking which artificial intelligence (AI) to buy, it is worth asking why a step still exists when no one can defend it without starting with “that is how we have always done it.”

TL;DR

Not every bottleneck needs artificial intelligence. Sometimes it calls for removing a step; sometimes for simplifying, standardizing, or automating it with an ordinary rule. Assistive AI belongs where language, ambiguity, or volume truly demand interpretation. An agent belongs where the path varies, tools are needed, and autonomy is bounded. Diagnosis comes before tooling because accelerating a bad process only produces a bad process at higher speed — with a much more expensive presentation.

There is a corporate ritual that repeats with impressive confidence.

Someone finds a queue, rework, a spreadsheet nobody understands, or a person who has spent their life copying data from one screen to another. The company looks at the scene, takes a breath, and announces the contemporary answer:

“We need to put AI in this.”

Maybe it does.

But perhaps the operation needs to stop asking someone to print, review, sign, scan, and resend a document that was born digital. Perhaps it needs a clear rule. Perhaps two systems need to talk to each other. Perhaps it needs to admit that a temporary decision from 2017 grew roots and nobody had the nerve to ask why.

Putting AI on top of that can be like using a bazooka to kill a fly. The fly dies. The office also loses a window.

I am not writing this to turn “not using AI” into a posture of technical sobriety. I work precisely by building software, automation, and AI-assisted systems. The point is different: technology is a choice about how a system’s parts, connections, and responsibilities are organized — its software architecture. It is not a modernity badge. And that architecture starts by understanding the actual problem, not celebrating the tool that just appeared in a demo video.

The problem is not the tool. It is the lazy question

In Your Company Doesn’t Need to Figure Out Where to Put AI, I argued that we should start where work gets stuck. This article takes one earlier step: before deciding where AI goes, we need to decide whether it should go there at all.

Because “where do we put AI?” is often an elegant way to avoid less photogenic questions:

• what outcome does this step actually produce?
• who uses that outcome — and what happens if it arrives late or wrong?
• what decision does the step support?
• what changes if it simply stops existing?
• is the rule already known, or are we calling confusion intelligence?

A tool can hide those questions for a while. It cannot answer them for us.

When the answer is “nobody knows, but we have always done it this way,” we do not yet have an AI use case. We have an investigation.

The intervention order that avoids technological theater

I usually think of six possible moves. They are not a mandatory ladder; one process can combine more than one. But the order helps keep complexity from becoming a résumé.

1. Remove it

The most underrated question in a process meeting is: does this need to exist?

A duplicated approval, a report nobody reads, a manual copy made “for safety,” and a review created to compensate for a different error can all look small. Together, they become an informal department dedicated to maintaining the past.

Removing a step is not laziness. It is process design. If it protects no risk, produces no decision, meets no real obligation, and delivers value to nobody, the most elegant solution may be retiring it.

No system trained to process and produce text — a language model — outperforms a task that no longer exists.

2. Simplify it

Sometimes the step has a reason, but it became elaborate because every exception got a patch. Someone fills five fields so another person can discover later that only two mattered. The form demands a long description that ends in “urgent.” The flow crosses three systems because nobody had time to define the authoritative place where information should be maintained — the source of truth.

Simplifying means reducing steps, fields, approvals, and transfers between people or systems until only what is necessary remains. It does not mean weakening control. It means making control proportional to risk.

Using a knife to tighten a screw can work in a pinch. Building the entire process around the knife is just a creative way to ensure somebody gets hurt later.

3. Standardize it

Some work only looks complex because everyone does it differently.

Standardizing means making the input, criterion, owner, exception, and outcome explicit. It means defining what “order ready” means before creating AI to guess whether an order is ready. It means recording the policy before asking an agent to apply it. It means deciding where information lives before creating search across five conflicting versions of it.

Standardization does not require every situation to become rigid. It separates the common path from the exception that deserves human analysis.

4. Automate it with a rule

When input, rule, and outcome are known, the best answer is generally a system that executes the same rule for the same conditions — deterministic automation.

If payment is confirmed, update the status. If a required field is missing, block submission. If a deadline expires, notify the owner. If a backup finishes, record the outcome.

We do not need AI to add values, transfer data between systems, or validate an objective condition. Using a system that chooses outputs from probabilities derived from learned patterns instead of merely executing a fixed rule — a probabilistic model — can make the result less predictable, harder to test, and more expensive to operate. It is impressive in the same way an airplane dashboard on a toaster is impressive: someone clearly worked very hard, but it is still just toast.

5. Use AI as assistance

AI starts to make sense where language, ambiguity, or volume cannot be handled well by a standalone rule.

It can summarize a long history, extract fields from varied documents, classify requests, compare text versions, locate relevant information, or produce an initial analysis for a person to review.

Here, AI does not receive authority to “solve everything.” It reduces cognitive work, organizes material, and improves the next decision. The person remains responsible for what matters; the tool helps the person see better.

This is especially useful where the response needs context but the result still requires human review. It is assistance, not abdication.

6. Use an agent — but with a contract

An AI agent is not a chatbot with courage. It is a system that combines context, tools, and criteria to choose next steps inside a defined space.

It can query data, gather evidence, fill forms and records, open a task, request missing information, or perform a permitted action. The path can vary by case; that is why controls must grow with it.

Before taking that step, I want to know:

• which tools the agent may use;
• which actions it can never perform alone;
• when it must stop and ask for help;
• how it records what it consulted and did;
• how we correct or undo an action;
• who is accountable when the result is not what was expected.

Without that, “autonomous agent” is often just a polished name for “nobody designed accountability yet.”

A less glamorous — and much more useful — example

Imagine a team receiving orders by email. Someone reads them, copies data into a spreadsheet, asks through chat whether there is stock, waits for the answer, updates another system, and sends a standard confirmation.

The rushed reaction would be: “let’s build an AI agent to handle orders.”

Diagnosis may reveal something else:

1. half the orders could already use a form that fills the correct fields;
2. inventory has an application programming interface (API), a documented way for one system to query another, and does not need someone asking in internal chat;
3. the standard confirmation can be sent by a rule;
4. only orders with ambiguous descriptions or commercial exceptions need interpretation;
5. only the truly relevant exception needs to reach a person.

The final design may have a better form, inventory integration, ordinary automation, assistive AI for free text, and a human queue for exceptions. There may not be an executing agent at all.

That is not a defeat for AI. It is a win for operations.

The goal is not to install the showiest component. It is to remove waiting, errors, and useless work without creating a new beast to feed.

The wrong tool charges interest

Every system carries operating cost: credentials, integration, data, monitoring, failures, maintenance, training, vendor changes, and people who need to understand what to do when something leaves the script.

An excessive solution can resolve the initial symptom and create another bottleneck around itself. The process that once had one bad spreadsheet ends up with one bad spreadsheet, an agent without context, an unstable integration, three monthly subscriptions, and a weekly meeting to discover why it said “certainly” about an invented premise.

That is not an argument against experimentation. Small, reversible, measured experiments are how we learn. But a prototype does not become an operation by osmosis. When something starts affecting customers, money, personal data, access, or a material decision, it needs an owner, criteria, observability — signals that let us understand what the system did and diagnose failures — and limits.

The AI Risk Management Framework from the National Institute of Standards and Technology (NIST) is voluntary and does not dictate a company’s architecture. It supports something more basic: AI risk must be considered in the design, development, use, and evaluation of a system. Admiring the model is not enough; the effect it produces needs governance.

The question I would ask before any demo

If I am talking to a company about AI, I do not start by asking for access to a vendor account. I start by locating the real work.

I ask where people wait. Where they repeat. Where they need to search for information. Where a decision relies on memory. Where an exception becomes a fire. Where someone performs a step they can explain — but cannot justify.

Then comes the question that dismantles a lot of anxiety:

If we took AI out of the room for five minutes, what would we still need to solve?

That answer is the material of architecture.

Sometimes it points to a simple integration. Sometimes to a better policy. Sometimes to automation. Sometimes to assistive AI. Sometimes to an agent with clear limits. And yes, sometimes it points to a stupid step that only needed a polite farewell.

At i-9.ai, I begin with that diagnosis: understand what is stuck, what must be preserved, and what is the smallest architecture capable of producing a verifiable result.

If you have a process that looks like it needs AI but suspect it only needs attention, get in touch. Bring the ugly spreadsheet. It usually tells more truth than the pretty demo.

Keep reading

• Your Company Doesn’t Need to Figure Out Where to Put AI: the larger map for choosing process, automation, assistive AI, an agent, or a human decision.
• Generic Agents May Be Your Worst First Contact With AI: why a ready-made solution without context usually disappoints before it helps.
• AI Is Not Just a Content Generator for Your Social Networks: a broader view of what AI can do once there is a real problem to solve.

References and limits of use

• OpenTelemetry — What is OpenTelemetry?: official documentation on telemetry signals, such as traces, metrics, and logs, used to understand running systems. It supports the explanation of observability; it does not impose a particular tool or implementation.
• NIST — AI Risk Management Framework: official reference for voluntary management of risks associated with AI systems. It supports considering risk throughout the lifecycle; it does not prescribe the intervention order proposed here or certify an implementation.

The examples are architectural hypotheses intended to make criteria visible. They are not case studies, performance promises, or a substitute for technical, legal, financial, labor, or security diagnosis in the real context.