When a business arrives at an AI conversation with a solution already chosen, the conversation has started in the wrong place. “We need a chatbot.” But why? Because prospects visit the website after hours and no one responds until the next morning. This is not a chatbot problem. It is a response problem, and a chatbot is one possible answer to it among several. The technology came first in the conversation, but the problem arrived before it.

The same pattern appears with AI agents. A team spends every Monday morning moving information between three different systems, copying data from one to the next by hand. “We need an AI agent.” But again, why? The underlying problem is a workflow problem: time lost to a manual process nobody designed intentionally, one accumulated around the shape of the tools available. Whether an AI agent is the right fix depends entirely on where the process breaks down, which requires examining the process first.

Starting with the technology before the problem is named produces a specific kind of inefficiency. The system gets built. The automation runs. The metrics look good. And the original problem remains, unchanged, because it was never fully understood before the solution was chosen.

The diagnostic work belongs at the front of the conversation, before any technology is considered. Where does the process slow down? Where does it break entirely? Who touches it at each stage, and what happens when something gets missed? What do the people inside the process do to compensate when it fails? What would “better” look like, in practical terms, for the people doing the work rather than the people overseeing it, and how would they know when it arrived?

These are not preliminary questions to move through on the way to a technology decision. They are the decision. The answers determine whether any technology is needed at all, and if it is, what kind, at what point in the process, and for which specific failure. They often point somewhere unexpected, and the direction they point is the one worth following.

Sometimes AI is the right answer. Sometimes simpler automation handles the problem at a fraction of the cost and complexity. Sometimes two systems need to connect to each other, and the right solution is an integration, not a model. Sometimes the process itself needs to change before anything is added on top of it. And sometimes, after the full picture is understood, nothing needs to be built. The process works adequately. It needed to be seen clearly, and the effort of seeing it was enough.

None of those outcomes is a failure. A clear diagnosis ruling out a technology investment has real value. It keeps the business from spending time and budget building something unable to solve the underlying problem. It redirects attention to where the actual constraint is. And it produces a more useful conversation about what to build next, if anything, because the problem is finally named correctly. An honest answer of “you don’t need to build anything” is harder to deliver than a technology proposal, but it is more useful.

The pressure in the current environment runs in the other direction. AI is prominent, well-funded, and present in nearly every boardroom conversation. The natural pull is to find somewhere to use it. That pull is understandable. The tools are genuinely capable and improving quickly. But “where can we use AI?” is a question starting with the technology and searching for a business problem to attach to it. The problems solved this way are often not the ones most in need of solving.

The question producing useful outcomes starts with the business: what is not working, and what would it look like if it worked? From there, the right technology, if any, becomes much easier to identify. And often, the problem turns out to be narrower than it seemed, which means the solution is too.