← View All Insights
AIEnterprise

Your Data Is Fine. Your AI Doesn't Know What It Means.

2026-03-27·4 min read

Enterprise AI investment tripled to $37 billion in 2025. The results don't match the spend. MIT found that only about 5% of enterprise AI pilots achieve rapid revenue acceleration. S&P Global reports that 42% of companies abandoned most of their AI initiatives — up from 17% the year before. RAND puts the overall AI project failure rate at over 80%.

The industry blames data quality. Every survey names it the number one obstacle. But MIT identifies something deeper: not a data problem, but an adaptation failure. Generic AI tools work for individuals but stall in enterprise use because they don't learn from or adapt to specific workflows.

Clean data is not the same as understood data.

The technician that wasn't there

Consider a service management ERP. A maintenance record has an "assigned technician" field. The AI reads it, finds it empty, and tells the user no technician was assigned.

In reality, that field is never populated. The actual technician can only be found through time-booking records filtered by a specific work-order type. The data is perfectly clean. The AI simply doesn't have the interpretation layer to know that this field is a dead end.

This is a data interpretation problem, not a data quality problem.

The market solves the wrong thing

The response follows a consistent pattern: solve the transport problem. RAG embeds documents in vector stores — useful for policy questions, useless for live operational queries. Text-to-SQL translates natural language to syntax, but doesn't know that a "type" field needs a specific numeric code or that certain schema fields are dead ends. Vendor-built AI has platform knowledge but mostly serves standard workflows — not free natural language access across domain-specific data models.

In all cases, knowledge lives in infrastructure layers — vector stores, prompt templates, governance dashboards — rather than in the tool interface where the LLM actually reasons at call time.

Skills: cookbooks at the door

Anthropic's skills guide diagnoses the problem correctly — users connect an MCP server but don't know what to do next — and prescribes a client-side "knowledge layer" of markdown recipes. The diagnosis is right. The prescription treats the symptom.

Skills exist because MCP servers are Level 1. If the server already taught the agent what the data means, when to use which tool, and how to chain calls, there would be nothing left for the skill to teach. The kitchen has no recipes, so they hand out cookbooks at the door.

And client-side knowledge reintroduces the problems it claims to solve: it goes stale when the server updates, fragments across clients and versions, and only helps the one client that loaded it. A skill uploaded to Claude doesn't help the same server when connected to Cursor, Copilot, or a custom agent.

Why nobody builds the missing layer

Four reasons.

Developer mindset. "I make the API available, the LLM is smart enough to figure out the rest." For GitHub or Slack, this works — the model knows what a pull request is. For a mid-market ERP with industry-specific type codes? None of that is in any model's training data.

No complex domain. Most MCP servers wrap well-understood APIs. A GitHub server doesn't need to explain what a commit is. An ERP server does need to explain what a service ticket (type 10) means versus a maintenance order (type 13) versus a service planning (type 48).

No feedback loop. Most builders ship and move on. They don't have power users hitting limits daily, revealing which metadata is missing and which interpretations lead to wrong answers.

New technology. MCP is still maturing. The idea that a tool description could contain multi-paragraph domain knowledge simply hasn't occurred to most builders yet.

The fix isn't a different transport or a client-side knowledge layer. It's filling existing servers with domain intelligence — directly in the tool descriptions and schemas where the agent actually reads it.

I mapped out six maturity levels to make sense of this gap. For the full pattern behind getting from Level 1 to Level 4 — including the five-phase method and the feedback architecture — grab the white paper.