Talk by Ishita Daga (Senior Machine Learning Engineer, Tesla) on why enterprise AI agents fail: models can generate SQL and call tools but lack understanding of how a business defines its data. The talk argues that longer prompts, more RAG, or bigger models are not the fix; instead it presents semantic retrieval infrastructure — a machine-readable metadata layer — enabling business-context-aware agents via semantic retrieval, metadata graphs, and domain-specific sub-agents. # Channel Presentation Observations — "Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla" ## Explicit Self-Description by the Creator - **Speaker's stated role and employer:** The speaker introduces herself directly: > "I'm Ishita Daga. I work as a machine learning engineer in Tesla, and I'm building enterprise agents for our organization." - **Stated scope of the talk:** A framework-oriented technical talk on why enterprise data agents fail, framed around three named problems: **ambiguity**, **staleness**, and **preference**. - **Personal opinion framing:** The speaker repeatedly signals that the framework is her perspective rather than official doctrine — e.g., "In my opinion, the source of truth actually is a hierarchy…" and "which is something that I'm trying." ## Intended Audience - **Practitioners building enterprise data/ML agents**, evidenced by assumed familiarity with terms used without definition: *semantic layers, DBT, Tableau, MCP servers, .MD context files, canonical queries, KPIs*. - **Enterprise decision-makers** are addressed indirectly: > "if an enterprise is approaching or adding sources of truth, they should start adding the first and the second layer first." - The audience is presumed to already operate agents, since the talk opens from the failure point: "when an agent gives a bad answer, the first reflect [reflex] that we have is that we need a bigger model…" ## Claimed Scope of Content - **Problem diagnosis:** Three failure modes for data agents — ambiguity (which source of truth), staleness (context lifecycle), preference (team/individual metric preferences). - **Proposed framework:** A three-tier source-of-truth hierarchy (semantic layer → canonical tables → database graph), a **context lifecycle** (live data sources + feedback loop of logging, evaluation, and updates), and partial approaches to preference (semantic layer storage vs. agent memory). - **Honest open-problem acknowledgment:** The speaker explicitly states preference remains unsolved: > "still an open-ended problem but yeah, I think something we should work on or research on a bit more." ## Observable Presentation Patterns (Not Creator Claims) - **Practitioner-grounded tone:** Advice is delivered from hands-on experience ("a lot of teams do not focus on evaluation that much, and which is why the agents actually fail so often"). - **Concrete examples:** A team A vs. team B average-milestone-time example illustrates the preference problem with realistic enterprise detail. - **Structured delivery:** The talk follows a clear enumerate-and-solve format (problem → framework → conclusion), consistent with a conference/meetup technical presentation format. ## Identity Signals Available - **Title metadata** attributes the talk to a named speaker with employer affiliation ("Ishita Daga, Tesla"), suggesting the channel hosts **named-industry-practitioner talks** rather than solo creator commentary — though this is a single video, so it is evidence only of this video's presentation, not confirmed channel-wide practice. # Delivery Observations: Ishita Daga — "Enterprise Agents Have a Structure Problem" ## Tone & Register - **Conversational but structured**: an informal talk style with a clear three-part roadmap. Uses soft hedges like "I feel" frequently: - > "So, ambiguity, I feel, is one big problem." - > "I think there are a lot of ways you can do that" - **First-person framing of opinions**: consistently presents recommendations as personal judgment rather than authoritative claims — "In my opinion, the source of truth actually is a hierarchy." ## Vocabulary & Recurring Phrases - **Repeated key terms** anchor the talk: *"source of truth"*, *"context"*, *"knowledge base"*, *"metric"*, *"semantic layer"*, *"preference"*, *"ambiguity"*, *"staleness"*. - **"I feel" / "I think"** appear repeatedly as preambles to judgments ("I feel is the most trickiest", "I feel creating this feedback loop"). - **Meta-labeling device**: explicitly names each problem right after introducing it: - > "One is ambiguity." - > "Second is staleness." - > "The last one is preference." ## Teaching Habits & Structure - **Numbered, enumerated structure** throughout: three problems, then three "buckets" of sources of truth, two components of the context lifecycle, two proposed solutions for preference. - **Signposting transitions** between sections: - > "Moving on to our second problem, which is tailness." *(note: transcript renders "staleness" as "tailness" here — likely a transcription artifact)* - > "The last problem is preference" - **Concrete illustrative example** for the abstract "preference" concept — Team A vs. Team B calculating average milestone time differently — grounding a subjective problem in a tangible scenario. - **80/20 heuristic** to give practical prioritization advice: - > "These are easy to set up, solve I think 80% of the problems, and then the 20% can be solved by the database graph." - **Honest limitation-stating**: repeatedly flags what proposed solutions *don't* solve: - > "So you can solve it but still is not storing the preference of the user." - > "It stores your preference but it can't understand the distinction between two different metrics." ## Communication Patterns - **Openness about unsolved problems**: explicitly frames preference as open research rather than pretending a solution: - > "still an open-ended problem but yeah, I think something we should work on or research on a bit more." - **Self-corrections mid-sentence** (observable filler/repair speech): - > "These are most of the parametric tables or um queries, sorry." - > "who what what a team or which individual" - **Filler words** ("um", "uh", "like", "sort of") occur regularly, indicating an extemporaneous delivery style rather than a read script. ## Uncertainty Notes - Timestamps are coarse (10-second blocks); exact delivery pacing cannot be observed from this transcript alone. - "tailness" at [343] is most plausibly a transcription error for "staleness" given the surrounding explanation ("the context gets rotten"); this cannot be confirmed without audio. - No nonverbal delivery features (gestures, slides, audience reaction) are observable from the transcript. # Observation Document: "Enterprise Agents Have a Structure Problem" — Ishita Daga, Tesla ## Speaker - **Ishita Daga**, machine learning engineer at Tesla, building enterprise agents for the organization (per transcript self-introduction). ## Central Thesis - Enterprise data agents fail not primarily due to model limitations, but due to three **structural problems**: **ambiguity**, **staleness**, and **preference**. - Common reflexes (bigger models, more context, more .md files, knowledge bases, MCP servers/plugins) are "fair solutions" but, per Daga, do not actually improve the agent itself. ## Problem 1: Ambiguity **Claim:** The agent cannot determine which table, column, data source, or knowledge base is right, which holds the source of truth, or which is most flexible. **Proposed framework:** Source of truth is a **hierarchy**, from cleanest/least flexible to messiest/most dynamic; questions should be answered starting from the cleanest source. Three buckets: 1. **Semantic layer** — best source of truth; curated KPIs, metric calculations, business definitions. Agent finds the closest KPI and references its data points. 2. **Canonical tables** — lists of parametric queries; gives the agent flexibility to choose or write its own queries/filters; answers a wider question set. 3. **Database graph** — connect tables to columns and to answerable metrics. Most flexible but most effortful and hardest to maintain. **Recommendation:** Enterprises should start with layers one and two — "easy to set up, solve I think 80% of the problems" (qualified as her opinion); the database graph covers the remaining ~20%. ## Problem 2: Staleness **Claim:** Context deprecates quickly — decisions, KPI definitions, and processes change too often to maintain .md files or skills manually. **Proposed solution: a context lifecycle** with two components: - **Live knowledge sources** — always-updated, reviewed, curated (e.g., GitHub, CRM tools, Tableau, DBT, semantic layers); mandatory and frequently updated. - **Feedback loop** — - **Log events**: user reports of incorrect databases/definitions, new metric calculations, new filters. - **Evaluate**: curated suites with human-annotated questions/human evaluation, or automated evaluation comparing recent answers against prior actual answers. **Claim:** Many teams underinvest in evaluation, which is why agents fail — without tracking performance, "you don't know how the agent is progressing." A recurring log-evaluate-update loop is essential. ## Problem 3: Preference **Claim:** Teams and individuals legitimately calculate the same metric differently; capturing this subjectivity is hard. **Example (as given):** Team A computes average milestone time from *previous milestone completion* to *current milestone completion*; Team B from *current milestone start* to *next milestone start*. Both are correct but yield different answers. **Claimed state of solutions (both incomplete, per Daga):** - **Semantic layer storing multiple metric variants** — user must prompt which to use; doesn't store user preference, and reintroduces **ambiguity** (agent doesn't know which metric is right). - **Agent memory** (e.g., mem0, memory.md) — stores preferences but can't distinguish between two metrics or decide which to use when. **Open problem:** Daga states the industry has no correct answer; the goal is routing the agent to the right metric based on which individual/team is using it — requiring "creating a hive mind for your data agent." ## Preserved Qualifications - Framing is explicitly opinion-based: "In my opinion, the source of truth actually is a hierarchy"; the 80/20 split is "I think." - Preference is repeatedly labeled an **open research problem** with no settled solution. - Contradiction acknowledged internally: the semantic-layer fix for preference reintroduces the first problem (ambiguity). ## Conclusion (as stated) Solving enterprise agents requires: better **structure** (ambiguity), better **context management and evaluation** (staleness), and embedding **individual preference** (open-ended). # Video Attribution & Provenance Record ## Video - **Title:** Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla - **ID:** `01a15ca8-7320-7911-9ab7-0d69ed0e1b87` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Ishita Daga** | **Creator / Presenter (sole speaker)** | Self-introduction: "I'm Ishita Daga. I work as a machine learning engineer in Tesla, and I'm building enterprise agents for our organization." | - **Narrator/Guest:** None present. No other speakers appear in the transcript. ## Speaker Affiliation - Ishita Daga states she works as a **machine learning engineer at Tesla**, building enterprise agents for the organization (per transcript; affiliation is speaker-claimed). ## Referenced Sources & Tools (mentioned, not cited as evidence) - **Knowledge/context sources:** `.MD` files, documents, MCP servers, plugins, knowledge bases - **Live data sources:** GitHub, CRM tools, Tableau, DBT, semantic layers - **Named technologies/techniques:** semantic layer, canonical tables, database graph, agent memory (**mem zero** / memory `.md`) ## Third-Party Claims - Speaker claims frontier labs and industry teams are actively working on the "preference" problem — **generalized claim, no specific parties named**. - Speaker presents opinions explicitly framed as her own ("I feel," "in my opinion") throughout. ## Promotional Segments - **None detected.** No product, service, or sponsor promotion is present in the transcript. ## Availability & Limitations - **No curated metadata supplied** — no description, comment availability, or timestamps provided. - **No timestamps** available in transcript; provenance cannot be located by time. - **Comment availability:** Unknown / not stated. - Transcript is a single continuous talk; no segment boundaries identifiable. Hello everyone, and welcome to my talk, Enterprise Agents Have a Structural Problem. A quick introduction about myself. I'm Ishita Daga. I work as a machine learning engineer in Tesla, and I'm building enterprise agents for our organization. Before we get into the framework and the solution space, I actually want to talk about why these agents fail in the first place. So, when an agent gives a bad answer, the first reflect that we have is that we need a bigger model, we need a the latest model, we want a model with a lot of context so that it can hold a lot of information, or we need to add a lot of knowledge base in terms of dot MD files, documents, or MCP servers, plugins, etc. But, while all of these are fair solutions, they're not the answer to actually improving the data agent itself. Model The agent actually has these three main problems. One is ambiguity. So, it doesn't know what table is right, what column is right, which data source, or which knowledge base to access when, which one holds the source of truth, or like the cleanest information, which one is just a bit more flexible. So, we have a lot of these knowledge bases, but it's not defined which one is the best, um, or which one to use when. So, ambiguity, I feel, is one big problem. Second is staleness. We all know context updates so quickly. Um, a lot of decisions change, a lot of definition, KPIs, they change so often. Processes, they get updated so often. But, to keep our data agents accurate, we need to update this context, this context life cycle. And that's a second part of the problem. The last one is preference, which is more so capturing an individual or a team preference on what metric to use to answer a specific question, how to use a query, or what filters to use in a query. Although we have like a canonical query, let's say, each team has a different preference on what filters or what definitions to use. So, this I feel is very open-ended problem, still needs a lot of research, a lot of um industries or the frontier labs are actually working on solving this one. So, let's start with the first one, ambiguity. The agent needs to understand what source of truth to use, or what knowledge base to use. It can't weight all the knowledge bases equally. There has to be a bit more structure to the one it chooses to answer a particular question. In my opinion, the source of truth actually is a hierarchy, which goes from the cleanest, least flexible source of truth to the messiest, uh but most flexible, most dynamic source of truth. And the way to answer any question is to start from the cleanest to the messiest or the most dynamic one. We have divided in the sources of truth in three different buckets uh for this framework. The first one being the semantic layer, which is the best source of truth, a very curated list of all the different queries, KPI definitions, metric uh or how to calculate the metric, um the business definitions, and everything combined into just one semantic layer, which the model can use to answer a query. So, the agent just looks into the semantic layer, finds the closest KPI, and references all of these different data points from that KPI to actually give you an answer. The second part is canonical tables. These are most of the parametric tables or um queries, sorry. Where you give the agent all of a list of different parametric queries, and it sort of tries to understand which ones can it use to actually answer your question. It gives it a bit more flexibility in choosing or writing its own query or its own filters, etc. And it can answer a bit more wider set of questions. The last one is the database graph, which I feel is the most trickiest because it takes a lot of effort, but it gives you a lot of flexibility in the kind of questions that can be answered. So, the idea here is you connect each table to all the different columns uh each table to the metric that can be answered through this table and vice versa and sort of create this um enormous database graph that can be served to the agent and it can answer or query on top of it. Well, it is tricky, it is also very difficult to maintain or update. So, I feel if an enterprise is approaching or adding sources of truth, they should start adding the first and the second layer first. These are easy to set up, solve I think 80% of the problems, and then the 20% can be solved by the database graph. Moving on to our second problem, which is tailness. I think the word speaks for itself. But, the context gets rotten, or it gets deprecated, or processes change so often that it's hard to maintain dot MD files, or keep on updating your skills with the most latest context. It's just not easy, and we need a better solution for that. My answer to this problem is creating a context life cycle, which basically has two different components. The first one being embedding life data sources, or knowledge sources. By life, I mean something or the data sources that are going to be always updated, would be reviewed and well curated, and always provide the newest, or the most up-to-date data. This can include your GitHub, your um CRM tools, your Tableau, or DBT, semantic layers, whatever you want to include can be there, but it has to be a mandatory data source, like a a data source that is updated most often. The second part is a feedback loop, which is something that a lot of enterprise or data agents actually miss. The idea here is you should be able to log each and every uh event. And by event, I mean whenever someone says that this database is incorrect, or this definition definition is incorrect, or updated, or there's a new way to calculate a metric, or the there is a new filter that you need to use. All of these events need to be captured, logged, and used to update your data agent context. Once you have captured these events, the second part is to actually evaluate your data agent, and you can do that by either curating an evaluation suite with human annotated questions or human evaluations, or you can create an automated evaluation where you see all the questions that have been asked in the last couple of days and the actual answers and how close the new answers are to the actually the actual answers. So, I think there are a lot of ways you can do that, but a lot of teams do not focus on evaluation that much, and which is why the agents actually fail so often because you don't know how the agent is progressing or how is the performance. You don't keep a track of that. So, I feel creating this feedback loop or a context loop where you log, evaluate, update the context every or every so often is very important. The last problem is preference, which is a very subjective problem because preferences they change very often in terms of what kind of metric should be used, what's the right calculation. Different teams will calculate the same metric differently or um use the same query but different filters. So, there is a lot of subjectivity which needs to be captured, but it's very hard to do that on individual or team level. To give an example, um so, let's say there is team A and team B, and they don't both want to calculate the average time uh taken for a particular milestone. Team A calculates it by looking at the previous milestones or completion of the previous milestone to completion of the current milestone, while team B actually looks at the start of the current milestone to the start of the next milestone. So, while both of these are correct metrics or the correct way to calculate the metric. They both will give you very different answers and it's just about preference. We just need to understand what an individual mean when they say what's the average milestone time. So while this is a great question, I feel the industry still does not have a correct answer or correct way to solve the problem itself. I feel like there are sort of two ways to solve it. One is a semantic layer, which is something that I'm trying. Wherein you store all the different ways to calculate a metric as a semantic layer and then the individual sort of can prompt the model which one do they want to use. So you can solve it but still is not storing the preference of the user. And the second thing is you again bump into the first challenge, which is ambiguity. The agent doesn't know which metric is the right one. You still have to prompt it. Second part is agent memory, which is your mem zero or like storing memory.md file, but it still is not the best way. It stores your preference but it can't understand the distinction between two different metrics or which one to use when. So I feel there are ways to solve it but none of the ways are actually solving the preference problem itself. What we actually want is a way to route the agent to the right metric based on who what what a team or which individual is using that agent. So still an open-ended problem but yeah, I think something we should work on or research on a bit more. Which brings us to the end of this presentation. So just to conclude, I feel there are these three big problems, ambiguity, staleness, and preference. And what we really need to solve for is a better structure, a better way to manage the context and evaluate the context. And then preference, which is such an open-ended problem. It requires not just understanding how the agent works, but also embedding an individual preference, like creating a hive mind for your data agent. That's about it. Thank you so much.