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 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 and 2025, as LLM capabilities grew, organizations rushed to deploy agents on top of that stack, and the agents hit a wall made of missing context rather than model limits.

Their central example is simple: 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 matters 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 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 governed definition that applies to the question, 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."

Their example is precise: "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.

a16z’s point is that these rules are not exceptions to the context layer. They are the point of it. 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 what a working 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.

Finway shows the loop a16z describes. Its reporting logic moved out of hand-written queries into one governed layer, and a new report now takes hours instead of a couple of weeks. Every definition captured, conflict surfaced and drift event detected adds to that layer, and the health of each metric is checked against it continuously, so the context grows more complete with use instead of resetting on a contract cycle.

The gap a16z names is real, and the fix is not a better model. It is a governed layer your agents query before they act. When you evaluate one, the answers to these five decide whether it works in production or only in a demo.

• Does it require moving your data? A context layer that demands migration is a re-architecture project. It should sit above your existing systems, read-only.
• Does it reconcile across every connected system at once? An agent querying CRM, warehouse, and finance cannot be handed three answers to adjudicate. Reconciliation has to happen at runtime, across all of them.
• Can it capture tribal knowledge as well as schema? "Affinity for USCAN deals from 2025, Salesforce before that" is the context that matters, and no automated crawl derives it.
• Is context indexed once, or re-processed per query? Re-tokenizing organizational knowledge on every call fails at scale, on both cost and latency.
• Does it stay current on its own? A layer that needs a data engineer to edit YAML after every schema change is the old semantic-layer problem wearing a new label.

LazyFox is built to answer yes to all five. Its three layers, structural, logical, and contextual, sit above your stack without migration, reconcile meaning across every connected system at runtime, capture tribal knowledge in natural language beside governed code, index once, and propagate changes automatically. It lives in code your enterprise owns, not a model provider's weights, which is exactly what makes the context a durable asset rather than a side effect of which model you run today.