Skip to content

The AI Model Is the Easy Part

Something interesting happened when Anthropic and OpenAI started rolling out their enterprise AI platforms. They didn’t go to the Fortune 500 first.

They went to the mid-market.

That’s not an accident. Mid-market companies can make a decision about new technology in weeks. A large enterprise takes months — if they decide at all. The AI capability is there. The organizational capacity to adopt it isn’t.

That gap is the real story right now. And for anyone working in or with large enterprises, it should be a little uncomfortable.

The companies I spend most of my time with — large, global, sophisticated — are watching AI move at a pace their internal structures weren’t built for. Governance cycles, procurement timelines, change management requirements, stakeholder alignment processes. None of it was designed for a world where the technology changes every quarter.

Meanwhile, a mid-market competitor with a fraction of the resources and none of the legacy infrastructure is deploying an AI-powered operation in the time it takes a Fortune 500 to get through legal review.

I’m not saying this to be provocative for its own sake. I’m saying it because it’s the most consistent thing I see in enterprise AI engagements. The technology isn’t the constraint. The organization is.

The model is not the hard part

Most enterprise AI programs fail not because they chose the wrong model. They fail because nobody thought hard enough about the three things that actually determine whether AI works inside a real business: the workflow it lands in, the people expected to use it, and the feedback loop that makes it better over time.

The model layer — data, features, algorithms — gets all the attention. It’s visible, measurable, and easy to put in a board update. But it’s the smallest part of the problem.

In a recent engagement with a global services client, the brief was simple: improve customer support with AI. Before we wrote a single line of model code, our team spent weeks with frontline support agents — watching how they worked, mapping where they stalled, understanding what “a good resolved case” actually meant in their language.

What we found was a workflow problem. Agents were moving between four systems to piece together context that should have surfaced automatically. They weren’t slow because they lacked intelligence — they were slow because their environment was fragmented.

The AI we built doesn’t replace the agent. It works alongside them: surfacing relevant tickets, suggesting responses in the team’s language, and flagging when context is missing. Adoption held. Automation rates climbed. The human connection customers expect didn’t erode.

None of that would have happened if we’d started with the model.

Trust is a design problem, not a communication problem

One of the fastest ways to lose momentum in an AI deployment is to give people an output they can’t understand and expect them to act on it anyway.

I’ve seen this happen in technically strong programs. The result might be directionally correct, but if the engineer, operations lead, or frontline manager can’t see why the system is making a recommendation, they either ignore it or follow it blindly. Neither is acceptable in production.

In a predictive maintenance pilot, we didn’t just surface a failure risk score. We paired each prediction with plain-language reason codes in the language of the people reading it — not ML jargon. “Abnormal vibration on Line 3 over the last 48 hours.” “Temperature spikes trending outside normal range.” Maintenance leads could cross-check the model against their own judgment. When the model was wrong, they told us — and that feedback made the system better.

Explainability isn’t a feature. It’s the trust condition. And trust is what separates AI that gets used from AI that gets shelved.

The loop is the product

The AI programs that hold up over time have one thing in common: humans are actively improving the model, and the model is actively improving human performance. A loop that runs itself.

In the support example, every response an agent accepts, edits, or rejects flows back into the training pipeline. For this engagement, teams in India maintain the loop. Quality reviews run jointly with leaders in the US and LATAM. What started as a single deployment has become a living system — one that reflects current products, current policies, and current customer language.

That’s not a deployment. That’s an operating model. And building it that way from the start is the difference between AI that compounds and AI that decays.

The three layers most teams only
engineer one of

When I explain this to clients, I keep it simple: every AI program has three layers, and most teams only invest in one.

The model layer — data, features, algorithms — is where most attention and budget goes. It’s also the easiest part.

The process layer is where AI actually fits into the workflow. Not adjacent to it. Not bolted on after the fact. Inside it. The design choices here — handoffs, approvals, escalation paths, feedback mechanisms — determine whether AI becomes operationally useful or just impressive in demos.

The people layer — roles, skills, decision rights, incentives — is the layer most teams underinvest in, even though it’s usually the one that determines whether a program gets adopted at all.

To move from pilot to production, you have to engineer all three. Deliberately. Together. That’s the framework we build around at Aditi, because it’s the only version I’ve seen that actually ships, sticks, and compounds.

The window is open, but it won’t stay open

Here’s the honest version of where enterprise AI is right now: the companies that figure out how to build the organizational conditions around AI — not just the models, but the processes and the people — are going to compound their advantage fast. The ones that keep running pilots without changing how work gets done are going to find themselves competing against leaner organizations that moved quicker.

Anthropic and OpenAI didn’t start in the mid-market because large enterprises don’t matter. They started there because the mid-market can move. The question for every enterprise leader is whether they’re going to find a way to move too — or wait until the gap becomes visible enough to be a crisis.

That’s the work we’re focused on at Aditi. Not selling models. Helping organizations build the operating conditions to make AI actually matter.

The model is the easy part. Everything that makes it work is not.

Carrick Carpenter, Chief Technology & AI Officer at Aditi Consulting, argues that the real challenge in enterprise AI is not the model itself, but the organizational conditions needed to make it work. Drawing from examples in customer support and predictive maintenance, he shows why workflow design, trust, and human feedback loops are what determine whether AI truly gets adopted, scales, and delivers lasting value.