a16z Just Described What We've Been Building
Andreessen Horowitz published their thesis on why data agents need a context layer. Canonical entities, identity resolution, tribal knowledge, governance. We've been building exactly this.
Andreessen Horowitz just published "Your Data Agents Need Context", and it reads like a description of the product we've been building.
Their thesis: enterprise data agents are failing because they lack a context layer. Structured knowledge about business definitions, entity relationships, and organizational logic that agents need to do useful work. Without it, agents guess. They hallucinate. They produce answers that are technically plausible but operationally wrong.
This isn't news to us. It's why SixDegree exists.
The Problem, Precisely Stated
a16z illustrates the failure with a simple question: "What was our revenue growth last quarter?"
Two challenges show up immediately. First, "revenue" isn't a single number. Is it ARR? Run-rate? Which product lines? What fiscal calendar? Second, the data lives in multiple systems (fct_revenue, mv_revenue_monthly, spreadsheets owned by finance) and no one has designated which is authoritative.
This is a data analytics example, but the same pattern shows up everywhere. It's 2am and a critical CVE drops. Your security team needs to know: which services use the affected library, which of those are internet-facing, who owns them, and who's on call right now? That information exists across GitHub, Kubernetes, PagerDuty, and Slack. No single system holds the relationships between them. So someone starts a Slack thread and begins doing archaeology.
Or a key engineer leaves. Three critical services just lost their only maintainer. Who knows enough to pick them up? Which customers depend on those services? Is anyone managing those relationships? The answers require connecting HR data, service ownership, customer accounts, and team topology.
a16z nails it: agents fail not because LLMs are incapable, but because the structured context they need to reason correctly doesn't exist in any accessible form.
Their Framework, Our Architecture
The article proposes a five-layer architecture for a modern context layer. It felt like reading our own design docs.
Data Accessibility. a16z calls for consolidated access across warehouses and "tribal knowledge repositories" like Slack, Google Drive, internal wikis. SixDegree does this through integrations. Each one connects to a system of record (GitHub, Kubernetes, AWS, Jira, LDAP, HubSpot) and continuously discovers entities and relationships. Not periodic batch imports. Live discovery from actual system state.
Automated Context Construction. They describe using LLMs to analyze query history, table relationships, and existing definitions to build initial context. We do something similar but grounded in system topology rather than query patterns. When an integration discovers a Kubernetes deployment, it maps relationships to the namespace, the cluster, the container images, the source repos. The context isn't inferred from usage patterns. It comes from the systems themselves.
Human Refinement. a16z emphasizes capturing "implicit, conditional tribal knowledge." Stuff that lives in someone's head, like "use Affinity for 2025+ USCAN deals, Salesforce for pre-2025 global leads." We handle this through skills: codified organizational workflows that encode decision logic on top of the ontology. The ontology provides the structural truth. Skills layer human judgment on top.
Agent Connection. They call for real-time exposure through APIs or MCP. This is our primary interface. Every entity and relationship in SixDegree is queryable through MCP, so any agent framework (ADK, LangChain, a raw Claude API call) can traverse the ontology natively. No special integration needed. Just MCP, the same protocol the agent already uses for everything else.
Self-Updating Flows. The article describes a "living corpus" that reflects upstream changes. This is table stakes for us. Integrations run continuously. When a new service deploys to Kubernetes, when a team member changes in LDAP, when a repository is archived in GitHub, the ontology updates. An agent querying SixDegree at 2pm sees the world as it exists at 2pm, not as it existed when someone last ran an import script.
Where We Diverge
a16z positions the context layer primarily through a data analytics lens: semantic layers, metric definitions, BI tool integration. Fair enough. But the problem is bigger than analytics.
The article gets at this when they mention "canonical entity definitions" and "identity resolution logic" as components of a context layer. These aren't data warehouse concepts. They're ontological primitives. An entity isn't a row in a table. It's a node in a graph with typed relationships to other entities across systems.
When SixDegree discovers a GithubRepository, that entity has relationships to KubernetesDeployment entities, Team entities, JiraProject entities. Those relationships are first-class, queryable, and typed. An agent can traverse them. "Find all internet-facing services that depend on libraries with critical CVEs, identify the owning teams, and check if those teams have on-call coverage this week." That query crosses four systems and requires six relationship hops. No amount of semantic layer definition makes that possible. You need a graph.
Or consider contract renewal season. A customer's top account hasn't logged in for 30 days. They use three products. Their contract renews in 60 days. There's no assigned CSM. Today, nobody notices until it's too late. With a relationship graph, an agent connects product usage, account data, contract timelines, and team assignments to flag the risk before it becomes churn.
This is also where progressive disclosure becomes critical. An ontology with hundreds of entity types and thousands of tools is just as overwhelming to an LLM as a flat list of MCP tools. SixDegree solves this architecturally: when an agent queries the ontology and discovers GitHub entities, only GitHub-relevant tools become available. The agent never sees GitLab tools for a GitHub problem. The context layer doesn't just provide information. It constrains the action space to what's actually relevant.
The Market Validation
a16z identifies three emerging categories: data gravity platforms (Snowflake, Databricks) adding lightweight context, existing AI analyst companies recognizing context as a differentiator, and new dedicated context companies building from scratch.
We're in the third category, but with a different lens than the analytics companies a16z profiles. Every integration we add enriches relationships that flow across teams and functions. Security, compliance, finance, RevOps. The graph gets more valuable with every connection.
The a16z piece references Palantir's ontology work as a benchmark for this complexity. Right comparison. Palantir proved that ontology construction for enterprises is valuable and hard. The difference now is MCP. Palantir built bespoke integrations. We build on a protocol that the entire industry is standardizing around: Anthropic, OpenAI, Google, Microsoft. The integration surface is orders of magnitude larger.
Early Innings, Already on the Field
The article closes with: "We are at an interesting point in time... the problem of a lack of context has become apparent, but we are still in the early innings of building solutions."
They're right about the timing. They're describing a market that's forming right now, and the thesis is correct: agents without context are useless, and context layers are the missing infrastructure.
SixDegree is already here. Not theorizing about what a context layer should be. Building one. The platform is live. The integrations connect to the systems enterprises actually use. The ontology updates in real time. The MCP interface means any agent can use it today.
When a16z publishes a thesis that reads like your product spec, it means one of two things: you're building something obvious, or you're building something that the market is about to demand. Given that 95% of enterprise AI pilots still fail and the solutions a16z describes barely exist yet, I'm confident it's the latter.
We're building the context layer at SixDegree. If a16z's thesis resonates and you want to see what it looks like in practice, let's talk.