Your AI Agent Doesn’t Know Your Business | Context Layers Explained

Your agent can write perfect SQL and still give you a confidently wrong answer — because nothing in your schema says what “churned”, “active”, or “in the shop” actually mean at your company.

At the MotherDuck DuckDB meetup in San Francisco (hosted by Uncork Capital), Bev Turnbaugh from MotherDuck’s customer team traces how we’ve tried to codify business meaning since the 1980s — data dictionaries, warehousing, governance, catalogs — and why agentic AI finally forces the issue. She breaks down the difference between a semantic layer (schema, joins, metrics) and a context layer (your institutional knowledge), surveys today’s options (Open Semantic Interchange, vendor solutions, RAG pipelines, rules.md files, dedicated platforms), and shows a sneak preview of MotherDuck’s approach: a context layer of guides that lives alongside your tables and gets surfaced automatically over the MCP server.

TL;DR

A ~32-minute talk-and-discussion by Bev Turnbaugh (customer team, MotherDuck) at a DuckDB meetup in San Francisco, published 24 July 2026. Roughly half the runtime is audience discussion, which she solicits continuously.

1. The framing claim: this is a forty-year-old problem that agents have finally made unavoidable. “This problem has existed since the 80s and I’ve been around a long time and I’ve heard them talk about this absolutely forever.” Her potted history: personal databases and defining your data in the 1980s; data warehousing in the 1990s once “we were collecting everything, every single click”; data governance in the 2000s, which Gartner called “the single most important aspect of computing for the century” — “yeah, well, that died”; data lakes and cataloguing in the 2010s; and “now we’re in the 2020s and we’re still talking about it.” Her prediction: “we’ll be talking about this when I’m long gone. Data is hard. Defining your data is hard.”
2. The distinction the talk exists to draw — semantic layer versus context layer. She notes the two are “conflated quite a bit.” A semantic layer is “pretty cut and dried… your schema, your joins, your table and column annotations.” A context layer “is a whole different animal — your definitions of business terms. It documents specific business knowledge.” Her illustration is the onboarding experience: a new hire writing their first board report is told “oh no, no, no, don’t include that guy, because that company has this problem… well, we have an exception for that.” “Where do you codify that? Where do you put that knowledge in?” — so that a natural-language query “doesn’t have the guy standing next to him.”
3. The failure mode is quiet, and she names it precisely. Asked what an LLM does when it lacks your business definitions: “It guesses. They don’t call it guessing. What word do you think they use? … They infer.” She looked it up: “according to the Cambridge dictionary, infer in fact means to guess. They have no other option. You haven’t given them any guidelines for what those terms mean to you.” Her worked examples are deliberately mundane — what “model” means to a home builder, what “class” means in your business, what “revenue” means — because that is where the wrongness is invisible.
4. On standards: the Open Semantic Interchange, and why she is sceptical. She asks the room what always goes wrong with standards and collects the answers: no one agrees; they’re stale by the time they ship; there are too many of them; and Gartner’s perennial one, adoption. The OSI spec was finalised in Q1 2026 and has “support across 50-plus platforms — but that’s support. That’s ‘oh yeah, that sounds like a great idea.’ And then the vendors go off and build their own product with their own specifications. And now we’re back to square one.” Her show-of-hands test — who has read the spec, who has incorporated it into their workflows — lands the point.
5. The vendor-lock-in argument, framed against Iceberg. Vendor semantic products are “tightly coupled with their solutions, takes advantage of all the infrastructure of the product… What happens when you want to leave?” She catches the inconsistency in the room directly: people who adopted Apache Iceberg precisely for vendor independence and open format are simultaneously “tying all of my semantic stuff to this ETL tool I’m using.” The OSI pro she credits is structural — “it separates what a metric means from where it is run. It makes it like Iceberg.” The con is that “you simply can’t get people to adopt it.”
6. Her critique of skills files, which is the most transferable idea in the talk. She asks the room what humans are notoriously bad at, collects answers (prioritisation, consistency, time estimates, multitasking, naming things), and supplies her own: remembering. Her grocery-store analogy lands it. The consequence for skills-style context: “my concern with skills is you have to remember to use them.” She describes a competitor’s context layer where “you have a slash and then you have to hunt for the skill that you want the LLM to use. I’m like, that ain’t going to work. … You have to have a way that forces your LLM to use those skills. You can write skills — because it’s a really good way of documenting that institutional knowledge — but how are you going to get people to remember to use them?” This is an argument about invocation, not authoring, and it is the criterion she then uses to justify MotherDuck’s design.
7. MotherDuck’s approach — “guides.” Quoting the product lead: “a context layer that lives alongside the tables in MotherDuck, so the right knowledge gets surfaced automatically when an agent touches the relevant data, and can be updated both implicitly and explicitly.” V1 properties as described: stored natively in the database (though loadable from GitHub); one guide per database, which she pitches at customer-facing analytics companies that run a database per customer; creatable, updatable, movable and visibility-changeable from SQL; agents can author them; and personal versus org scoping. The scoping design carries two ideas she likes: an admin can watch what individuals put in personal scope and promote it to org scope, and an agent learning from query patterns can write its own observations into personal scope where “it won’t touch your orgs,” leaving a human review step.
8. What a guide contains. Term-and-meaning pairs (what “churn,” “contraction,” “expansion” mean here), fiscal-calendar definitions — “if you’re not on a calendar quarter and you tell Claude to go off and give you the quarterly results, what’s he going to do? January, February, March…” — plus gotchas (“for this customer, remember they play golf; he gets an automatic discount”), where the data lives, and optionally the finished SQL. She flags the maintenance question herself: “and then what happens when your schema changes?”
9. The retrieval path. User asks a natural-language question → agent calls get_guide / looks for guides.md on the MotherDuck MCP server → receives the tree of existing guides and custom instructions → “now it doesn’t have to infer or guess.”
10. Two audience exchanges that are the most valuable part of the discussion. Asked what happens when a question concerns a metric not in the guide, so the agent falls through to base tables, her answer is a rule rather than more content: “I personally would actually have a rule in my context layer that says if you don’t know what I’m talking about, do not infer — come back and say [you don’t know].” She frames this as her single biggest ask of agents generally: at a panel asked what your agent can’t do that you wish it could, “do you know what my answer was? Say I don’t know. … I don’t want it to guess. I don’t want it to hallucinate. I don’t want it to make me look bad if I take its answer and give it to somebody.” She also describes watching the agent’s tool calls live rather than tabbing away — “I watch exactly who it’s talking to, exactly where it’s pulling data, and then I’ll go, oh yeah, he has no clue, look at all these sources he’s looking at and he can’t find an answer” — as the signal to go fix the guide. The second exchange is an unanswered open problem she explicitly asks the recording to capture: context bloat, and whether tooling could recommend when a guide entry should be split out, moved up the stack, or fetched on demand rather than held in the window. Her answer: “no, that’s a really good point.”

What was actually ingested

The full auto-generated (ASR) English caption track (299 segments, consistent with duration: 31:42 / length_seconds: 1902). All 10 chapter markers present. This is a meetup talk with heavy unmiked audience participation: several questions and answers are partially inaudible or ambiguously attributed in the captions, and Turnbaugh repeats most questions for the recording — where she does, the summary above follows her repetition. Slides are referenced throughout (the semantic-versus-context comparison table, the example guide, the MCP sequence diagram) and are not captured. The preceding talk by “Jim,” which she says laid the groundwork, is not part of this video.

Dynamic-capabilities tagging

• digital-transforming/improving-digital-maturity — the whole talk is about a maturity prerequisite: the institutional knowledge that currently lives with “one guy in the corner cube that’s been there forever… he knows where all the bodies are buried” has to become machine-readable before natural-language querying is trustworthy. The proposed mechanism — guides stored beside the tables, versioned, org- and personally scoped, surfaced automatically over MCP — is an infrastructure answer to a maturity problem, and the forty-year lineage she traces (data dictionaries → warehousing → governance → catalogues → context layers) frames it as the current instalment of a long-running capability build rather than a new one.
• contextual/internal-barriers — she names two barriers explicitly and treats both as more binding than model capability. The first is standards adoption: OSI has 50-plus platforms’ support and near-zero uptake in the room, “and then the vendors go off and build their own product.” The second is human memory: skills-style context that requires a person to remember to invoke it will not be invoked, which is why she treats automatic surfacing rather than authoring as the design problem.

Linked entities and concepts

• WorkLab — the same context-layer-as-prerequisite argument at enterprise-strategy altitude; see this source’s relationships:.
• Ebbelaar — retrieval mechanics against the semantics retrieval runs over.
• knowledge-graphs — the semantic-layer/context-layer distinction, and the argument that schema-and-joins metadata is necessary but not sufficient for a correct natural-language answer.
• agent-harness — automatic surfacing over MCP rather than user-invoked skills is a harness-layer design decision, and her “say I don’t know” rule is a harness constraint rather than a model capability.
• enterprise-ai-adoption — the forty-year lineage of failed attempts to codify business meaning, and the vendor-lock-in-versus-open-standard tension applied to the semantic layer.
• responsible-ai — the confidently-wrong failure mode (“they infer”), and watching tool calls live as the practitioner’s detection method.
• knowledge-architectures-for-llm-agents — the context layer is a fourth architecture alongside the RAG / LLM-wiki / fat-skills trio that synthesis compares, and her skills critique is a direct argument against one of them.
• dynamic-capabilities — the two cells tagged above.

Dangling (single-source mention, deferred per author-entity promotion): MotherDuck as a publishing channel and as the vendor whose product is previewed (first appearance; promote on a second source), Bev Turnbaugh, DuckDB, Uncork Capital, Open Semantic Interchange.

Source quality note

Auto-generated transcript from a live meetup; proper nouns corrected at acquire time (MotherDuck, Databricks, Snowflake Summit, guides.md, get_guide — see the raw file’s notes:).

This is vendor content with an unusually visible product pitch: roughly the back half previews an unreleased MotherDuck feature (“this product is being released imminently”), and the competitor whose slash-command context layer she criticises is identified only as “a data warehouse that we compete with… it’s really cold” — an unnamed target the wiki cannot check. The historical framing and the skills-invocation critique stand independently of the product; the claimed properties of guides are pre-release vendor description with no deployment evidence, no scale figures and no failure cases. She is candid that the design is provisional (“V1 is coming out, but lots of room for improvement on V2 should it be necessary”) and repeatedly solicits objections, which is a better epistemic posture than the format usually produces. The audience-reported experience with RAG pipelines (three respondents, all broadly positive, all with caveats about documentation versioning and startup-scale corpora) is anecdotal and self-selected.