There is a statistic making the rounds that 95 percent of AI projects fail. The number comes with important qualifications, but the underlying warning is real: many organizations can produce an impressive AI demo without producing a durable business result.

That made me ask a more personal question: if so many AI initiatives fail, why has my own work with AI been effective?

The answer is not that I found a magic prompt. It is that I use AI as an investigation and execution multiplier, not as a novelty and not as an oracle.

My working rule: Use AI to reduce the cost of thinking through a difficult problem. Keep human judgment, accountability, and verification in the loop.

The statistic is about outcomes, not clever answers

When people say an AI project failed, they usually do not mean that the model never generated anything useful. They mean that the initiative did not reach production, did not change a meaningful business metric, or created more cost and risk than value.

A model can write a convincing summary, generate working code, or suggest a plausible diagnosis and still be part of a failed project. The real test is whether the complete process became faster, safer, cheaper, or more valuable after accounting for integration, review, training, security, and correction.

That distinction describes the difference between a demo and an operating capability. I have been effective because I tend to start with a real operational problem and measure success by what happens in the real system afterward.

Start with the problem, not the technology

The strongest AI use cases I have found began with a problem that was already expensive in attention or time. A defect had been open for weeks. A cloud migration involved a messy chain of image conversion, disk upload, boot diagnosis, and repair. A technical issue required connecting evidence across monitoring, tickets, command-line tools, and source code.

I did not start by asking, “Where can we use AI?” I started by asking, “What is preventing us from reaching a reliable answer or a verified result?” That framing matters. It gives the AI a job to do and gives the human a way to decide whether it succeeded.

Use AI where context is fragmented

Many difficult problems do not have one missing fact. They have several facts sitting in different places that nobody has lined up yet.

In one investigation, the clues were spread across infrastructure metrics, live process state, incident history, cache behavior, and a shared library. The CPU ramp was visible in monitoring. A runnable thread was visible on the host. The same thread appeared across multiple services. The cleanup behavior was in source code. No individual tool contained the answer.

The agent helped stitch the evidence together and keep the reasoning available between sessions. It helped move from symptom to hypothesis, from hypothesis to query, and from query to the next layer of evidence. That is a much more valuable role than simply asking it to write a paragraph about the incident.

The same pattern appeared in an Azure migration. The work required a sequence of small but consequential decisions: convert a dynamic disk to fixed VHD, align it correctly, upload it through a managed disk workflow, repair boot behavior, and validate the result from limited evidence. AI helped with command construction, interpretation, and troubleshooting, but the work succeeded because each step had a concrete gate and a way to verify the next state.

Keep competing hypotheses alive

AI is dangerous when it gives a plausible explanation and everyone starts defending it. I get more value when I ask it to keep multiple explanations in play.

For the CPU issue, a flat memory graph initially seemed to rule out a leak. That was useful, but it did not rule out every kind of resource leak. A node replacement appeared to fix the problem, but the more careful interpretation was that it had reset the age of every process and restarted the ramp. The agent helped connect those observations without turning the first interpretation into a permanent conclusion.

I want the system to say:

  • Here is what the evidence supports.
  • Here is what it rules out.
  • Here is the observation that does not fit cleanly.
  • Here is the cheapest next test.
  • Here is what would change our mind.

That turns AI from an answer machine into a hypothesis-testing partner.

Give the AI access to the work, not just a description of it

A model working from a short prompt has to guess what matters. An agent operating within a controlled set of tools can inspect the actual ticket, query the relevant metrics, read the code, compare configurations, and preserve the trail of reasoning.

That does not mean giving an agent unlimited access. It means giving it the smallest useful set of capabilities and making the boundaries explicit. Read-only investigation is different from changing production. Drafting a remediation is different from applying it. The more consequential the action, the more important approval gates and rollback become.

The useful pattern is progressive autonomy:

  • Observe: collect evidence from approved systems.
  • Explain: connect facts and present competing hypotheses.
  • Recommend: propose a focused change and identify risk.
  • Execute: apply only the approved action.
  • Verify: prove that the system reached the intended state.

Make verification part of the work

The best AI-generated answer is still only a hypothesis until reality confirms it. I expect the result to survive a query, a build, a test, a deployment check, a screenshot, or a direct inspection of the system.

That habit catches two different kinds of failure. It catches incorrect model output, and it catches correct output applied to the wrong problem. A command can be syntactically valid and operationally wrong. A diagnosis can explain one symptom while missing the incident. Verification is where those differences become visible.

It also changes the conversation with the AI. Instead of asking, “Is this right?” I ask, “What evidence would prove or disprove this?” That produces better work and makes uncertainty visible to the people who own the decision.

Use AI to remove tedium, not accountability

The value in these examples did not come from avoiding expertise. It came from making expertise more available to the problem.

The agent reduced the cost of searching, comparing, summarizing, testing alternatives, and carrying context across system boundaries. I still had to decide what mattered, assess risk, recognize when a theory was too convenient, and determine whether the fix was safe to apply.

That is the division of labor I want. Let the machine handle more of the tedious investigation. Keep people responsible for priorities, trade-offs, and consequences.

A repeatable playbook

For people trying to use AI effectively, the pattern is straightforward:

  1. Choose a real bottleneck. Start with time, risk, delay, or repeated effort that already matters.
  2. Define the desired outcome. Say what “better” means before asking the AI to help.
  3. Assemble the evidence. Include the systems, logs, history, code, and constraints that shape the problem.
  4. Ask for competing explanations. Do not reward the first confident story.
  5. Run cheap tests first. Use the AI to identify the next action that eliminates the most uncertainty.
  6. Apply the smallest safe change. Separate recommendation from execution and preserve rollback.
  7. Verify the result. Treat production behavior as the authority.
  8. Record the reasoning. Capture what was tested, what was rejected, and why the final decision was made.

Why this works

My successful AI work has a few common traits:

  • It begins with an outcome rather than a tool.
  • It crosses system boundaries where context is normally lost.
  • It uses domain expertise to evaluate the model's suggestions.
  • It treats negative results as useful evidence.
  • It keeps uncertainty visible instead of hiding it behind polished language.
  • It includes a real feedback loop from the system being changed.

That is why I have been effective even while many larger AI initiatives struggle. I am not asking AI to replace the operating model. I am using it inside an operating model that already has a problem, an owner, evidence, decision points, and a definition of done.

Closing thought

People do not need to become prompt engineers to use AI well. They need to become better problem framers, evidence gatherers, reviewers, and decision makers.

The most useful AI systems will not simply produce more content. They will help people connect information, test explanations, navigate complexity, and move from uncertainty to a verified result.

Use AI to make difficult thinking cheaper. Do not use it as an excuse to stop thinking. That is the difference between an AI demo and an AI capability.