Resourcesicon
AI Makes It Easy to Build. Then Comes the Hard Part.

AI Makes It Easy to Build. Then Comes the Hard Part.

Something new is happening in customer advocacy. Some of the most tech-savvy program managers are building their own AI workflows on top of ReferenceEdge and other applications they use every day.

It’s easy to understand why. If you know exactly what you want to accomplish but haven’t had IT’s attention or the non-development tools to make it happen yourself, AI can be enormously empowering. The distance between “I wish I could do this” and “I can do this” has seemingly collapsed.

But there’s a blind spot hiding behind all that newfound freedom:

What does it cost?

A recent Wall Street Journal CIO Journal article about enterprise AI ROI put some startling numbers around that question.

Why are AI token costs becoming an enterprise problem?

AI token costs are becoming an enterprise problem because organizations have made AI increasingly easy to use and build with, while visibility into the cost of individual AI workflows is still developing.

David Hsu, CEO of Retool, told the Journal:

“We believe that about 90% of the tokens you’re spending are probably negative ROI.”

He cited an AI-powered out-of-office responder built by an employee that ended up costing approximately $10,000 a day.

It’s an extreme example, but it exposes a much larger issue.

Most end users building AI workflows have little visibility into their economics. They can see that the workflow works. They can see the time it saves. They can experience the thrill of creating something that previously would have required IT.

What they generally can't see is a little meter spinning furiously behind the curtain.

Arvind Jain of Glean described the problem well:

“When you allow people to build things, you give them immense power: the power to actually burn tokens and spend money.”

Better AI observability and cost-monitoring tools are emerging. As they mature, IT will get much better at identifying its conspicuous token consumers.

And that could bring this first exuberant period of end-user AI workflow experimentation to a fairly abrupt end.

When should companies use AI instead of deterministic automation?

Companies should use AI when a task benefits from reasoning, interpretation or understanding unstructured information. Predictable, rules-based processes are often better handled by deterministic automation.

That distinction may become one of the most important lessons of this phase of enterprise AI.

The Journal reported an example from Hsu in which a company had more AI agents than employees. When the company examined its costs, it discovered that 95% of the problems those agents were solving were better suited to deterministic workflows.

Changing the approach reportedly saved $20 million to $30 million.

Consider some everyday customer advocacy workflows:

Send a notification when something happens. Create a record when certain conditions are met. Route a request. Update a status. Schedule a reminder. Trigger an approval.

Those problems have been solved reliably with deterministic automation for years. And in most cases, the infrastructure to perform those actions already exists.

Using AI simply because AI can do them is the technological equivalent of hiring a sommelier to open a can of soda.

But understanding an ambiguous request? Interpreting unstructured customer information? Reasoning across multiple pieces of context? Determining what someone actually means rather than simply matching predetermined criteria?

Now AI is earning its keep.

How should enterprises balance AI and automation?

The most economical approach is likely to combine AI reasoning with deterministic workflows rather than replacing conventional automation with AI agents.

Our approach to ReferenceEdgeAI took shape near the end of what I think of as the token-maxing phase of enterprise AI.

By then, cost was already part of the conversation. There was never a time when we could assume more AI was automatically better.

Instead, we started with a different question:

Where does intelligence actually add value?

When a workflow can be handled deterministically, conventional automation is typically more predictable, consistent and accurate. Its economics are also much easier to understand.

When the problem genuinely requires reasoning, the equation changes.

The goal isn't to minimize AI. It's to stop spending intelligence on problems that don't require intelligence.

Will end users continue building their own enterprise AI workflows?

End-user AI experimentation may diminish as organizations impose stronger governance and cost controls, but the experiments themselves are providing valuable insight into what users actually need from enterprise applications.

There’s another lesson emerging from all this experimentation: vibe coding works best when the “coder” understands some fundamentals about application design, architecture and token consumption.

The vibe part is fun. Then comes maintenance (modifications, enhancements, fixes). That part can't be neglected.

From what we’re already observing, this period of largely free-form experimentation may be shorter than anyone expected. In some organizations, the shift is already underway.

As AI observability improves and organizations understand what their AI initiatives actually cost, financial discipline will follow. Some homegrown workflows will survive. Others will be rebuilt using less expensive automation. Still others will disappear because their value never justified their consumption.

But dismissing this period of experimentation would be a mistake. Customers are teaching us something extraordinarily valuable.

Given the opportunity to become creators, they can work through, in remarkable detail, what they actually want.

That’s very different from a feature request delivered from 40,000 feet.

We’re paying attention to what these customers are building.

The long-term job for enterprise technology teams isn't necessarily to preserve every experiment. It's to understand the needs those experiments reveal and determine the most reliable and economically sensible way to meet them.

For software companies, that also means deciding what belongs in the application itself and what belongs in the AI layer. Some capabilities warrant enhancements to product code. Others are better delivered through AI instructions, knowledge, skills and supporting files. Still others should combine both.

That separation matters. It allows the underlying application to do what software does best while reserving AI for the places where intelligence actually adds something.

Sometimes the answer is AI. Sometimes it's automation. Increasingly, the smartest enterprise systems will quietly use both.

Users won't particularly care which one is operating behind the curtain. They'll care that it works. And eventually, the CFO will care that the math works too.

That balance between AI reasoning and deterministic automation is central to how we're approaching ReferenceEdgeAI.

You can see examples in the videos we've shared at:

www.point-of-reference.com/referenceedgeai