Why Enterprise AI Agents Fail: It's a Structure Problem
When an enterprise agent gives a bad answer, the reflex is almost always the same: get a bigger model. Or a longer context window. Or bolt on another MCP server, another pile of .md files, another knowledge base.
Ishita Daga, a machine learning engineer at Tesla building enterprise agents, opened her AI Engineer talk Enterprise Agents Have a Structure Problem by naming that reflex and then dismissing it. Those are fair moves. They are not the fix. The agent's actual failures are structural, and no model upgrade touches them.
TL;DR — Enterprise AI agents fail for three structural reasons, not because the model is too small: ambiguity (which of these six sources is the truth?), staleness (this definition was right in March), and preference (Team A and Team B compute the same metric differently). The fixes are a ranked hierarchy of sources of truth, a context lifecycle with logging and evaluation, and — for preference — an honest admission that nobody has solved it yet. MDflow attacks the first two by making the ranking signal something you write in plain prose: folder descriptions are the primary retrieval signal, and every change is versioned and attributed.
Why enterprise AI agents fail
Because the inputs are unranked, out of date, and ambiguous about whose definition applies — and a bigger model just reasons more fluently over the same broken inputs. Daga breaks this into three problems, and most teams will recognize at least two of them immediately.
| Problem | What it looks like | Solved? |
|---|---|---|
| Ambiguity | Six knowledge bases, four tables, three .md files that all could answer the question. None is marked as authoritative. | Yes — with a ranked hierarchy |
| Staleness | The KPI definition changed in March. The doc still says the old thing. The agent believes it. | Yes — with a context lifecycle |
| Preference | Team A and Team B both compute "average milestone time," correctly, and get different numbers. | No — open research problem |
There is a good external check on this framing. The Spider 2.0 benchmark rebuilt text-to-SQL evaluation around real enterprise data environments — thousands of columns, multiple SQL dialects, actual warehouse sprawl. GPT-4o scores 86.6% on Spider 1.0 and 10.1% on Spider 2.0; even o1-preview manages only 17.1%. The models did not get worse at SQL between those two benchmarks. The environment got ambiguous.
Problem 1: ambiguity, and the hierarchy that fixes it
An agent cannot weight all your knowledge bases equally, so you have to rank them — from the cleanest and least flexible source to the messiest and most flexible one. The agent works down the list and stops at the first tier that can answer.
Daga's three tiers, from the top:
- The semantic layer. A curated set of KPI definitions, business terms, and canonical calculations. The agent finds the closest concept and reads the definition. Least flexible, highest trust — it answers only what someone has already curated, but it answers it correctly.
- Canonical tables and parameterized queries. A library of known-good query shapes the agent can adapt — pick the right one, fill in the filters. Wider coverage, a bit more room to get it wrong.
- The database graph. Every table wired to its columns, and every column wired to the metrics it can serve. Maximum flexibility, maximum coverage — and, in her words, the trickiest of the three, because it takes enormous effort to build and even more to keep current.
Her practical advice is the useful part: build tiers one and two first. They are cheap, and they cover about 80% of the questions. The graph is the last 20%, and you should not start there.
That ordering generalizes past data agents. The same logic applies to a coding agent facing an ADR, a wiki page, a Slack thread, and the code itself — or a support agent facing a help center, a runbook, and last quarter's incident review. Every one of those is a source-of-truth hierarchy you have not written down. The agent is inferring your ranking from vibes, and it is inferring it fresh on every call.
Which is why "just add more markdown files" makes ambiguity worse, not better. Ten unranked files are ten candidate answers with no tiebreaker. The format is fine. The pile is the problem.
Problem 2: staleness, and the context lifecycle
Context rots faster than anyone budgets for, and it rots silently. Definitions change. KPIs get redefined. A process gets a new approval step. The document that describes the old world sits there looking exactly as authoritative as it did the day it was written.
Humans handle this by pattern-matching on age — this wiki page is from 2023, let me ask someone. An agent has no such instinct. It retrieves the stale definition, treats it as ground truth, and reasons confidently from there. The output looks correct until somebody checks the assumption underneath it.
This is measurable. A June 2026 study by Christoph Treude and Sebastian Baltes, Context Rot in AI-Assisted Software Development, ran documentation-consistency checkers over 356 repositories and found stale code-element references in 23.0% of them — in exactly the CLAUDE.md, AGENTS.md, and .cursorrules files that are supposed to be the agent's ground truth. Nearly a quarter of the configuration files teams trust most are already lying about something.
Daga's answer is to stop treating context as a write-once artifact and give it a lifecycle with two parts.
Anchor on live sources
Wire the agent to sources that are updated as a side effect of work already happening — the repository, the CRM, the BI layer, the dbt project. These are maintained because someone's job depends on them being right, which is a far stronger guarantee than "someone will remember to update the doc."
The corollary matters: anything you cannot anchor to a live source is something you have to maintain deliberately, and you should know which documents those are. Most teams do not.
Close the feedback loop
This is the part almost everyone skips. Every time a human says "that table is wrong," "that definition changed," "you need to filter out internal accounts" — that is a maintenance event, and it should be logged, not just said out loud in a thread.
Then evaluate. Daga is blunt that teams under-invest here: without an eval suite you cannot tell whether last week's context edits helped. Two workable approaches, neither exotic:
- Human-annotated evals — a fixed question set with reviewed answers, run on a schedule.
- Automated regression — replay recent real questions and compare against known-good answers.
Log → evaluate → update → repeat. Without the loop, context management is a series of one-off fixes that quietly drift out of sync again.
Problem 3: preference, which nobody has solved
Two teams can compute the same metric, both correctly, and get different numbers — and the agent has no way to know whose definition you meant.
Daga's example is precise. Team A measures "average milestone time" from the completion of the previous milestone to the completion of the current one. Team B measures it from the start of the current milestone to the start of the next. Both are legitimate. They produce different answers. The question — "what's our average milestone time?" — is identical.
Neither existing tool fully solves this:
- A semantic layer can store every variant, but then the user has to specify which one, which just reintroduces the ambiguity problem one level down.
- Agent memory (mem0, a
memory.md) stores that you prefer something, but it does not encode the distinction between two valid metrics or when each applies.
What is actually needed, she argues, is routing: the agent resolves the right definition based on who is asking and which team they are on. That is an open problem, and it is worth flagging as one rather than pretending your architecture has handled it.
The practical mitigation available today is cheap and worth doing: write the disagreement down. If two definitions exist, a document that says "Team A means X, Team B means Y, and here is when each applies" is strictly better than a document that silently picks one. It converts a wrong answer into a clarifying question.
Which applications benefit most
- Data and BI agents — the talk's own domain. Text-to-SQL fails on what does this metric mean far more often than on SQL syntax; the Spider 2.0 numbers make that concrete.
- Coding agents in large repos — where
AGENTS.md, ADRs, and runbooks are the source-of-truth hierarchy, and the context-rot study says a quarter of them are already stale. - Internal support and ops agents — policies, escalation paths, and approval rules that change monthly and are documented in three half-current places.
- Regulated workflows — finance, health, insurance, where "which source, and is it current" is an audit question, not a preference.
- Any team with more than one agent — because unranked context is a cost each new agent pays again from scratch.
How MDflow fits
MDflow is a home for the top of the hierarchy — the curated, human-written layer — with the ranking signal and the audit trail built into the store rather than bolted on. It is not a data catalog and it does not run your evals, and it is worth being clear about both.
What already lines up today
Folder descriptions are the ranking signal, and you write them in prose. Every folder in MDflow carries a description stating what belongs inside it and what it is for. This is not decoration: mdflow_get_context over the MCP server ranks folder descriptions ahead of folder names and document titles, then returns the best-matching markdown bodies. That is a directly authored answer to the ambiguity problem — instead of ten equally-weighted files, you get a corpus where you have stated what each grouping is authoritative for. It is why folder descriptions are the feature that matters most for agents.
Workspaces scope the hierarchy. Each workspace has its own name, description, and folder tree, so an agent can be pointed at one coherent slice — one client, one product line, one domain — instead of ranking across everything you have ever written.
Version history and the Document Log make staleness visible. Every change is captured with a line-by-line diff and a non-destructive restore, and the Document Log names the actor on every write — including automated · <token name> for API and MCP writes. When a definition changes, you can see when it changed and who changed it, which is the minimum viable version of a maintenance event log. (Version history is a Pro feature and is deliberately private to the document owner — it is not exposed over the API or MCP.)
Live anchoring where the source already exists. The GitHub integration lets you edit markdown that lives in your repositories directly from a workspace and commit straight back, so specs and ADRs stay in the place that is already maintained. The web clipper pulls external pages in as clean markdown rather than as links that rot.
One store, every agent. The same knowledge is reachable from Claude, ChatGPT, Cursor, Codex, and Claude Code over the remote MCP server (OAuth or a Personal Access Token) and from anything else over the REST API. Documents are plain markdown, every shared page has a raw .md twin with YAML frontmatter, and discovery is published as llms.txt, docs.md, an OpenAPI spec, and an agent card.
What MDflow does not do. There is no technical ontology — it does not catalog your warehouses, hold schemas, or map concepts to columns. There is no built-in evaluation suite, no correction-event log distinct from version history, and no per-user preference routing. Tiers two and three of the hierarchy belong in a semantic layer or a graph; MDflow is the tier-one layer beside them. For the fuller version of that argument, see a semantic layer for AI agents.
Where we are headed
Direction, not a dated commitment. The interesting frontier for a markdown-native store is making the hierarchy explicit rather than implicit: descriptions that can express authority and freshness, not just membership; a way to see which documents an agent actually read when it answered; and scoped tokens so an agent's reach can be narrowed to the slice its job needs. The honest local version of the feedback loop — knowing what agents read, and whether it helped — is the piece we find most interesting.
The bottom line
The next model release will not fix an agent that cannot tell which of your six documents is authoritative, or that is reading a KPI definition from March. Those are structural problems, and they are solved with structure: rank your sources, start with the two cheap tiers, and give context a lifecycle instead of a launch date.
Preference is genuinely unsolved, and the useful move there is not to pretend otherwise — it is to write the disagreement down so the agent asks instead of guessing.
All three fixes have something in common: they are things people write, in prose, that both humans and models can read. Which is a good argument for keeping that layer in a format neither one has to fight.
Start free · Connect an AI agent · Read the API docs
Frequently asked questions
Why do enterprise AI agents give wrong answers?
Usually not because the model is too small. Three structural problems account for most bad answers: ambiguity, where the agent cannot tell which of several knowledge bases or tables is authoritative; staleness, where the context it reads was true six months ago and nobody updated it; and preference, where two teams define the same metric differently and the agent has no way to know whose definition applies. A larger model reasons more fluently over the same broken inputs.
What is a source-of-truth hierarchy for AI agents?
It is an explicit ranking of your knowledge sources from cleanest and least flexible to messiest and most flexible, so an agent consults them in order instead of weighting them equally. Ishita Daga of Tesla proposes three tiers: a curated semantic layer of definitions and canonical answers first, parameterized canonical queries and tables second, and a full database graph last. The first two tiers are cheap to build and cover roughly 80% of questions.
How do you stop AI agent context from going stale?
Give context a lifecycle rather than treating it as a one-time write. That means anchoring on live sources that are already maintained for another reason, logging every correction someone makes as an event rather than fixing it verbally, and running an evaluation suite so you can tell whether context edits made the agent better or worse. Staleness fails silently, so without evaluation you have no signal at all.
Does adding more markdown files make an agent more accurate?
Not on its own. Unranked markdown files add to the ambiguity problem, because the agent gets more candidate answers with no signal about which is authoritative. Markdown becomes an asset when the corpus is structured and ranked, when each grouping states what it is for, and when a maintenance loop keeps it current. The format is a good choice; the pile of files is not the strategy.
How does MDflow help with agent context management?
MDflow makes the ranking signal something you author in prose. Every folder carries a description that says what belongs inside it, and the mdflow_get_context tool ranks those descriptions ahead of folder names and document titles before returning matching markdown. Workspaces scope a slice of knowledge to one project or client, version history and the Document Log show who changed a definition and when, and the same store is reachable from any agent over MCP or the REST API. MDflow does not catalog databases or run evaluations for you.
Further reading
- Enterprise Agents Have a Structure Problem — Ishita Daga, Tesla (AI Engineer, July 2026) — the talk this post is built on.
- Spider 2.0: an enterprise text-to-SQL benchmark — the 86.6% → 10.1% drop, and why real data environments break agents that ace academic benchmarks.
- Context Rot in AI-Assisted Software Development — Treude & Baltes, June 2026; stale code references in 23.0% of 356 repositories' AI configuration files.
- MDflow: folder descriptions as agent context, a semantic layer for AI agents, context engineering for AI agents, from systems of record to systems of context, and connecting an agent over MCP.