The Uncomfortable Truth About AI in 2026
Here's a number that should make every CTO uncomfortable: 95% of AI projects fail to reach production.
Not because the models aren't smart enough. Not because the technology isn't ready. They fail because organisations automate broken workflows and call it "AI transformation."
I've spent the last five years building AI orchestration systems, first inside enterprises like Nordea and DXC, then through my own company, Hundred Solutions, where we built DVERSI, an AI orchestration platform. The pattern I've seen is always the same: companies buy the most capable AI model they can find, point it at their existing processes, and wonder why nothing changes.
The AI isn't the problem. The approach is.
The Configuration Trap
Walk into any enterprise AI deployment and you'll find the same architecture: a configuration wizard that asks someone (usually not the person who actually does the work) to define rules, map workflows, and set triggers. By the time the system goes live, it's already outdated.
I call this the Configuration Trap. It assumes that someone knows the optimal process before they start. But in reality, the best workflows emerge from doing the work, not from planning it in advance.
Every tool in the market today: Zapier, Make, n8n, even the newer "agentic" platforms like Lindy, starts with the same question: "What do you want to automate?"
That's the wrong question.
The right question is: "What problem are you actually trying to solve?"
Solve First, Automate Later
At Hundred Solutions, we built DVERSI around a counterintuitive principle: don't automate anything on day one.
Instead, we let users solve problems through conversation with AI. No wizards. No configuration. Just describe what you're trying to do, and the system helps you do it.
Here's what happens next. This is where it gets interesting.
As users solve real problems through conversation, patterns emerge. The system notices that you process invoices the same way every Tuesday. That your customer onboarding follows the same five steps. That your sales follow-ups have a rhythm.
At that point, and only at that point, the system asks: "I've noticed you do this regularly. Want me to automate it?"
The user clicks yes, and the conversation becomes a deterministic workflow. No LLM tokens. No inference costs. Just reliable execution of a pattern that was discovered, not prescribed.
The Three Phases
Phase 1: CONVERSATION
User describes problem -> AI solves it -> value delivered immediately
Phase 2: PATTERN RECOGNITION
System identifies recurring workflows from conversation history
Phase 3: DETERMINISTIC AUTOMATION
Proven patterns convert to zero-token execution
This isn't theoretical. DVERSI processes hundreds of workflows that started as conversations. The conversion rate from "discovered pattern" to "automated workflow" is significantly higher than the industry average for pre-configured automations, because the user already trusts the process. They watched it work before it became automated.
The Economics of Zero-Token Automation
Here's where the economics get compelling.
A typical AI agent platform charges per inference. Every time your agent "thinks" about what to do, you pay. At scale (say, processing 500 customer interactions per day) this adds up to hundreds of thousands of tokens per day. That's real money.
Now consider what happens when those same interactions run as deterministic workflows. The steps are known. The logic is fixed. The LLM isn't needed.
Token cost at runtime: zero.
The AI was only needed during the learning phase. Once the pattern is validated, you're running pure logic. The economics flip from "AI is expensive at scale" to "AI is a one-time investment that pays for itself."
This is what I mean by Zero-Token Automation: the end state where your AI system's most valuable workflows cost nothing to run because they've graduated from probabilistic inference to deterministic execution.
The Orchestrator-Specialist Pattern
Most AI systems today are monolithic. One model tries to do everything: understand context, make decisions, take actions, handle errors. This works for demos. It breaks in production.
The architecture that actually scales separates two distinct kinds of intelligence:
The Orchestrator understands what needs to happen. It reads context, identifies intent, selects the right approach. Think of it as the conductor of an orchestra, one that doesn't play any instrument but knows which one should play when.
The Specialists execute specific tasks. One processes invoices. Another handles email classification. A third manages calendar scheduling. Each is optimised for its domain, with its own context, tools, and error handling.
User Request
|
ORCHESTRATOR (understands intent, selects specialist)
|
+-----------+-----------+-----------+
| Invoice | Email | Calendar |
| Specialist| Specialist| Specialist|
+-----------+-----------+-----------+
|
Deterministic Workflow (if pattern exists)
OR
Specialist Execution (if new scenario)
The orchestrator uses intelligence. The specialists use capability. And the deterministic layer uses neither, it just runs proven patterns.
This three-layer separation is why systems built this way don't collapse under scale. You're not asking one model to be everything. You're asking each component to do what it does best.
Context as Competitive Moat
Features get copied. Pricing gets undercut. But context (the accumulated understanding of how your business actually operates) cannot be replicated.
Every conversation a user has with DVERSI builds an entity graph: who are the customers, how do they connect, what patterns repeat, what's the relationship between a Tuesday invoice run and Thursday payment processing. Over time, this graph becomes the most valuable asset in the system.
When a competitor tries to win the same customer, they're starting from zero. The customer would have to re-explain everything: relationships, preferences, edge cases, the "that's how we've always done it" context that took months to accumulate.
This is the Context Moat. It doesn't come from better algorithms. It comes from time spent understanding.
The Three Questions Every AI Leader Should Ask
Before your next AI investment, ask these:
-
"Are we automating a solved problem or an assumed one?" If your team can't describe the current workflow in detail, you don't have an automation problem. You have a process clarity problem. Solve first.
-
"What happens when the process changes?" If your automation breaks when someone changes a step, your architecture is too rigid. Build for discovery, not prescription.
-
"Where are our tokens going?" If you're paying for AI inference on tasks that have been done the same way 500 times, you're overpaying. Convert proven patterns to deterministic execution.
Looking Forward
AI orchestration is still in its earliest days. The market hasn't yet decided whether this is a feature (built into existing tools), a category (standalone platforms), or a layer (infrastructure that everyone needs).
My bet, and the bet we've made with Hundred Solutions, is that it's a category. One that will be defined not by the companies with the best models, but by the companies that best understand how humans and AI actually work together.
The future of AI isn't artificial intelligence. It's orchestrated intelligence: systems that know when to think, when to execute, and when to get out of the way.