How Do You Know If a Business Problem Actually Needs AI?

The pressure to add AI usually arrives before anyone names the problem it solves. 

Your board asks what the company is doing with AI, a list gets assembled, and that list is built backward from the technology toward places it might attach. 

Intake could use AI, reporting could use AI, and support could probably use it somewhere.

Some of those are right. The ones that go wrong tend to fail in a specific way, where a process that used to produce the same answer every time starts producing answers that depend on how a request was phrased. 

We build AI into client systems regularly and we talk clients out of it about as often, because the value we sell is knowing which of those two things a given workflow needs.

‍

Why do so many AI agent projects get canceled?

They get canceled on cost and on business value that never showed up, with risk controls that were never built into them. 

Over 40% of them will be shut down by the end of 2027 according to Gartner, whose analyst Anushree Verma put the underlying issue in one line: "Many use cases positioned as agentic today don't require agentic implementations." 

The same research counts only around 130 genuine agentic vendors among the thousands selling it, with the rest rebranding assistants and RPA they already had.

The pattern shows up in deployments too. A survey of 2,527 enterprise decision makers published this May found that 74% of companies running AI customer agents had rolled back or shut down at least one, and that the number climbed to 81% at companies with mature AI governance. 

Better-governed teams caught the problems sooner rather than having fewer of them.

The technology works, and the failures cluster where it was installed as the wrong component for the job.

‍

When should you use AI instead of rules-based logic?

Use AI when the same question, asked twice, does not have to produce the same answer.

If a customer asks about their refund eligibility on Tuesday and again on Thursday, your business needs both answers to match, because the policy has not changed and the customer will notice if the answer does. 

That is a rules problem, and rules problems belong in code that executes the same way every time.

If two experienced people on your team could read the same support ticket and reasonably summarize it differently, that variation is inherent to the work, and it is where a language model earns its place.

The test takes about ten seconds per workflow. 

Run it across everything currently labeled an AI project and the list usually gets shorter.

‍

What business problems is AI actually good at?

AI is good at work where the input arrives messy, language-heavy, or dependent on context that shifts case to case:

• Summarizing a long support history before someone picks up the phone
• Classifying inbound requests that arrive in whatever words the customer used
• Drafting internal notes and first-pass responses for a person to edit
• Searching internal documentation that was never organized for search
• Comparing long documents and surfacing the differences
• Suggesting a next step that a human reviews before it happens

Each of those takes something unstructured and makes it usable, and a wrong answer costs a few minutes of a person's attention rather than a customer relationship.

‍

Which parts of your software should not use AI?

Any part of your system where the business already knows the rule should stay deterministic. 

When you can state the logic in a sentence, that sentence belongs in code:

• Billing and pricing calculations
• Role-based permissions and user access
• Required fields and data validation
• Approval gates and status transitions
• Compliance checks and audit logs
• Any update to a system of record

We built FindFill around matching nurses to open shifts, which is the kind of matching problem people assume needs a model. Licensure, credentials, distance, and availability are facts with defined answers, so the matching runs on rules that produce the same result every time and can be explained to whoever asks. 

A model asked to do that job would be slower, more expensive, and occasionally creative about a nurse's certification.

‍

What goes wrong when AI sits where a rule belongs?

You convert a solved problem into an open one. Pricing logic that ran identically for every customer starts varying with phrasing. 

Access that followed a role matrix starts depending on how a request was worded. The failure surfaces late, usually when one customer compares notes with another and the two answers do not match.

When deterministic logic produces a wrong answer, a developer traces the path and finds the line. 

When a model produces a wrong answer inside a business rule, there is no line, and the fix is prompt adjustment plus hoping. 

That is why we push clients toward deterministic logic for anything touching money, access, or compliance. 

A customer asking why they were charged a certain amount deserves a real answer, and we believe that business is built on transparency and trust, and that good software is built the same way.

‍

How should AI and regular software work together?

AI handles the reading and the drafting while the system keeps every decision that has to be consistent.

A support workflow can have a model summarize the ticket history and propose a category, while the routing rules, the SLA clock, the permissions on the record, and the customer-facing status all run on ordinary code.

The model makes a person faster at the interpretive part while the system guarantees the rest behaves the same way on the thousandth ticket as it did on the first.

That division is also what makes the AI part safe to change. 

When the model sits beside the workflow rather than inside it, swapping models or adjusting a prompt cannot alter who gets access or what anyone gets charged, and you can upgrade the interpretive layer every few months without a compliance review.

Testing splits along the same line. 

A deterministic rule gets a test that passes or fails, while a summarization feature gets judged on whether the output helps the person reading it. 

Keeping those two kinds of work in separate layers means each one can be verified the way it actually needs to be.

‍

What should you ask before adding AI to a workflow?

Run any proposed AI feature through these before it reaches a roadmap:

• What is the problem, stated without the word AI? If it cannot be stated that way, the problem has not been found yet.
• Does the same input have to produce the same output? Yes points at rules. No opens the door to a model.
• Would two good employees answer this differently? Genuine variation is the signal for judgment work.
• What breaks if the answer is wrong once in fifty? Money, access, and compliance answers cannot carry that rate.
• Could a person explain the output to a customer? Anything customer-facing needs a traceable reason.
• Is the underlying data clean enough to reason over? A model reading from two disagreeing systems will produce confident nonsense.
• Is there a simpler fix? Clearer rules, a better integration, or a redesigned screen solve a surprising share of the problems that arrive labeled as AI problems.

That last question kills more AI features in our discovery sessions than any other. 

A workflow people find slow and confusing usually stays slow and confusing with a model bolted onto it.

‍

Is your AI project actually a software project?

Start from the workflow and work toward the tool. 

Gartner's read of the cancellations points at use cases that never needed an agent, which makes the 40% a scoping failure rather than a technology one, and scoping is something you control before anyone writes code.

Take the three AI ideas currently on your roadmap and apply the same-answer-twice test to each one. 

Whatever fails it is a software project wearing an AI label, and you will get it delivered faster and cheaper by calling it what it is.