Applied AI fails when it accelerates the wrong process

By Juan Pablo Ingrassia, VP Applied AI & Forward-Deployed Engineering at Santex

There is a pattern that keeps showing up in almost every conversation about enterprise AI.

Someone demos a copilot that drafts an email, summarizes a meeting, or finds an answer in a document. The team gets excited, the company buys licenses and rolls out training. A few months later, people are still waiting for approvals, chasing down data, copying information between systems, and discovering risks too late.

The tool may be good. The problem is that it was attached to an isolated task while the process around it stayed exactly the same.

Michael Hammer made the point more than three decades ago: computerizing the old way of working does not fix the old way of working. AI is no different. The only difference is that the speed of the demo now makes it easier to confuse activity with impact.

While developing STX Agents, that distinction became very tangible. An agent can prepare an excellent brief and still change nothing if the person who needs to act never sees it, if critical information is scattered across three systems that do not communicate, or if no one has defined who makes the decision when an exception appears.

That is why the unit of value is the end-to-end workflow, not the agent.

The problem lives between systems

Companies already have systems to record what happens: CRM, ERP, ticketing platforms, documents, email, spreadsheets, chat channels. The work that consumes the most time often happens between them.

That is where someone gathers context for a meeting, tracks down a missing piece of data, interprets an exception, enters information again, or discovers too late that a project's risk profile has changed. None of this appears as a formal task in a system, yet it consumes a significant share of a team's capacity.

Before talking about agents, you need to identify the bottleneck — and the decision that is being made too late because of it.

The problem lives between systems.

At Santex, the problem is rarely that someone takes too long to complete a task. It appears when a signal is fragmented across a Slack conversation, a meeting, a document, and the system where that signal should become action.

A delivery risk may have surfaced during a call. The person who could unblock it only finds out during the weekly review, after five people have already reconstructed the context. A sales signal may be buried in a conversation and reach Sales after the window of opportunity has closed.

The manual work is not so much writing the update. It is reconstructing the entire story every time someone needs to make a decision.

That is why it is useful to look at the time from signal to decision: the time between something changing in the operation and the right person having enough evidence to act.

An agent may write the brief in five minutes. The value appears when that brief connects the right signal, the right owner, and the right next step at the right time.

Time from signal to decision.

The warning sign: individual satisfaction without operational results

General-purpose tools can save time and make individual work easier. But those savings do not automatically translate into organizational productivity.

The UK's Department for Business and Trade evaluated a pilot involving 1,000 Microsoft 365 Copilot licenses. Of those who responded, 72% were satisfied or very satisfied. At the same time, the report found that time savings were small in most cases and found no evidence that those savings had already improved productivity at the organizational level.

That gap between “I like using it” and “the process improved” should change the way we measure applied AI.

Tool usage matters very little if we cannot show what changed in cost, cycle time, quality, risk, or revenue.

McKinsey reached a similar conclusion in its global survey. Of the 25 attributes analyzed, workflow redesign showed the strongest association with EBIT impact attributable to GenAI. And yet, only 21% of organizations using GenAI reported having redesigned at least some workflows.

Adoption arrived before the ability to redesign the work itself.

Individual satisfaction without operational results.

What we learned from developing agents

1. The real process lives in the exceptions

Process diagrams usually show a flawless happy path. Real operations live in everything that does not fit neatly into that diagram: the document with an unusual format, the data point that does not match, the customer who changes a condition, or the person who knows a rule because they have seen it fail twenty times.

If you do not understand those exceptions, an agent may work in a demo and become fragile the moment it reaches production.

That is why serious discovery does not start with, “What kind of agent do you want?”

It starts by looking at real cases, understanding which sources are involved, defining what a good outcome looks like, identifying where cases get stuck, and knowing who steps in when there is no clear rule.

Interviews are essential, but they are not enough on their own. Systems show timestamps, status changes, volumes, and delays. Operators explain why something happened and which informal controls prevent a problem.

One without the other leaves half the picture unseen.

2. Code, agents, and humans solve different problems

One of the most expensive mistakes is using an LLM for everything simply because it can talk convincingly about almost anything.

A stable rule with predictable data and little room for interpretation belongs in conventional code, with validations and traceability. It is cheaper, faster, and easier to audit.

An agent adds value when it needs to read unstructured information, connect context, classify cases, search for evidence, or prepare a recommendation. The judgment involved may be repeatable, but it cannot be fully captured in a fixed rule.

Decisions that move money, create compliance exposure, affect a sensitive relationship, or rely on insufficient evidence need a person who remains accountable for the outcome.

Code, agent, and human.

With STX Agents, we follow a deliberate progression: first read, then prepare, then recommend, and only later execute limited actions with approval.

Autonomy comes after real cases, permissions, evals, and a clear mechanism for stopping when something does not add up.

Autonomy comes later, not first.

Anthropic recommends the same technical discipline: start with the simplest solution, use predictable workflows when the task is well defined, and add more autonomous behavior only when the added flexibility justifies the cost and latency.

3. The opportunity is in the gaps between systems

Many AI initiatives begin with an unrealistic promise: “We will replace your CRM” or “We will rebuild your entire stack.”

In a real company, the CRM, ERP, or ticketing platform already contains rules, history, permissions, and processes that took years to stabilize. Throwing them away to put a chat interface on top is often an expensive way to introduce more risk.

The opportunity is to add an action layer on top of those systems.

That layer can read context from multiple sources, detect an exception, prepare a brief, suggest a next step, route a task, and leave a trace of what it did.

Systems of record continue to capture the operation. The action layer helps move it forward.

STX Agents follows that logic: specialized agents working across defined sources, tools, and boundaries. When a recommendation could influence a sensitive decision, the human retains the final say.

4. Quality has to be designed and measured

The problem with agents is not only that they can hallucinate.

They can also use the wrong source, misinterpret an exception, call a tool that returns incomplete data, or produce an answer that is technically correct but useless to the person who needs to act.

That is why a useful evaluation does not ask only, “Did the model answer correctly?”

It asks:

• Did it find the right evidence?

• Did it flag uncertainty?

• Did it follow the format the operator needs?

• Did it escalate the case when necessary?

• What did the human correct, and why?

• What were the cost and latency of each run?

Every human correction should feed into a failure taxonomy.

An incomplete source, an ambiguous business rule, or a tool failure are design categories that need to be addressed, even if they initially look like isolated incidents.

An agent without traces or evals is a black box with a friendly interface. It may look impressive, but it has no place operating a critical process.

5. Measurement starts before implementation

A baseline and a testable hypothesis need to exist before a pilot begins.

Before implementation, choose a metric that matters to the process owner:

• resolution time;

• volume of cases waiting;

• errors or rework;

• risks identified earlier;

• conversion or opportunity velocity;

• expert hours recovered for higher-value work.

Then define what outcome would kill the idea.

If the agent does not reduce a queue, improve quality, or achieve adoption within a reasonable window, the workflow needs to be corrected — or the investment needs to stop.

Adding more prompts does not turn a weak hypothesis into a product.

Gartner projected that more than 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls.

It is a prediction, not a law of physics. But it describes remarkably well the combination we see in projects born from hype: inflated autonomy, poorly chosen use cases, and no clear owner of the outcome.

The expert's job changes

The most useful applied AI removes repetitive work that consumes attention from the loop and leaves experts focused on exceptions, quality, and the decisions where their judgment adds value.

That shift in role also changes the business conversation.

Trust grows when a company can see what information the system used, what permissions it has, when it requested approval, where it failed, what it learned, and which operational metric improved.

The real product includes the model, yes.

But it also includes trusted sources, well-designed tools, permissions, a working interface, logs, evals, human feedback, and an operating model that takes responsibility for improving the system over time.

What I would ask before approving the next AI pilot

I would ask for five concrete answers:

1. What decision or operational outcome are we trying to improve?

2. Where is time being lost across teams, systems, and exceptions?

3. What should be handled by code, what requires judgment, and what remains a human responsibility?

4. What evidence does a person need in order to trust the system and act quickly?

5. What number, 30 days from now, would prove that this is worth continuing?

Without those five answers, what the company has is a demo looking for a problem.

At that point, it is better to go back to the workflow map before spending more on licenses, prompts, or new agents.