In June, on the first day of the Snowflake Summit, roughly 30 of the 50 vendors on the expo floor were selling some version of a context layer. Then the second day arrived, and Snowflake announced one too, so you don't need any of those vendors after all.
That's the state of the category. Everyone agrees agents can only do real data work if they understand your business, your metrics, your schemas, your quirks, your history. Almost nobody agrees on who should provide that understanding. Everyone wants to be at the center of your data infrastructure.
I’ve spent the past few weeks comparing notes with data leaders on how they're solving this. Everyone from a healthcare startup who are building from scratch to an established F500 with existing infrastructure is deep in the vendor evaluations. Surprisingly, their stories were consistent.
What teams are actually doing
One team had taken intro calls with several context-layer vendors. Then, during an internal hackathon, they created a GitHub repo, dumped every .md file they had describing their data, and told Claude to read them before doing anything. It took five minutes, and agent accuracy jumped noticeably across their use cases.
They challenged every vendor since: "I just did something in five minutes. What are you really solving for here?" The answer is never clear. "Every problem they promised to solve," the team told me, "sounded like a problem we'd still have with their tool."
They're not an outlier. One enterprise software company I interviewed started early, in mid-2025: they wrote their definitions and domain knowledge into one of the early players promising to solve the problem of organizational context. And it worked. The accuracy of their data agent went from 14% to the low 90s. But the biggest gains came from simply writing the knowledge down. The hackathon team saw a similar jump with a folder of markdown files. Writing your context down pays off enormously; where you put it matters far less.
A lot of what's sold as a context layer is something else
Everyone wants in. But there are actually 3 archetypes that keep coming up:
Data catalogs & data platforms
Useful at scale: LinkedIn alone runs millions of internal datasets, of which maybe 10,000 matter, and an agent needs help narrowing that down. But filtering datasets is a catalog's job, not a context layer's.
Data pipeline tools
The ELT vendors are moving in too. They already sit on your sources, schemas, and syncs, so context looks like a natural add-on. But what a pipeline knows is how data moves — where it came from, when it landed, what shape it arrived in. That's useful plumbing, but it can't tell an agent which tables matter or what counts as revenue.
Knowledge bases
A place to describe entities, standard operating procedures, ontologies.
Sidenote: To this day, I don't get a good answer for why I need a graph database just to map out my context.
Context wants to live at the source
The stronger pattern: context is moving into the places that already hold the data and the logic.
The first place is the warehouse. Describe your columns where the tables live, and agents pick it up. Snowflake now ships semantic views. Databricks keeps building out Unity Catalog. BigQuery has its Knowledge Catalog. And emerging open standards mean one set of definitions can serve every tool that connects. For a new team, a standalone semantic layer increasingly looks like a middleman. Teams with an existing one have no reason to rip it out, but the friction is familiar: I need a new metric, it's not there, somebody has to go add it, and that's lag.
The second place is the codebase, and it might be the most valuable context of all. The hardest questions data teams get sound like this: "Why did signups drop on May 15th?" No semantic layer contains that answer. Git history does: on May 14th, someone shipped a new onboarding flow. Traditional BI tools had no practical way into your repos until recently; now agents can browse code and history on their own. For a software company, the repo is the richest description of how the business actually behaves — and it never drifts out of date, because it is the product.
The third place is usage itself. The most valuable signal about your data is in how your team actually works with it. If everyone fetches revenue from the same table, an agent should use that table too. Which dashboards get opened every Monday, which queries get rerun and trusted, which metric nobody has touched in a year: those patterns already sit in query logs and workspace analytics. Nobody has turned them into a first-class context source yet, but the raw material is already there.
Whatever you buy today will age fast
I was upfront with both teams: "I'm going to give you June 2026 advice. I'm not sure if it's going to hold in September 2026." Nobody has fully caught up with this space yet, and I wouldn't trust anyone who claims they have.
The team behind those accuracy numbers is a case in point. They built on an early tool designed when agents could barely handle a single MCP server. So the state of the art in 2025 was to funnel everything through one giant omnipotent MCP endpoint. A year later, agents write their own SQL, browse GitHub, and juggle as many tools as you give them. That architecture aged out in twelve months.
With the benefit of hindsight, this flaw seems obvious. But it wasn’t back then. Also, back then, the team needed a system that works, not a system they will start working on 12 months later.
The hard part is not buying a new tool, but collecting and writing down what you know into that tool. Simple Markdown in Git is beautifully simple. Once a clean solution emerges, an agent can migrate your files into it, and the switching cost stays close to zero.
What a folder of markdowns doesn't solve
Four problems are still wide open:
1. Curation
Human review never goes away. Definitions drift, duplicates creep in, someone ships a dashboard with its own idea of revenue. So we run a maintenance agent internally at Deepnote; every 24 hours, it reads every data source, markdown file, and definition, and flags what's stale or conflicting. The fancy features that vendors sell today, such as letting someone bless the canonical definition when duplicates appear, might just be a GitHub action on the context repo.
2. Goals
Context layers store facts, but they can’t help with the intent. When a CEO asks who the most important customers are to meet in London, they are thinking of a new pipeline. When a VP of Marketing asks the same question, they are thinking of logos and case studies. Agents will eventually pull intent from org charts and KPIs. Going from reactive to proactive thinking. Nobody has cracked this yet.
3. Traces
Every agent session leaves a record of how work actually happens; what was tried, what failed, what got used instead. When an agent makes a decision, it needs to be stored for compliance reasons. And the same trace becomes the goldmine for understanding how the organization actually works. If only it were that easy, though. This goldmine carries an unsolved permissions problem: who sees which traces, and what gets masked. Someone will become rich solving that.
4. Format
Markdown itself is showing its limits. As agent output gets richer (tables, diagrams, interactive views), plain text strains to hold it; it's part of why more agent-written documents now ship as HTML. And markdown has no native slot for permissions or metadata: nothing in a .md file says who may read it, which agent may run it, or where its numbers came from. And definitely no signs of enterprise-grade determinism.
Where Deepnote fits
My take: context shouldn't be a separate product you point at your stack. It should live inside the place where the work already happens — that's the bet we're making with Deepnote.
In Deepnote, every notebook you create automatically becomes context. You write a module called arr that captures how ARR is actually calculated — which Stripe subscriptions count, how currencies get normalized, where the edge cases hide — and agents read it like any other markdown file.
But a notebook is also a runtime for agentic work. The same knowledge base entry can fetch dbt artifacts on a schedule, cache results, carry lineage, and enforce rules about what an agent may touch. Static knowledge becomes knowledge with computation attached; skills become sub-agents, traceable and schedulable. You end up in a world where pretty much everything is executable markdown. That's what we're building toward, and it's why the .deepnote format exists: files that read like markdown but carry the metadata, permissions, and executable blocks a plain .md never will.
And as more analysis starts life in Cursor or Claude Code, Deepnote is where the resulting apps, dashboards, and pipelines live — where humans find, review, and share them, in sync with the tools agents work in.
If you're starting this quarter
Write your context down in markdown and keep it in a git repo. Describe your columns at the source. Give agents direct access to your code and your data. Add a scheduled agent that checks for drift. Don't overengineer your memory layer; reach for a graph database only when you can say why you need it. And expect to revisit all of it in 3-6 months — that's not a failure of planning, just the cost of building in the most interesting year the data stack has had in a decade.