Getting an AI agent to query your data is easy. Doing it safely, repeatedly, and at scale is the hard part. The interesting question was never "can Claude read my Snowflake data?" It's whether you can hand agents that data without a pile of one-off connectors, broken access control, and no audit trail to show for it.
The building blocks are already there: Cortex Analyst, Cortex Search, Cortex Agents, and the Snowflake-managed MCP server that ties them together. The gap is turning them into something you can run in production. That's the gap OneSix works in.
Standing something up and running it in production are two different things. The interesting question isn't "can I get an agent to query my data?" It's "can I do that safely, repeatedly, and at scale, without a pile of one-off connectors that keep me up at night?" OneSix takes these Snowflake capabilities from lab to production for real customers.
Here's how the pieces fit together.
For twenty years, the way you connected systems was the REST API. It worked because the world was predictable. A developer knew the endpoint ahead of time. The request and response shapes were fixed. Authentication was coded per application. The UI knew how to render whatever came back. Add a capability, ship a code change.
Agents break every one of those assumptions. An AI agent doesn't know your endpoints in advance. It needs to discover what tools exist, invoke them a standard way, and read tool descriptions it can actually reason over. It needs consistent authentication and governance across everything it touches, and it needs to reuse the same tools across many clients. REST solved system-to-system integration. Agentic AI changed the pattern.
That's the problem the Model Context Protocol (MCP) solves. Think of it as a universal adapter between AI models and the data or tools they need. Instead of building N models by M data sources worth of bespoke integrations, everything speaks one protocol. An MCP host (Claude, Cursor, a custom app) runs an MCP client, and that client talks to MCP servers that expose tools and data.
Plenty of vendors can stand up an MCP server. What makes Snowflake's managed MCP server compelling is where it lives: inside the same governed perimeter as your data.
The server is a first-class Snowflake object. It exposes Snowflake's Cortex capabilities as tools an agent can call. Cortex Analyst for structured, text-to-SQL questions grounded in semantic views. Cortex Search for hybrid search across unstructured content like documents and transcripts. Cortex Agents to orchestrate multi-step reasoning across both. Authentication runs over OAuth, and Snowflake's role-based access control is enforced on every single call at three levels: usage on the MCP object itself (can you connect and discover tools?), usage on each tool (can you invoke Cortex Analyst or Search?), and usage on the underlying data (can you actually retrieve these rows?).
The payoff is simple and important. No data leaves Snowflake, and there's no middleware to maintain. The same policies that govern your people now govern your agents, and every tool call lands in query history as a full audit trail.
.png)
The part that makes this repeatable rather than a one-time build is a proprietary OneSix dbt package: the dbt Cortex Agent Accelerator. Agents as code, deployed on Snowflake.
Here's the problem it solves. Most teams build Cortex Agents by clicking through Snowflake or running one-off SQL. It works until it doesn't. The agent points at a semantic view that hasn't rebuilt. The search index goes stale. No one can trace a regression back to the change that caused it. And every new Snowflake feature means another manual redeploy. Once real data enters the picture, the risk compounds. One-off connectors create shadow access paths, break role-based access control, and leave no audit trail. That's the difference between a prototype and something safe to run in production.
The accelerator brings the whole Cortex agentic stack under one pipeline: Cortex Agents, Cortex Search services, and Snowflake-managed MCP servers. A few design choices make it punch above its weight.
dbt run, and manage them like everything else in your project.ref() wires agents and MCP servers into the dbt DAG, so they always deploy after the semantic views and search indexes they depend on. Upstream first, agent last, every run.The result: every agent, tool, and search service ships through the same CI/CD pipeline as the data it depends on. An MCP server stops being a special case and becomes another versioned, reviewed, governed artifact in your dbt project. It's delivered as part of a Data Foundations or Artificial Intelligence engagement, and it slots into the dbt project you already run. No new orchestration, no separate deployment path for AI.
Strip it down and the value lands in three buckets.
A prototype proves the capability. The production pattern proves it's safe to scale. By deploying MCP servers as versioned dbt models inside Snowflake's governed perimeter, teams get both: the flexibility to connect any AI client to their data, and the discipline of treating those connections like the production infrastructure they are.
If you're sitting on well-governed Snowflake data and wondering how to safely put it in front of your AI clients, that's the road from lab to production. It's a shorter trip than you might think. Read more about the dbt Cortex Agent Accelerator that makes it repeatable.
