Cortex Agents, Cortex Search services, and Snowflake-managed MCP servers usually live outside your pipelines: built by hand, versioned nowhere. The dbt Cortex Agent Accelerator, a proprietary OneSix dbt package, turns each into a versioned dbt model, so every agent, tool, and service ships through the same CI/CD pipeline as your code.
The stakes
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 to a change. And every new Snowflake feature means another manual redeploy.
The risk compounds once real data is involved. One-off connectors create shadow access paths, break role-based access control, and leave no audit trail. That's the difference between a lab demo and something safe to run in production.
THE BUILD
One dbt package that brings your entire Cortex stack under version control, governance, and dependency-aware deployment.
What's included
Deploy Cortex Agents, Cortex Search services, and Snowflake-managed MCP servers as dbt models. Define them once, run them with dbt run, manage them like everything else in your project.
The model body is the raw Snowflake YAML, passed to Snowflake verbatim. Every current and future feature works the day it ships. No package updates, no waiting for a wrapper to catch up.
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.
Agent versioning keeps full change history. Idempotent deploys make re-runs safe. A shared feedback table captures user ratings and comments with no extra setup.
Process
01
Review your Cortex environment and map the agents and MCP servers you need.
02
Install the package, model your agents and search services, wire them into the DAG.
03
Run the pipeline. Everything builds in dependency order, versioned and idempotent.
04
Documentation and a working pattern your team extends on its own.
Delivery
Delivered as part of a Data Foundations or Artificial Intelligence engagement, on an environment configured to Snowflake best practice. It slots into the dbt project you already run: no new orchestration, no separate deployment path for AI.
FAQs
No. The model body is the raw Snowflake agent or MCP server YAML from the CREATE AGENT reference. If you can write a Snowflake spec, you can write the model.
It works immediately. The spec is passed through verbatim, so there's no wrapper to update and no package upgrade required.
By default, every dbt run preserves history: the package updates the live version with the compiled spec and commits a new named version. Disable it per-model for fast dev iteration, and dbt run --full-refresh resets history for a clean slate.
Yes. Deploys are idempotent. Cortex Search services are handled with extra care, altering the index in place on steady-state runs so incremental refresh is never discarded.
The package provisions a shared feedback table and an AGENT_SUBMIT_FEEDBACK procedure any agent can call. Ratings, comments, and conversation context land in one table across all your agents, with no custom logging to build.
Yes. The same package ships materializations for both. MCP servers use the raw-spec passthrough; search services build from a normal dbt SELECT. Both wire into the DAG with ref() so the whole stack deploys together.
Every agent, tool, and MCP server is a Snowflake-managed object, so RBAC applies to all of them: scoped access, full audit trail, no shadow paths. No data leaves Snowflake and no middleware sits in between.