It took me a while to put this into words.
I spent more than twelve years working around enterprise Customer Support, Technical Escalations, knowledge systems, conversational technology, customer data, routing, integrations, and the operational systems behind customer care.
During that time, I also watched AI begin moving into those workflows.
And I kept noticing a failure pattern.
Sometimes the starting question was effectively:
"We have AI. Where can we use it?"
The better question is:
"What is actually wrong with this workflow, what outcome needs to improve, and what kind of intervention does the problem require?"
Those are very different starting points.
A Support problem might come from missing information, a product defect, poor routing, bad data, or something deterministic software could handle perfectly well.
Only some problems actually require ambiguity, contextual interpretation, or adaptive decision-making from an AI system.
That distinction matters more than it might seem.
A technology can be capable without being the right intervention
One of the easiest mistakes to make with a powerful new technology is to confuse capability with necessity.
An LLM might be able to classify a request.
That does not mean an LLM is the best way to classify it.
An agent might be able to choose among several tools.
That does not mean the workflow requires adaptive tool selection.
A generative system might be able to produce a polished answer.
That does not mean generating a new answer is better than retrieving an authoritative one that already exists.
The question is not:
Can AI perform this task?
The more useful question is:
What mechanism does this problem actually require?
That changes the design conversation.
If the input is known, the rule is stable, and the expected action is deterministic, normal software may be the better answer.
If the problem is that people cannot reliably find information the organization already possesses, retrieval may matter more than generation.
If the workflow requires interpreting variable language or incomplete context, an AI-assisted step may make sense.
If the next action genuinely depends on intermediate evidence and the system must choose among several approved tools, bounded agentic behavior may become useful.
Those are different problems.
They should not collapse into one category called "AI opportunity."
The workflow comes before the model
Years in production Support taught me not to confuse the first visible symptom with the mechanism causing it.
A customer might report that something is "slow."
That does not tell you whether the problem is the application, the network, the database, a downstream dependency, capacity, configuration, or something else entirely.
You investigate the path.
You compare expected behavior with observed behavior.
You gather evidence.
You narrow the failure domain.
The same discipline should apply when an organization says:
"Agents are spending too much time on these cases."
That statement is not yet a diagnosis.
Maybe the information already exists but is difficult to retrieve.
Maybe the information does not exist.
Maybe the workflow requires too many handoffs.
Maybe the product exposes the wrong data at the wrong point.
Maybe the case is waiting on another team.
Maybe there is a deterministic rule that has simply never been automated.
Maybe the work genuinely requires judgment.
Those situations can look similar at the level of the business symptom.
They require very different interventions.
If we jump directly from:
"Agents are spending too much time"
to:
"Let's build an LLM assistant"
we skip most of the reasoning that determines whether the intervention has any chance of creating value.
The first useful question is usually about the outcome
I already knew how to investigate difficult technical problems.
What I realized I wanted to get better at was the layer above the technical diagnosis.
What outcome are we actually trying to improve?
Where in the workflow is value being lost?
What evidence supports one explanation over another?
What are the alternatives?
And if a technical metric improves, does that improvement actually become operational value?
So I started changing how I approached problems.
Start with the outcome.
Understand the workflow.
Establish the baseline.
Test the likely causes.
Compare the available interventions.
Only then decide what should be built.
Afterward, measure whether the workflow actually improved.
That last part is important.
Because a system can improve technically without improving the operation.
Better AI metrics do not automatically mean better business outcomes
Suppose a new retrieval system improves recall.
That may be useful.
But it does not yet tell us whether Support cases are resolved faster.
Suppose an assistant reduces the time required to draft a response.
That does not tell us whether customers receive better answers.
Suppose an automated workflow saves five minutes per case.
That does not automatically mean the organization created financial value.
Saved time only becomes operational capacity if the workflow can actually use that capacity.
And capacity only becomes financial value through some realization mechanism.
Maybe the team can absorb additional demand without hiring.
Maybe backlog falls.
Maybe escalation volume falls.
Maybe service level improves.
Maybe highly skilled engineers spend less time reconstructing known information and more time on novel problems.
But those things have to be demonstrated.
A technical success metric is not the same thing as a business case.
That distinction is especially important with AI because it is easy to measure things that are adjacent to the outcome rather than the outcome itself.
The model responded.
The endpoint was healthy.
The latency was acceptable.
The evaluation passed.
The agent completed the workflow.
All of those may matter.
None of them independently establish that the customer-care operation improved.
Sometimes the right answer is retrieval, not generation
One of the recurring Support problems that pushed me toward applied AI was much simpler than "we need an intelligent agent."
The organization often already possessed useful knowledge.
A difficult issue would be investigated.
Support would collect evidence.
Engineering or Development might become involved.
Eventually the problem would be understood and resolved.
That knowledge would then exist somewhere.
A ticket.
A document.
A conversation.
A runbook.
An individual's memory.
Months later, a similar issue could appear and another skilled person would reconstruct much of the same reasoning.
The knowledge existed.
The system for using it reliably did not.
That is a very different problem from:
"We need the model to invent an answer."
It is closer to:
"We need to retrieve the right evidence, for the right person, in the right context, and know when the evidence is not good enough."
That distinction led me much deeper into retrieval, evaluation, and evidence quality.
It also reinforced a larger lesson:
The intervention should match the failure mechanism.
Sometimes deterministic software is better
There is also a tendency to use AI for decisions that are not actually ambiguous.
If a rule can be expressed clearly and evaluated deterministically, there is often no advantage in asking a probabilistic model to rediscover it every time.
For example:
- required fields;
- eligibility rules;
- state transitions;
- routing based on known attributes;
- permissions;
- fixed escalation conditions;
- threshold checks.
Those are usually better expressed as software, policy, or workflow logic.
AI may still participate elsewhere in the workflow.
It might extract information from unstructured text before the rule runs.
It might summarize context for a human.
It might retrieve supporting evidence.
But that does not mean the control itself should become probabilistic.
There is a useful architectural principle in that:
Use AI where ambiguity exists. Use deterministic mechanisms where the rule is already known.
The boundary between those two is often more important than the choice of model.
Agentic behavior should have an additional justification
The same applies when moving from a single AI-assisted step to an agent.
An agent is useful when the workflow genuinely requires variable sequencing.
Observe something.
Choose among several approved tools.
Inspect the result.
Decide what evidence is still missing.
Take another bounded action.
Stop when the objective or stopping condition is satisfied.
That can be powerful.
But it introduces another level of uncertainty.
More possible paths.
More state.
More tool interactions.
More failure modes.
More questions about permissions and external consequences.
So "this could be an agent" is not enough.
The workflow needs to justify why adaptive sequencing provides value that a simpler deterministic process cannot.
Sometimes it does.
Sometimes a fixed workflow with one or two AI-assisted steps is easier to evaluate, easier to operate, and easier to trust.
I needed to understand the technology deeply enough to reject it
At the same time, I knew I could not make good decisions about AI while treating the technology as a black box.
So I got to work on that side too.
Retrieval.
Evaluation.
AI workflows.
Runtime controls.
Not because every problem needs them.
Because I wanted to understand the intervention space well enough to know when they were actually warranted.
That may sound backwards.
Why learn a technology deeply if the goal is sometimes to say not to use it?
Because shallow understanding makes technology selection worse.
If I do not understand retrieval, I cannot tell when better search is enough.
If I do not understand model evaluation, I cannot tell whether apparent improvement survives controlled testing.
If I do not understand agentic workflows, I cannot distinguish genuine adaptive reasoning from a deterministic workflow wrapped in agent terminology.
If I do not understand runtime controls, I cannot reason clearly about the difference between generating an output and allowing that output to create an external consequence.
Technical depth should make intervention selection more disciplined, not more enthusiastic.
"Do not use AI" is a legitimate result
Sometimes the analysis should end with an LLM.
Sometimes it should end with retrieval.
Sometimes deterministic software.
Sometimes a data fix.
Sometimes a process change.
And sometimes the correct conclusion should simply be:
Do not use AI here.
That is not anti-AI.
I think it is part of becoming good at applied AI.
The value of applied AI is not measured by how many workflows contain a model.
It is measured by whether the organization became better at accomplishing something that matters.
That means understanding where the constraint actually is.
Choosing the smallest intervention capable of addressing it.
Measuring whether the intervention changed the workflow.
And being willing to stop when the evidence does not support continuing.
AI-first should not mean putting AI first in the reasoning process.
It should mean becoming very good at recognizing where AI creates real leverage, building it well when it does, and measuring whether the organization actually got better afterward.
Related engineering notes
- From Genesys to Keystone: enterprise rigor on the LLM substrate
What 12+ years in enterprise contact-center systems carried into hands-on AI engineering. - The knowledge was already there. The system to use it was not.
Why repeated support investigations led me toward retrieval, RAG, evaluation, and production AI systems. - What evaluation artifacts taught me that demos never could
Why retained failures and bounded claims became part of the engineering loop.