A prospect evaluating my company asked me whether we’re trying to replace his lake. He runs a Snowflake shop in capital markets, the world I spent thirty years inside, and our homepage at the time read enough like a warehouse pitch that the question was fair.
The answer is no. But there’s a better question hiding under his, and every data team is about to get asked it: when agents start doing real data work in your environment, what do they actually need from you?
Because they’re already doing it. Agents are pulling in data and answering questions from it right now, at firms that haven’t fully noticed. And they don’t need another place to put the data. You have places. Snowflake, Databricks, Postgres, kdb+, a lake you spent years getting right. What’s missing is a safe way to work with what you already run.
What an agent does when you don’t give it one
The first time I watched a capable agent do data work, it stopped me cold. Given a task, it grabbed a database driver and started issuing raw writes. It wanted the connection string in its own hands. It reimplemented validation inline, badly, the way a rushed engineer under deadline always has. It was recreating every mistake I spent a career cleaning up after, at machine speed.
Now multiply that by every agent every team stands up this year. Each one improvising its own ingest script against your warehouse, holding credentials to systems that matter, running whatever the model decided validation meant that afternoon. No record of what ran or why.
Your Snowflake is fine at its job. So is the lake. What’s missing is the front door, the layer an agent goes through to reach them, because right now there isn’t one.
The acquisition half
Data acquisition is the half everyone can picture. An agent gets told to bring in a new source, an API or a vendor feed or a pile of files, and get it into the warehouse.
Through a proper layer, that becomes a declarative conversation: ingest this source, validate it against this schema, land it in Snowflake. Or Databricks, or Postgres, or object storage. Wherever the data belongs in your estate. The layer owns everything underneath the sentence: the connector, the retries, idempotency so a rerun doesn’t double your rows, quarantine for records that fail validation, the secrets, and an audit trail of what ran, when, and what came back.
The agent never touches a credential, and your warehouse never sees a raw write from improvised model code. What lands is validated, traceable data. Actual data engineering, done by an agent.
These are batch jobs, deliberately. Scheduled or on-demand, with a completion record. If your problem is streaming tick data at microsecond latency, that’s Snowflake’s job and it should stay that way.
The querying half
The other half is quieter and carries more risk: agents answering questions from your data.
The pattern taking hold right now is one MCP server per database. Postgres, Snowflake, Mongo, each with its own server, all wired into the same conversation. It feels responsible, since nobody handed the agent a raw warehouse password. But each server authenticates as some database user, and the agent’s reach is whatever that user was granted. Even when every server is scoped carefully, the entitlements are defined once per store, with nothing above them holding a single view of what the agent is allowed to know. Same for the audit trail, when one exists at all.
And when a question spans two stores, the agent becomes the join engine, pulling raw rows from each server into its context window and correlating them in the model. That’s slow and expensive, and the answer shifts a little every run. The data also leaves governance the moment it lands in the context.
The alternative is governed retrieval. The agent queries through a layer that holds a working set scoped to its task, searchable, with vector search for the unstructured pieces. Access control decides what it can see, and every question gets logged. When it needs data it doesn’t have, that’s an acquisition job through the front door rather than an ad-hoc SELECT against prod.
The working set looks a little like storage, and it is, but it exists to serve agents. Your quants will never go near it, and it’s the only surface your agents get.
What the layer has to be
If this layer is going to exist, and the agents are forcing the issue, it has to hold to a few rules or it becomes the next problem:
It sits beside your stores. The moment it wants to own your storage, it turns into another warehouse pitch, and it will lose to the incumbents you already trust. Its whole value is that your lake stays your lake.
It’s neutral. It works with whichever warehouse you bought and whichever model you’re calling this quarter. Destinations and models are settings, not migrations. A layer that only feeds one vendor’s lakehouse is really just that vendor’s moat.
It’s honest about its shape. Batch-oriented and schema-enforcing, with an audit trail under everything. A layer that claims to do it all hasn’t decided what it is.
It speaks the agent’s protocol. MCP, today. Any framework’s agent can drive it, and every team goes through the same governed interface instead of wiring up a fresh integration.
Where Datris fits
Datris is our build of that layer. Open source, MCP-native, and it covers both halves: agents acquire data through it into Snowflake, Postgres, MongoDB, and object storage, and they query a governed working set instead of holding your keys. It sits beside your warehouse and your lake, and it will keep sitting beside them. That position is the product.
So, to the prospect who asked: no, we’re not after your lake. Nobody building this layer honestly can be. The next platform your data estate needs isn’t a new place for the data. It’s the way in for the agents.
Todd Fearn is the founder of Datris.ai, an open-source, agent-native data platform built on the Model Context Protocol, and he runs IData Corporation, a data engineering consultancy for financial services firms. He has spent about thirty years building production data infrastructure inside institutions like Goldman Sachs, Bridgewater Associates, Deutsche Bank, and Freddie Mac.