The Context Layer
Is the Stack.

In March 2026, Andreessen Horowitz partners Jason Cui and Jennifer Li published a detailed analysis of why enterprise AI data agent deployments are failing. Their conclusion is crisp: agents aren’t failing because models are weak. They are failing because enterprises deploy agents against data they cannot actually interpret, data without governed definitions, without tribal knowledge, without a reliable source of truth.

The article traces a decade of data infrastructure evolution. The modern data stack transformed how enterprises ingest, clean, and warehouse data. Then in 2024–2025, as LLM capabilities grew, organizations rushed to deploy agents on top of that stack. The agents hit a wall. Not a model wall. A context wall.

The canonical example they use is devastating in its simplicity: an agent asked "What was revenue growth last quarter?" fails, not because it cannot write SQL, but because it does not know what revenue means in this company, which fiscal quarter is meant, or which of three tables named fct_revenue, mv_revenue_monthly, and mv_customer_mrr is the authoritative source.

a16z maps what a modern context layer must include that a traditional semantic layer does not: canonical entity resolution, tribal knowledge in natural language, governance rules for agents, and a self-updating architecture that keeps context current as systems evolve. What they describe is not a product category. It is an infrastructure requirement. And it points directly to what LazyFox is built to close.

The a16z example is worth examining closely because it is not exotic. "What was revenue growth last quarter?" is a question every enterprise answers dozens of times a week. What makes it hard for an agent is exactly what makes it easy for someone who has been at the company for three years: they know that "revenue" means ARR, not run rate; that the fiscal quarter ends in March; that fct_revenue is the source of truth after the Q4 migration, but that mv_revenue_monthly is what finance still uses for historical comparisons pre-2024.

That knowledge does not live in a schema. It lives in a person, or in a stale YAML file from a data team member who left two years ago. When the agent looks at the warehouse, it finds three tables with similar names and no signal about which one is authoritative, no definition of the fiscal boundary, and no mapping from the business term "revenue" to the engineering artifact fct_revenue.

a16z is explicit that the fix is not a better model. It is not a more capable text-to-SQL system. It is a governed layer that captures metric definitions as maintained, versioned code that agents can query before they act. Traditional semantic layers cover some of this, but they are hand-built by data teams in BI-specific syntax, connected to a single tool, and cannot capture the implicit business rules that make definitions actually correct.

This is precisely the logical layer of LazyFox’s three-tier semantic architecture. Metric definitions are captured as governed, versioned code. Semantic drift detection flags when a definition diverges across connected systems. When an agent asks "what is revenue?" it does not receive three conflicting answers from three different tables. It receives the single, current, governed definition, and the source of truth to query against it.

a16z is specific about where automated context construction reaches its limit: "It is tempting to set agents loose and have them collect all internal knowledge, but some of the most important context is implicit, conditional, and historically contingent, and only exists as tribal knowledge inside teams."

The example they give is surgical in its precision: "For CRM data, look at Affinity for all new USCAN deals from 2025 onwards but Salesforce for all global leads before that." No automated system will derive this instruction from schema inspection. It exists because a migration happened on a specific date, because one team adopted a new tool and another did not, because a commercial decision was made at a specific moment in time that is now embedded in the data architecture but documented nowhere.

The key insight from a16z is that these rules are not exceptions to the context layer, they are the point of the context layer. Metric definitions can be partially automated. Source-of-truth selection for historical edge cases cannot. This is the step that separates a context layer that works in demos from one that works in production at 2 a.m. on a quarter close.

LazyFox’s contextual layer is built for exactly this. Business rules , "use the lakehouse for post-migration revenue, the legacy warehouse for pre-2024 comparisons", are captured in natural language alongside metric definitions. They are indexed once. Every agent query reads from governed code at runtime; no model re-processes that context on each call, adding neither latency nor cost per query.

And when a rule changes, when the migration completes, when a new product line launches, when the fiscal year boundary shifts, the change propagates across every connected agent automatically. The context layer is a living document, not a snapshot.

a16z closes their analysis with a market observation that is straightforward but important: "Realistically not every enterprise can (or should) build this in house." They map three categories of solutions: data gravity platforms adding lightweight context features (Databricks, Snowflake), AI data analyst companies that have pivoted toward context construction as a core competency, and a third category, dedicated context layer companies, building from the ground up. They are explicit that the third is early, but equally explicit that the mandate is clear.

LazyFox sits in that third category. And the architectural requirements that fall out of the a16z analysis define exactly what a genuine context layer must do:

• No data migration. A context layer that requires moving data is a rearchitecting project, not a product. It must sit above existing systems as a governance and interpretation layer, not replace them.
• Cross-system reconciliation, not single-system scope. An agent querying across a CRM, warehouse, and finance system cannot receive three independently scoped answers that it then has to adjudicate. Reconciliation must happen across all connected systems simultaneously at runtime.
• Token efficiency by design. The context injection a16z describes (via API or MCP) fails at scale if context is re-processed per query. Business context must be indexed once; every subsequent interaction runs from governed code, not from the model re-ingesting organizational knowledge on each call.
• Self-updating without manual maintenance. When data systems change, context must propagate automatically. A layer that requires a data engineer to update YAML files after every schema change is the old semantic layer problem with a new name.

LazyFox’s three-layer architecture, structural (schema mapping), logical (metric definitions and governance), contextual (tribal knowledge and business rules), is designed around all four constraints. It is vendor-agnostic because context lives in code that your team owns, not in a model provider’s weights. It reconciles across all connected systems simultaneously. It indexes once and serves from governed code. And it propagates changes automatically when upstream definitions shift.

The 167% net revenue retention LazyFox has achieved with an early enterprise customer reflects exactly the compounding dynamic a16z describes: each definition captured, each tribal knowledge rule encoded, each drift event detected makes the context layer more accurate and more comprehensive over time. The value does not reset on a contract cycle. It compounds.