Most AI Problems Are Operational Problems

Most organizations do not have an AI problem.

They have work that waits too long, moves through too many hands, depends on one person's memory, repeats without getting easier, or breaks whenever the usual workaround stops working.

AI may help with that. Sometimes it helps a lot. But "we need AI" is often a conclusion people reach before the workflow has been inspected. It skips the more useful question: where does the work actually get stuck?

That skip is understandable. AI is visible. It is new, impressive, and easy to imagine as a general solvent for whatever has become annoying. A team sees manual follow-up, duplicated entry, slow reporting, unanswered questions, and a person constantly being interrupted. Then someone asks whether an agent could handle it.

Maybe. But "handle it" is doing a lot of work.

Before a system can help, the work has to be made visible enough to understand. What starts the process? What information is required? Who owns the next step? Where does the work wait? What counts as a good output? What happens when the input is incomplete, stale, weird, or politically delicate? Which decisions need human judgment because the consequence belongs to a person, not a model?

The bottleneck might be a person who has become the unofficial router for every edge case. It might be a spreadsheet that everyone updates differently. It might be a policy that exists in conversation but not in documentation. It might be a review step that matters, but has never been named. It might be a handoff where the next person never receives enough context to act without asking three follow-up questions.

It might also be something smaller and less glamorous. A form that asks the wrong first question. A shared inbox where priority is implicit. A folder full of almost-current templates. A recurring report whose audience changed six months ago. A customer intake process where every missing field becomes a private detective assignment. A manager who is not overloaded by volume so much as by being the only person who knows which exceptions are safe.

Those are operational problems. Some are excellent candidates for an agent. Some are not. The difference matters because the workflow is the product, not the model call by itself.

An agent can help when the work repeats, the inputs are available, the output can be reviewed, and the system has a defined lane. It can draft, check, route, summarize, compare, prepare, and alert. It can reduce the amount of effort a person spends getting to the point where judgment is useful.

That is a real gain. A good agent does not have to replace the experienced person to be valuable. It can gather the source material before the review meeting. It can prepare the first version of a weekly brief. It can compare new cases against known rules. It can flag missing information before a request lands in front of the person who is supposed to make the decision. It can turn "go look through all this" into "here is the review packet, with the uncertain parts marked."

That is useful because experienced attention is expensive. Not just in salary, but in interruption. Every time a senior person has to reconstruct context, answer the same procedural question, find the right document, or remember how the last exception was handled, the organization is spending judgment on friction.

But an agent is a poor substitute for an unresolved decision. It will not fix a workflow nobody owns. It will not make missing data appear. It will not rescue a process where every case is different because the organization has never agreed on what "done" means.

This is where many AI conversations get sideways. The team asks for a tool, but the tool is only the visible part of the complaint. They ask for a chatbot, but the actual issue is that answers live across five documents and nobody knows which one is current. They ask for an email agent, but the real bottleneck is that nobody has agreed which replies require approval. They ask for automatic reporting, but the hard part is that each department defines the metric differently.

If those questions are skipped, the agent inherits the confusion. It may even make the confusion faster. That is not progress. That is a workflow problem wearing a shinier jacket.

That is why the first question should not be "what AI do you want?"

The better questions are more ordinary:

• Where does work wait?
• What gets repeated?
• Who keeps getting interrupted?
• What information is missing when the next person receives the work?
• What does everyone already know is a workaround?
• What would break if the person with the context disappeared for a week?

These questions are less exciting than a demo, but they are much more useful. They move the conversation away from a desired feature and toward the shape of the work. They also protect the buyer. Once the workflow is visible, it becomes easier to see whether the right answer is an agent, a smaller software tool, a process change, a better template, an off-the-shelf product, a clearer owner, or a person in a role that now makes sense.

Those questions point at the real intervention. Sometimes the answer is a workflow-specific agent. Sometimes it is conventional software, an existing product, clearer documentation, a changed handoff, a different hire, or no action yet. The same pressure can also show up as hiring urgency, which is why it is worth asking whether you are hiring around a broken workflow before adding headcount.

That is not a failure of AI. It is the condition for using AI well.

The best AI projects usually become more specific as they get more serious. "We need help with operations" becomes "every Tuesday, these five sources need to be checked, differences need to be summarized, missing inputs need to be flagged, and the owner needs a review packet before noon." That second version can be scoped. It has a trigger, inputs, outputs, timing, ownership, and a place for human review. It gives the system a lane.

The same is true in the other direction. A vague agent request can become a plain operational fix. Maybe the company does not need an AI system yet. Maybe it needs one canonical intake form. Maybe the customer success team needs a shared exception log. Maybe the founder needs to write down the five rules they keep explaining in Slack. Maybe the best recommendation is to buy a product that already solves eighty percent of the problem.

This is why a good first engagement should feel more like an assessment than a pitch. The job is not to validate the original request. The job is to inspect the workflow closely enough to recommend the highest-leverage intervention. Sometimes that leads to a build. Sometimes it leads away from one. Either way, the organization should understand the work better than it did before.

The goal is not to buy an agent. The goal is for the organization to spend less effort achieving the same business outcome. If AI is the right tool for that, build it carefully. If something simpler removes the friction first, do that.

AI is powerful enough that it deserves this discipline. The more capable the tool becomes, the more important it is to point it at the right job.