Your Data Agent Is Only as Smart as Its Context (So We Built One That Gets It Right)

A16z just laid out the blueprint for how data agents must work. Here’s why Jean-Paul from SnapLogic was already using it before the ink dried.

The team at Andreessen Horowitz (a16z) recently published a sharp piece titled “Your Data Agents Need Context.” If you lead data, analytics, or AI initiatives in your organisation and you haven’t read it yet, stop here and do so. It is one of the clearest articulations of why the first wave of enterprise data agents largely failed, and what a second, more advanced wave looks like.

The short version: connecting a large language model to a data warehouse is not enough. What separates a data agent that hallucinates revenue figures from one that reliably answers a question such as, “Why did EMEA pipeline drop 12% last quarter?” is context. The accumulated business logic, tribal knowledge, and living metadata make data meaningful to humans, but have never been systematically encoded for machines.

We found ourselves nodding vigorously at every paragraph. Not because it was new to SnapLogic, but because it accurately described the exact architectural decisions we made when designing Jean-Paul, our AI-native integration and analytics agent. Two weeks ago, at our public event Agent Fest, we announced Jean-Paul to the world. The a16z piece dropped shortly after. The timing felt less like a coincidence and more like confirmation.

“Most data agents fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations.”

Andreessen Horowitz (a16z), “Your Data Agents Need Context” (2026)

We’d add one word to that diagnosis: permanently. Most agents failed, and they’ll continue to fail, until the context problem is solved at a platform level, not as an afterthought bolted on after deployment.

The five-step blueprint, and where Jean-Paul lives in it

A16z outlined a five-step architecture for a modern context layer paired with an agentic data system. Let’s map it honestly and specifically against what Jean-Paul does today.

1. Accessing the right data

A16z calls this table stakes: making all relevant data accessible, including sources beyond the warehouse such as GDrive, Slack, internal systems, and tribal knowledge repositories.

Jean-Paul connects natively to SnapLogic’s integration fabric, which already federates hundreds of data sources. When a data leader asks a question, JP doesn’t just query one place. It reaches across the organisation’s entire connected data estate, including unstructured sources, in a single agent loop.

Jean-Paul: native multi-source access

2. Automated context construction

High-signal context can be extracted automatically: 

• Query history reveals frequently referenced tables
• DBT models and LookML provide metric definitions
• Schema metadata clarifies joins

Jean-Paul does exactly this: our BigQuery analytics skill ingests schema documentation, past query patterns, and dataset descriptions before executing any query. We don’t let the LLM guess. We built a mandatory schema-first discipline into the agent’s architecture.

Jean-Paul: schema-first, grounded queries

3. Human refinement

Automated context can’t capture everything. The most critical business logic is conditional, historically contingent, and lives only in people’s heads. For example, “use Salesforce for global leads before 2025 but Affinity for USCAN deals from 2025 onwards.” 

A16z compares this to developers maintaining .cursorrules files. Jean-Paul exposes this kind of configuration layer, allowing data practitioners and admins to encode rules, caveats, and exceptions that shape every subsequent agent interaction. Context is not static. It is curated.

Jean-Paul: configurable rules layer

4. Agent Connection via API or MCP

The context layer only works if it is accessible to agents in real-time. A16z identifies API and MCP (Model Context Protocol) as the two standard exposure patterns. Jean-Paul is built on both. 

It exposes SnapLogic’s full integration and analytics capabilities as an MCP server, meaning any MCP-compatible AI client (including Claude, Cursor, and third-party agents) can consume Jean-Paul’s context-enriched tools without rebuilding the context layer from scratch. One platform, many agent clients.

Jean-Paul: MCP-native server

5. Self-updating context flows

This is the one that excites us most, because we’re finishing it right now. Data systems are never static. Schemas change. Business rules evolve. Agents make mistakes that need to be corrected back into the context layer. 

A16z describes a “living and constantly evolving corpus.” Jean-Paul’s self-updating context flow is in the final stages of development, specifically designed to handle upstream data warehouse changes, including our own recent DWH structural updates. When the warehouse changes, the context layer changes with it. No manual intervention required.

Jean-Paul: self-healing context (in active development)

Why this matters for data leaders right now

A16z segments the emerging market into three categories: 

1. Data gravity platforms (Snowflake, Databricks) that are adding context capabilities to existing infrastructure
2. Evolved AI data analyst tools bolting on context post-hoc
3. A new category of dedicated context layer specialists building ground-up solutions

We’d argue there’s a fourth position, perhaps the most defensible: the integration platform that already owns the connective tissue between systems. 

SnapLogic doesn’t need to build new connectors to access your ERP, CRM, data lake, and operational databases. We already have them. The context layer isn’t something we’re adding. It’s the natural extension of what an enterprise integration platform does when it becomes AI-native.

The insight data leaders need to internalise: You cannot buy context off the shelf. You cannot prompt-engineer your way to it. Context is an organisational asset that must be constructed, curated, and continuously maintained by the teams who understand the business. Jean-Paul provides the infrastructure to do that systematically.

3 practical tips for your data and AI strategy

1. Stop evaluating data agents on demo queries

“Revenue last quarter” is easy to answer correctly in a controlled environment. The real test is ambiguous, cross-system, business-critical queries under real conditions: “Which customer segments are underperforming against forecast and what’s driving it?” This requires context at every step. Evaluate agents on that basis.

2. Treat context as infrastructure, not a prompt

The teams we see succeeding with data agents are not the ones who write the cleverest system prompts. They’re the ones who invest in encoding business logic into a durable, versionable context layer, one that outlasts any individual LLM model version. This is a data engineering problem, not an AI problem.

3. Plan for context drift from day one

A16z is right that self-updating context is not optional; it’s a survivability requirement. A static context layer is a liability. Data schemas change quarterly. Business definitions shift. Mergers happen. The organisations that build a context maintenance discipline now will have compounding advantages as their agents accumulate institutional knowledge over time.

Looking ahead: Gartner D&A, May 11–13

This May, data and analytics leaders from across the industry will gather in London at the Gartner Data & Analytics Summit. If the a16z piece is directionally correct, and we believe it is, the conversations at that event will increasingly centre on the context problem. Which vendors have solved it? What does a production-grade context layer look like? How does an organisation migrate from ad-hoc AI experiments to repeatable, trustworthy data agents?

These are the questions Jean-Paul was built to answer. If you’ll be in London at the Gartner Data & Analytics Summit, we’d welcome the conversation. Stop by the SnapLogic booth (#212) and say hello!