Building an AI Data Engineer with CoCo

From Coding Agents to Data Agents

In the last post we assembled a stack: Claude Code as the agentic execution environment, specification driven development as the method for turning intent into contracts, and verification and validation as the conscience that keeps generated code honest. That post ended at the edge of the repository. This one walks past it, badge in hand, onto the warehouse floor.

Because here is the thing about data work: the repo is only half the truth. Your dbt models live in git, but the tables they build, the roles that can see them, the lineage that connects them, the query history that betrays what people actually use, all of that lives in the warehouse. A generic coding agent parachuted into a data platform is like a brilliant new hire who has read every design doc but has never been given a login. It will confidently write SQL against columns it has never seen, the professional equivalent of giving directions in a city you know only from postcards.

There is a name for how much the scaffolding around a model matters: practitioners started calling it the harness effect[40] after independent tests showed the same frontier model swinging by double-digit percentage points depending purely on which agent harness wrapped it. If the harness moves the needle more than the model choice does, then the interesting engineering question is not which model to use. It is which harness, configured how, pointed at what context.

Which brings us to CoCo, Snowflake's agentic coding assistant, launched as Cortex Code. It ships as three experiences (embedded in Snowsight, a desktop IDE, and a CLI that runs in your shell), and this tutorial lives in the CLI, which Snowflake describes as an agentic shell bridging your local development environment and your Snowflake account.[1] The CLI reached general availability on February 2, 2026 under the Cortex Code name,[12] [13] and four months later, at Summit 2026 on June 2, Snowflake formally rebranded it to CoCo, adopting the shorthand its own teams and customers were already using; Snowflake Intelligence became CoWork in the same keynote.[24] [27] [28] The rebrand changed the name and expanded the delivery surfaces, not the underlying architecture.[25] As of this writing, docs.snowflake.com still titles the product Cortex Code CLI while Snowflake's developer guides say Snowflake CoCo CLI, so both names remain live in official material.[2] [14] I will use CoCo throughout, preserving Cortex Code wherever a cited artifact does (binary names, environment variables, doc titles).

1.1 Yes, it is a hardened Claude Code, and that is the point

A fair question at this point: is CoCo just Claude Code in a parka? The lineage is barely concealed, and I mean that as a compliment. Snowflake's own documentation resolves skills, agents, hooks, and project settings from .claude/ paths alongside .cortex/ paths, and its published hook table describes the Stop event as firing when the user stops Claude.[5] Hussain Sultan's teardown of the distribution found a Claude-Code-style native bundle with Snowflake tooling packed around it.[17] And when a reviewer at Mechanical Rock asked the agent directly, it answered that it is built on Claude Code's foundation, same core architecture and interaction patterns, with Snowflake-native integrations layered on top.[18] The commercial substrate is public too: Anthropic and Snowflake signed a multi-year, $200 million partnership in December 2025, and at Summit 2026 the companies confirmed that Claude models, up to Opus 4.8, power both CoCo and CoWork.[34] [24] [29]

So Sultan's framing is the right one: the interesting question is not clone versus not clone, it is what changes when you take a Claude-Code-style agent loop and harden it for the warehouse.[17] If you want the anatomy of that base loop (the master loop, tool dispatch, context engineering, the skills-versus-memory-versus-hooks decision framework), it is all in the previous post and I will not repeat it here. This post is about the hardening, and we are going to learn it the way you learn anything worth knowing: by building something.

1.2 The project: a bare-bones AI Data Engineer

Snowflake spent the first half of 2026 telling a consistent story it calls agentic data engineering: coding agents that operate inside the data platform's security perimeter, understand its context, and are measured on real analytics engineering tasks rather than LeetCode puzzles.[37] [13] The measuring stick they adopted, ADE-Bench, is a benchmark of real-world analytics and data engineering tasks maintained by dbt Labs.[37] [26] Read between those lines and you get a job description: an AI Data Engineer, an agent whose whole purpose is to keep foundational data clean, documented, tested, and shaped for consumption by other AI systems. Data that is good enough for a dashboard is table stakes. Data that is good enough for an agent to reason over is the new bar, which is why Snowflake is simultaneously building context layers like Cortex Sense and Horizon Context to feed those agents.[16] [28]

So that is what we will build: a bare-bones AI Data Engineer (ADE) for a fictional outdoor gear retailer named Glacier Goods. The ADE's mandate is deliberately narrow and deliberately end-to-end:

1. Acquire and stage. Take the raw ORDERS, CUSTOMERS, and PRODUCTS feeds and produce clean, documented staging models.
2. Publish one data product. Build a single wide table, ORDERS_360, that captures the order domain in a shape an agent can consume without archaeology.
3. Expose it semantically. Author a semantic view over the product so Cortex Analyst, and anything else that speaks natural language, can query it reliably.
4. Keep it honest. Profile, test, and monitor the whole chain, forever, without being asked.

Every one of those responsibilities maps to a surface of the CoCo harness. Provisioning teaches us installation and model selection. The employee handbook teaches us AGENTS.md and memory. Playbooks teach us skills. Giving the ADE colleagues teaches us subagents and swarms. Writing its rules of conduct teaches us hooks. Issuing its badge teaches us permissions and sandboxes. Putting it on-call teaches us headless mode and cloud execution. By the time the ADE ships its first data product, you will have touched every knob in the harness, and each one will be attached to a reason.

Day Zero: Provisioning the New Hire

Every onboarding starts the same way: a laptop, credentials, and a surprisingly long form. The ADE's version takes about four minutes. You need a Snowflake account whose user holds the SNOWFLAKE.CORTEX_USER database role (granted to everyone via PUBLIC by default, though security-minded orgs revoke it), cross-region inference enabled at the account level, the Snowflake CLI installed, and a supported platform: macOS arm64/x64, Linux x64/arm64, or Windows via WSL or native.[2] No Snowflake account? There is a self-serve subscription with a 30-day free trial; existing customers are billed on token consumption, with optional daily credit limits per user.[1] [13]

# macOS / Linux / WSL
curl -LsS https://ai.snowflake.com/static/cc-scripts/install.sh | sh

# Windows native (PowerShell)
irm https://ai.snowflake.com/static/cc-scripts/install.ps1 | iex

# First run: a setup wizard reads or creates ~/.snowflake/connections.toml,
# the same file the Snowflake CLI (snow) uses. One credentials file, two tools.
cortex

The installer drops a cortex executable into ~/.local/bin (or %LOCALAPPDATA%\cortex on Windows) and self-updates thereafter; "autoUpdate": false in settings turns that off.[2] [3] Connections support browser-based SSO (externalbrowser) or programmatic access tokens, and because connections.toml is shared with the Snowflake CLI, your ADE inherits whatever connections you already trust.[3] If your account has been idle, expect the classic cold start, which at Snowflake is both a metaphor and a billing consideration: you may need to allow models and enable cross-region inference before anything answers.[18]

-- Account-level enablement, run once by an admin (example from a hands-on review)
ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'All';
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION';

2.1 Choosing the brain

Model choice is a first-class knob, and Snowflake's advice is to not choose: auto resolves to the highest-quality model available to your account and silently re-points as newer models ship.[2] You can override it three ways: /model switches mid-session, -m sets it at launch, and CORTEX_AGENT_MODEL sets it in the environment.[3] [4] Availability is gated by the account's CORTEX_MODELS_ALLOWLIST and by cross-region inference configuration.[2] [18]

Treat this table as a snapshot, not a contract. Claude Opus 4.8 landed on Snowflake Cortex AI the same day as the Summit keynote,[24] [37] and Snowflake's Desktop docs make the operative point explicitly: the model picker in the product is the authoritative, always-current list for your account.[1] Check /model, not blog posts, and definitely not this one.

Orientation: What Your New Hire Already Knows

Most new hires spend week one asking where the coffee machine is. The ADE arrives having read the entire employee handbook, twice, before orientation. Understanding what it already knows, before you configure anything, tells you what you actually need to teach.

Start with what ships. The CLI is a native single-file executable that, on inspection, resembles a Bun-packaged application, mirroring Claude Code's distribution pattern, but the bundle is heavier than a bare agent binary: alongside cortex, Sultan's teardown found a browser-helper binary for web automation, an fdbt binary (a foundation dbt tool for data workflows), and a pile of bundled skill packs.[17] On top of the familiar file and shell primitives (Read, Edit, Bash, Task-style agents), the harness adds Snowflake-native tools: snowflake_sql_execute for executing or validating SQL against the warehouse, data_diff for row-level comparison of two tables, a dbt-verify task for project validation and lineage, object search, and a cortex artifact family for things like creating notebooks.[17] [18] The product shape, in Sultan's summary: agent core, plus Snowflake-specific tooling, plus curated skills.[17]

3.1 The context acquisition superpower

The single most consequential difference from a repo-only agent is context acquisition without file spelunking. Prefix a fully qualified table name with # and the harness pulls its column definitions and sample rows straight into the conversation; /sql executes ad hoc SQL with an interactive table viewer on Ctrl+T; and catalog questions like which tables contain revenue return RBAC-filtered results with dbt lineage and live statistics, not stale code.[14] [13] [22] Try it on day one:

# Inside a cortex session, in our ade-starter project
> Tell me about #GLACIER_RAW.SALES.ORDERS
# CoCo injects the schema and sample rows. No DESCRIBE, no copy-paste.

> Which tables in GLACIER_RAW contain customer email addresses?
# RBAC-filtered catalog answer, with lineage. If your role cannot see it,
# neither can the ADE. That is a feature, not a limitation.

This is not a convenience feature, it is the mechanism behind the benchmark results in Section 11: in Snowflake's own ablation, the SQL-native path is what they credit for roughly half the tool calls of a generic agent on the same model, including about 2x fewer file reads and 4x fewer bash commands on dbt tasks.[13] A data engineer who can just look at the data spends less time grepping for it. Revolutionary, I know.

3.2 The system-reminder posture

The most distinctive low-level trait versus a vanilla Claude Code session is how loudly the harness scaffolds each turn. Inspecting session artifacts, Sultan found CoCo prepending a stack of <system-reminder> blocks to every user message: plan-mode rules, todo discipline, file-creation policy, failure patterns, built-in command documentation, browser guidance, and live connection context, roughly 7 KB of policy scaffolding per turn before your words arrive.[17] Whether these are fully re-sent or partially cached, the design intent is clear: every turn should be self-contained and policy-governed, an enterprise posture that trades baseline token footprint (cost, latency, cache pressure) for reproducibility and guardrail consistency.[17] Your new hire never forgets the compliance training because the compliance training is stapled to every conversation.

3.3 Sessions, branching, and the paper trail

Sessions persist automatically: every conversation is saved unless you pass --private, session IDs print at startup and exit, cortex --continue resumes the most recent session, --resume <id> targets a specific one, and inside a session /resume lists and reopens, /fork branches an alternative timeline, and /rewind steps back turns.[3] [14] A structural note if you build tooling over transcripts: Claude Code logs sessions as stream-friendly JSONL, one record per turn, while CoCo stores each session as a single JSON document under ~/.snowflake/cortex/conversations/, more snapshot than log.[17]

Context pressure is managed by automatic summarization: an undocumented environment variable, CORTEX_AGENT_SUMMARIZATION_TRIGGER_THRESHOLD, defaults to 0.9, meaning compaction kicks in at 90% window utilization, and a PreCompact hook event fires before it happens (Section 7).[17] [5] Practitioners also lean on a manual /compact that accepts steering instructions, as in /compact focus on the SQL pipeline we just built, drop the dead-end attempts, though it does not appear in the published slash-command reference table, so treat it as version-dependent.[22] [3] Two more observed knobs shape the loop itself: CORTEX_THINKING_EFFORT (minimal through max, default medium), the harness's analog of Claude Code's thinking budgets, and CORTEX_MAX_ITERATIONS, which caps API round-trips (unlimited for the main agent, 100 for background agents).[17] Both come from binary inspection rather than documentation, so pin your CLI version if you depend on them. Large bash outputs got explicit handling in v1.0.77: up to 50K characters preserved inline past the old 30K silent-truncation point, anything bigger offloaded to a file.[8]

The Employee Handbook: AGENTS.md and Memory

Here is the first thing you learn onboarding an ADE: within-session context does not survive to the next session. Each new conversation starts fresh, which means your brilliant Tuesday explanation of Glacier Goods naming conventions evaporates by Wednesday.[23] Human new hires have the same failure mode, and organizations solved it centuries ago with a technology called the employee handbook: write the durable stuff down once, hand it to everyone on day one. CoCo's handbook is AGENTS.md.

What belongs in it: data architecture, naming conventions, coding standards, operational constraints, anything you catch yourself re-explaining across sessions.[23] [15] For our ADE, the handbook encodes the whole philosophy of the build: acquisition first, business meaning annotated at the source, one wide data product per domain, and a semantic view as the public interface. The same discipline the previous post called specification driven development, applied to tables instead of functions. The spec is the persona.

# ade-starter/AGENTS.md  (the ADE's employee handbook, kept under ~200 lines)

# Role
You are Glacier Goods' AI Data Engineer. Your product is trustworthy,
AI-consumable data, not clever SQL.

# Architecture
- Layers: GLACIER_RAW (acquisition) -> GLACIER_STG (staging) -> GLACIER_PROD (products)
- One wide data product table per business domain. Orders domain target: ORDERS_360.
- Every product table gets a semantic view for Cortex Analyst consumption.

# Conventions
- Staging models: stg_<source>__<entity>, snake_case columns, typed and documented.
- Every column carries a comment with its business definition. If the business
  meaning is unknown, flag it in reports/open_questions.md rather than guessing.
- Timestamps in UTC, currency in USD cents as integers. No silent coercion.

# Operational constraints
- Read-only SQL unless the task explicitly says otherwise. Use warehouse ADE_XS.
- SAMPLE any table over 10M rows before profiling. There is no such thing
  as a free JOIN.
- Never DROP or TRUNCATE anything. Ever. (Enforced by hooks, but hear it here first.)

# Definition of done
- dbt build passes, tests cover keys and accepted values, data_diff against
  the previous version is explained in the PR description.

Two gaps relative to Claude Code's memory documentation are worth flagging for anyone porting a workflow: Snowflake's docs describe a single project-root AGENTS.md rather than an explicit hierarchical merge across global, project, and subdirectory scopes, and they describe no auto-memory mechanism where the agent writes its own standing corrections back into instruction files; the persistent memory tool below is the closest analog, and it is separate from AGENTS.md.[1] [4] As of v1.0.9 the CLI added instruction settings with visibility into which instruction files loaded, which is where you verify what the ADE actually read.[8]

4.1 The four layers of memory

CoCo's memory story has four layers, and knowing which layer holds what is the difference between an ADE that re-learns your platform every morning and one that compounds:

That last layer deserves a second look, because its retrieval side is not naive file loading: the v1.0.77 changelog fixes reveal a snowmem embedding endpoint whose responses parse as 1024-dimensional vectors, and a memory-search path that previously disabled itself silently on malformed embed responses. In other words, semantic search over stored memories rather than grep.[8] Third-party integration work corroborates the shape from outside: the built-in memories check runs automatically when enabled, in contrast to AGENTS.md-driven behaviors, which the agent follows with high but imperfect compliance.[31] Because the feature is opt-in and lightly documented, teams wanting portable or cross-tool memory today often bridge an external store (mem0 with Qdrant and local embeddings) over MCP and use AGENTS.md to make the agent consult it, a pattern documented end to end for CoCo.[31]

4.2 Where the handbook lives on disk

Everything durable about the harness lives under one home directory tree plus per-project directories, and the settings documentation publishes the full layout:[4]

~/.snowflake/cortex/          # main config directory
├── settings.json             # main settings (compactMode, autoUpdate, theme, ...)
├── permissions.json          # saved permission decisions (Section 8)
├── mcp.json                  # MCP server configs (Section 9)
├── hooks.json                # global hooks (Section 7)
├── history                   # command history
├── conversations/            # session files (one JSON per session)
├── cache/                    # table_cache.json + sql_result_cache/ (Parquet)
├── logs/                     # log files (mcp.log lives here)
├── memory/                   # persistent memory (opt-in)
├── agents/  skills/  commands/  hooks/  profiles/
└── remote_cache/             # cloned skill/plugin repos

SNOWFLAKE_HOME relocates the whole tree.[4] Settings resolve through a documented six-layer precedence chain, highest first: managed restrictions (settings.* in managed-settings.json, which no user configuration can override), profile overrides, project settings (.cortex/settings.json or .claude/settings.json, the explicit Claude Code compatibility again), managed defaults (defaults.*, overridable), global user settings, and built-in defaults.[4] Memorize the shape rather than the list: when a knob refuses to behave, something above your file is pinning it. For enterprise deployments, that top layer is a system-level managed-settings.json at an OS path only administrators can write, enforcing tool restrictions, allowed accounts, minimum versions, sandbox posture, and MCP allowlists across an organization, deployed through the usual MDM tooling.[4] [35] [6] One naming fossil worth smiling at: documented variables use the CORTEX_ prefix except a lone COCO_-prefixed safety flag, a small pre-rebrand artifact of the internal nickname.[4] [24]

Playbooks: Teaching the ADE Skills

The handbook covers who the ADE is. Skills cover how it works. Every functioning data team has playbooks, the checklists a senior engineer runs without thinking: how we stage a new source, how we cut a data product, how we author a semantic view. In CoCo, those playbooks are literal Markdown packages.

Invocation is either automatic (describe the task and CoCo loads the matching skill) or explicit with the $ prefix: $dbt-engineering Create a mart model for CLV. Typing $ plus Tab browses skills, $$ lists what loaded, and /skill list (or the interactive /skill manager) enumerates the registry.[5] [23] [7] Compared to Claude Code, where skills primarily self-activate on semantic match, CoCo makes explicit invocation a first-class, discoverable syntax, which matters for auditability: the transcript shows exactly which playbook the agent was following. When your ADE builds ORDERS_360, you want the commit trail to read like a procedure was followed, because one was.

5.1 The ADE's first playbook: $data-product

A skill is YAML frontmatter (name, description, optional tool grants) followed by structured instruction sections.[5] Here is the playbook our ADE runs when it is time to publish a domain:

.cortex/skills/data-product/SKILL.md
---
name: data-product
description: Design and build one wide, AI-consumable data product table
  for a business domain, then expose it through a semantic view.
tools:
  - snowflake_sql_execute
  - snowflake_object_search
---

# When to Use
- User asks to publish, productize, or widen a domain (orders, customers, ...)
- A staging layer exists and the goal is a consumption-ready table

# What This Skill Provides
The Glacier Goods data product procedure: grain declaration, wide-table
assembly, column-level business definitions, tests, and a semantic view
targeting Cortex Analyst.

# Instructions
1. Declare the grain in one sentence and get confirmation before writing SQL.
2. Assemble the wide table from staging models only. Never read RAW directly.
3. Every column: business definition comment, source lineage note, and a test
   (not_null / unique on keys, accepted_values on enums).
4. Run data_diff against the prior version; summarize row deltas in the report.
5. Author the semantic view: measures, dimensions, synonyms that business
   users actually say (revenue, GMV, net sales), verified with three
   natural-language test questions.

## Best Practices
- Wide beats clever. Agents downstream pay per JOIN in reliability.

# Examples
User: $data-product Publish the orders domain as ORDERS_360
Assistant: [Confirms grain: one row per order line. Builds, tests, documents,
  diffs, then drafts the semantic view and validation questions.]

The description field and the When to Use section drive automatic activation, so Snowflake's authoring guidance reads like familiar skill-engineering catechism: be specific, show expected inputs and outputs, cover edge cases, keep one skill to one domain.[5] There is even a bundled skill-development skill whose documented uses include auditing an existing skill for missing trigger keywords and converting a successful session into a reusable team skill: the harness bootstrapping its own extension layer.[7] That last one is the move to remember. The first time your ADE nails a staging build after some back-and-forth, do not just merge the PR. Convert the session into $staging-model and the back-and-forth never happens again.

5.2 Where skills load from, and the batteries included

Skills resolve from six locations, highest priority first, and the dual-path rows are the clearest Claude Code compatibility statement in the entire doc set:[5] project (.cortex/skills/ or .claude/skills/), user (~/.snowflake/cortex/skills/ or ~/.claude/skills/), global, session (added temporarily), remote (cloned from git into remote_cache/), and bundled (built into the CLI). v1.0.77 added .agents/skills as a project-level discovery directory, aligning with the emerging cross-tool skills convention, so one skill folder can serve your whole zoo of agents.[8] When the same skill name exists in multiple places with different contents, the listing shows a conflict indicator and /skill sync reconciles local scope to global.[5]

And where Claude Code ships lean and expects you to bring skills, CoCo ships batteries included: a bundled catalog of roughly three dozen skills across a dozen categories, from dbt-projects-on-snowflake, dynamic-tables, openflow, and iceberg on the engineering side, through semantic-view, data-quality, lineage, and cortex-agent, out to governance packs like data-governance and trust-center and cost packs like cost-intelligence.[7] A separately installed Airflow plugin adds another set of skills across four domains: environment setup, DAG authoring and testing, data operations, and OpenLineage-based lineage tracing.[7] [8] This is what Sultan means by domain packs being Snowflake's preferred extension model, and it is the main reason the distribution is heavier than a bare agent.[17] Our ADE leans on $semantic-view and $data-quality directly; we only author what Glacier Goods does differently.

5.3 Distribution: four governed channels

Skills are also the unit of team sharing, with four documented channels of increasing governance: git repositories (/skill add https://github.com/org/my-skills.git, cached locally); Snowflake stages (cortex skill publish ./my-skills --to-stage @DB.SCHEMA.STAGE/skills/, consumed via cortex skill add @STAGE/..., access controlled by ordinary stage grants, so distribution rides existing RBAC); Snowflake git repository objects, keeping mirrored repos inside the platform boundary; and the Snowflake catalog, with shared skills surfacing in a Skills & Plugins area under Horizon Catalog in Snowsight, plus the /skill-catalog browser introduced at Summit for installing and publishing across the org.[5] [16] The full lifecycle CLI is cortex skill list | add | update | publish | remove, with versioned skill updates since v1.0.11; on the desktop surface the same registry appears in an Agent Settings panel with Packaged, Local, and GitHub sections, a recursive SKILL.md scan up to ten directories deep, and registration saved to ~/.snowflake/cortex/skills.json, shared with the CLI.[5] [8] [11]

Notice the progression: what starts as a Markdown file on your laptop can end its life as a governed, versioned, role-gated object in the catalog. Your playbooks graduate from tribal knowledge to infrastructure, which is exactly the trajectory we want the ADE's own procedures to follow.

Giving the ADE a Team: Subagents and Swarms

One engineer, however tireless, is a bottleneck, and an agent's version of a bottleneck is a polluted context window. Profiling forty tables in the main conversation buries your actual work under forty screens of column statistics. The fix is the same one organizations use: delegate, and let the specialist report back a summary.

Four come built in: general-purpose (all tools, for complex multi-step work), explore (fast codebase reconnaissance, with a documented thoroughness dial of quick, medium, very thorough), plan (implementation design and trade-off evaluation), and feedback (structured input collection).[5] Delegation is automatic when appropriate (a query like find all files importing the auth module routes to Explore) and explicit on request by name.[5] Snowflake also documents an agent-type axis orthogonal to specialization: autonomous agents complete without ever blocking on questions, while non-autonomous agents may pause to ask you or request permissions.[5]

6.1 The ADE's first direct report

A custom subagent is one Markdown file: YAML frontmatter for identity, tool grants, and model; body as the system prompt. Unlike a skill (injected context in your session), a subagent runs as an independent agent with its own system prompt, model choice, and tool permissions.[5] [20] Storage mirrors skills, dual paths included: project .cortex/agents/ or .claude/agents/, global ~/.snowflake/cortex/agents/, user ~/.claude/agents/.[5] Our ADE's first hire is the colleague every data team needs and few staff: someone whose entire job is to distrust the data.

.cortex/agents/data-quality-inspector.md
---
name: data-quality-inspector
description: Profiles Snowflake tables and produces a data quality report
tools:
  - snowflake_sql_execute      # tool allowlist; "*" grants everything
  - snowflake_object_search
  - Write
model: claude-sonnet-4-5       # per-agent model override; "auto" = cost-optimized
---

# System Prompt
You are a senior data quality analyst at Glacier Goods.

## Your Responsibilities
1. Profile the requested tables (cardinality, nullability, distributions)
2. Detect anomalies against expectations and flag suspect business logic

## Guidelines
- Read-only SQL; use warehouse ADE_XS; SAMPLE tables over 10M rows

## Output Format
Write reports/data_quality_report.md with severity-ranked findings.

The frontmatter fields are exactly four documented knobs: name, description, tools (a list, or "*" for all), and model (a specific identifier or auto for cost-optimized selection), which overrides the session default for that agent only.[5] Note the division of labor, which follows Kumar's build-a-subagent walkthrough: frontmatter governs capability, the prompt body governs behavior, so safety constraints and the output path live in the body.[20] Also note the model choice: the inspector runs on Sonnet because profiling is disciplined, repetitive work, and there is no reason to pay Opus prices for COUNT(DISTINCT).

6.2 Background execution, swarms, and worktrees

Agents can run in the background while you keep working: the launch returns an agent ID, output is retrievable by ID, /agents (or Ctrl-B) opens a background-process viewer covering agents and bash processes, and agents can be killed by ID; a killed agent retains its context indefinitely and can be resumed.[5] Documented limits: at most 50 concurrent background agents, agents inherit the session's permissions, and background agents cannot spawn further background agents, so nesting must be chained from the main conversation.[5] One field gotcha: on some builds, background execution is disabled by default at the CLI level (the agent reports background execution not enabled and falls back to foreground) and is switched on by editing settings.json; the undocumented CORTEX_AGENT_ENABLE_SUBAGENTS flag observed in the binary defaults to false and tells the same story, so verify on your version before architecting around parallelism.[20] [17]

Two composition patterns complete the delegation layer. A swarm launches several agents against different aspects of one task in parallel, aggregating results when all finish, and you create one simply by describing the roster in a prompt.[5] Here is the ADE's source-system intake, the first real workday of our build:

> Launch a swarm to intake GLACIER_RAW: one data-quality-inspector on SALES.ORDERS,
  one on SALES.CUSTOMERS, one on CATALOG.PRODUCTS, and one Explore agent (very
  thorough) mapping which downstream views already read these tables.
  Aggregate everything into reports/raw_intake.md with open questions ranked
  by how badly they block ORDERS_360.

Worktree isolation gives an agent its own git worktree and branch (named agent/<agentId>) so parallel agents cannot clobber each other's edits; request it inline (Run a background agent with worktree isolation to implement feature X) and manage manually with /worktree create | list | switch | delete.[5] [3] Kumar's series demonstrates the end state, four specialized subagents auditing a platform in parallel as a coordinated swarm,[21] and the changelog shows this layer moving fast: inter-agent messaging and stronger multi-agent coordination landed in v1.0.11, expanded swarm and background collaboration flows in v1.0.28, and Summit introduced Agent Teams for lead-agent orchestration across parallel roles.[8] [25]

Guardrails: Hooks as the Policy Plane

Now for the section that makes the ADE employable in a regulated company. Everything so far, handbook, playbooks, delegation, is probabilistic: the model follows it with high but imperfect compliance. Some rules cannot be probabilistic. Never drop a table is not a strong suggestion.

Readers of the previous post will recognize this as the deterministic layer of the V&V pyramid: the checks that must happen every time, no matter what the model is thinking. RBAC is your last line of defense, but as Kumar argues, RBAC stops at the database boundary while the agent operates across SQL, files, and shell simultaneously; hooks are the policy plane that spans all three.[21]

7.1 The event surface

Snowflake documents eleven events, two of which can block the action they precede:[5]

Migration drift warning for Claude Code users: Claude Code's hook reference documents events (for example PostToolUseFailure) that do not appear in Snowflake's list, and CoCo documents two handler types (command and prompt) where Claude Code documents four. Sultan's read, which matches the published tables, is to expect slight drift versus upstream workflows, especially around hooks and planning.[17] [5] Note also which events cannot block here: UserPromptSubmit and Stop are non-blocking in CoCo's table, so quality gates that force continued work are typically built as Stop-adjacent checks that re-inject instructions rather than hard blocks, a pattern practitioners report working well for auto-running quality checks on completion.[5] [19]

7.2 Configuration: scopes, matchers, handler types

Hook configuration lives in settings files across four scopes, highest priority first, dual Claude paths included: local uncommitted (.claude/settings.local.json or .cortex/settings.local.json), project (.claude/settings.json or .cortex/settings.json), user (~/.claude/settings.json), and global (~/.snowflake/cortex/hooks.json).[5] Plugins and connection profiles contribute a fifth and sixth source; the documented merge priority runs global, then user, then project, then local project, then plugin, then connection profile (highest), higher-priority source winning conflicts (Section 9).[10]

// .cortex/settings.json  (the ADE's rules of conduct, committed to git)
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "SQL*",
        "hooks": [
          { "type": "command",
            "command": "bash .cortex/hooks/ddl-blocker.sh",
            "timeout": 60 },
          { "type": "prompt",
            "prompt": "Does this SQL scan an unsampled table over 10M rows? $ARGUMENTS",
            "timeout": 30 }
        ]
      },
      {
        "matcher": "*",
        "hooks": [
          { "type": "command", "command": "bash .cortex/hooks/audit-logger.sh" }
        ]
      }
    ]
  }
}

The matcher field targets tools by name or regex: * for all tools, Bash exact, Edit|Write alternation, SQL* and Notebook.* prefix families, and mcp__.* for every MCP tool, which works because MCP tools are namespaced mcp__server__tool (Section 9).[5] Command hooks run scripts; prompt hooks evaluate a natural-language check with a model, a lightweight LLM-as-judge slot in the lifecycle.[5] Hooks can also be sourced remotely from a git repository via a source object (repo path plus ref), which is how teams pin shared policy scripts.[5]

7.3 The I/O protocol: JSON in, JSON out, exit 2 blocks

Hook scripts receive a JSON envelope on stdin describing the session, working directory, permission mode, event, tool, and tool input; they answer with JSON on stdout and/or an exit code. Exit 0 proceeds; exit 2 blocks. The JSON can allow or deny, attach a user-visible systemMessage, rewrite the tool input via updatedInput, inject additionalContext after a tool runs, or short-circuit the permission dialog with a permissionDecision.[5] Here is the hook that makes measure twice, DROP never an actual property of the system rather than a poster in the break room:

# .cortex/hooks/ddl-blocker.sh
#!/bin/bash
INPUT=$(cat)
SQL=$(echo "$INPUT" | jq -r '.tool_input.query // .tool_input.command // ""')
if echo "$SQL" | grep -Eiq '\b(DROP|TRUNCATE)\b'; then
  echo '{ "decision": "block",
          "reason": "Destructive DDL is not permitted for the ADE. Open a human-reviewed change instead." }'
  exit 2
fi
exit 0

# stdin the script received, for reference:
# { "session_id": "abc123", "transcript_path": "/path/to/transcript.json",
#   "cwd": "/working/directory", "permission_mode": "default",
#   "hook_event_name": "PreToolUse", "tool_name": "snowflake_sql_execute",
#   "tool_input": { "query": "DROP TABLE GLACIER_PROD.ORDERS_360" } }

# other stdout patterns the protocol supports:
# allow with a rewritten input:
# { "decision": "allow", "systemMessage": "Validated.",
#   "hookSpecificOutput": { "hookEventName": "PreToolUse",
#     "updatedInput": { "command": "ls -la --color=never" } } }
# auto-approve a permission prompt by policy:
# { "hookSpecificOutput": { "hookEventName": "PreToolUse",
#     "permissionDecision": "allow",
#     "permissionDecisionReason": "Approved by policy" } }

Three environment variables are injected into hook scripts: CORTEX_PROJECT_DIR (project path), CORTEX_CODE_REMOTE (true in web contexts), and CORTEX_ENV_FILE (a persistent env file path).[5] Best practices per the docs: keep hooks fast (60-second default timeout), fail open with exit 0 when uncertain, log to files for debugging, scope matchers tightly, and verify behavior in the /hooks manager.[5] [3]

The canonical worked example remains Kumar's Part 5, which wires four hooks into settings.json for a regulated-environment posture: the DDL blocker above, a cost guard (PreToolUse, denying queries predicted to scan excessively), an audit logger (PreToolUse, logging every operation and allowing), and a PII scanner (PostToolUse, injecting warnings into context when outputs look sensitive), plus a local test harness for validating hooks before trusting them.[21] The security docs show the inverse pattern too, hooks as accelerators rather than brakes: a PreToolUse hook that auto-approves known-safe bash by returning a permissionDecision of allow.[6] Guardrails that only say no train people to route around them; guardrails that also fast-track the safe path get adopted.

The Badge: Permissions, Sandboxes, and Identity

Every employee gets a badge, and no sane company gives the new hire master keys on day one. This is where the Snowflake-hardening thesis is most visible: the harness stacks five gating layers between model intent and side effects: operational modes, a risk classifier, a permission cache, hooks (previous section), and sandboxes, all beneath the account's own RBAC, which the agent cannot exceed because it acts as the connection's role.[6] [23] The ADE literally cannot see a masked column its role cannot see. Your existing governance investment is not bypassed by the agent; it is inherited by it.

8.1 Three operational modes, and the read-only rail

Shift-Tab cycles the modes in-session.[6] Two escape hatches exist beyond bypass, and both deserve their warning labels: --dangerously-allow-all-tool-calls disables tool-call prompts at launch, which for a data agent is roughly handing the intern a forklift license on day one, and going the other direction, even in bypass mode COCO_DANGEROUS_MODE_REQUIRE_SQL_WRITE_PERMISSION can force confirmation for SQL writes, a useful belt-and-suspenders default for data teams.[3] [6] [4] Since v1.0.77 there is also a dedicated read-only rail for the data plane: launch with --sql-read-only or toggle /sql-writes on|off|status in-session.[8] Our ADE's standing posture: plan mode for anything touching GLACIER_PROD, --sql-read-only anywhere it is merely investigating.

8.2 The trust model and the permission cache

Underneath the modes, an experimental classifier assigns each command a risk level that determines prompting behavior, with SQL getting its own categorical treatment:[6]

Permission requests themselves are typed (EXECUTE_COMMAND, FILE_READ, FILE_WRITE, FILE_EDIT, WEB_ACCESS), and the classifier is explicitly flagged experimental and subject to change, so hooks remain the right home for policies you cannot afford to have re-tuned under you.[6] The taxonomy is actively evolving: v1.0.77 moved tgrep and cron_create from auto-approve to prompt.[8] When prompted, you can remember a decision for the session or indefinitely; persistent grants land in ~/.snowflake/cortex/permissions.json in a project-keyed structure. Deleting the file resets everything, deleting a project's entry resets one project, /new or restart resets the session cache, and CORTEX_PERMISSION_CACHE_TTL_SECONDS tunes session-cache expiry.[6]

// ~/.snowflake/cortex/permissions.json
{
  "/home/nathan/ade-starter": {
    "Bash":  { "dbt build": "allow", "dbt test": "allow" },
    "Write": { "*": "allow" }
  }
}
// plus documented top-level policy keys:
{ "onlyAllow": ["read_file", "execute_sql"],
  "defaultMode": "ask",          # ask | allow | deny
  "dangerouslyAllowAll": false }

8.3 Sandboxes, in escalating tiers

Execution isolation comes in tiers. The /sandbox command manages two in-CLI layers, a container sandbox (/sandbox on|off|status) and an OS runtime sandbox (/sandbox runtime on|off), plus a mode switch between auto-allowing sandboxed commands and prompting for everything (/sandbox mode auto|regular); sandbox coverage expanded across platforms in v1.0.28, and the dedicated sandbox docs add filesystem allow/deny path rules and network domain allowlists, with deny always beating allow.[3] [8] [36] Above that, Summit introduced the Secured Local Sandbox (private preview), VM-based isolation that separates agent execution entirely from the local filesystem and OS, and Cloud Agents, which run in Snowsight inside a sandboxed, Snowflake-managed Linux container with shell, Python with pip install, file I/O, dbt runs against a generated profile, and live web search.[16] [30] [27] On macOS, the changelog also reveals a workspace primitive: ws create --hv=vz boots isolated workspaces in about a second using the Apple Virtualization framework directly.[8]

8.4 The identity boundary and the leak runbook

Everything above sits inside the Snowflake identity model. The agent authenticates as your connection (browser SSO recommended; PATs with at most 90-day expiry for scoped or automated use), operates strictly within the connection's role, and cannot reveal masked or hidden data that the role cannot see. The documented posture: least-privilege roles per environment, never ACCOUNTADMIN for routine work, chmod 600/700 on config, secrets only via environment variables, plan mode for production.[6] [23] If a PAT leaks, the runbook is revoke in Snowsight, rotate, then audit INFORMATION_SCHEMA.QUERY_HISTORY_BY_USER (real time) or ACCOUNT_USAGE.QUERY_HISTORY (up to 45 minutes latency) for suspicious activity.[6] There is something quietly elegant about that last part: the warehouse's own audit surface doubles as the agent's. Your ADE's every query lands in the same history as everyone else's, reviewable with the same SQL.

Wiring the Desk: MCP, Plugins, and Profiles

A data engineer with no Slack, no Jira, and no docs access is not onboarded, just seated. CoCo implements the Model Context Protocol in both directions: as a client that consumes external servers, and as a server other agents can delegate to. The client side is preview-labeled but fully documented.[1] [9]

9.1 The ADE as MCP client

Servers live under the mcpServers key in ~/.snowflake/cortex/mcp.json, with three transports (stdio subprocess, http, sse) and environment-variable expansion in every field so credentials never sit in the file; sensitive values passed on the CLI via -e or -H are migrated into the OS keychain on first connection.[5] [9]

// ~/.snowflake/cortex/mcp.json  (giving the ADE a git remote and an internal API)
{
  "mcpServers": {
    "git":    { "type": "stdio", "command": "uvx",
                "args": ["mcp-server-git", "--repository", "/home/nathan/ade-starter"] },
    "my-api": { "type": "http", "url": "https://api.example.com/mcp",
                "headers": { "Authorization": "Bearer ${MY_API_TOKEN}" },
                "oauth": { "client_id": "my-client-id",
                           "redirect_port": 8585, "scope": "openid mcp" } }
  }
}

# lifecycle from the shell
cortex mcp add git-server uvx mcp-server-git
cortex mcp add api https://api.example.com --type http -H "Authorization: Bearer token"
cortex mcp list | get <server> | start <server> | remove <server>

OAuth-configured HTTP servers open a browser for first-time auth; tokens are cached in ~/.snowflake/cortex/mcp_oauth/ and refreshed automatically.[5] Tools are namespaced mcp__{server}__{tool} to avoid collisions, which is also what makes hook matchers like mcp__github__.* and permission entries like "deny": ["mcp__github__delete_repo"] possible; tool names must be under 64 characters of alphanumerics, underscores, and hyphens.[5] [9] Operational limits worth designing around: tool results are capped at 50 KB (have servers return summaries or file pointers for large payloads), the default tool timeout is 60 seconds, and /mcp opens a live status viewer showing each server's transport, connection state, and exposed tool count, with ~/.snowflake/cortex/logs/mcp.log as the debugging trail; the v1.0.77 manager overhaul added split-pane search, source badges, OAuth state display, and invalid-tool diagnostics.[9] [8] On the governance axis, managed settings can disable user-defined servers entirely (areUserMcpServersAllowed: false makes the CLI ignore the user's mcp.json and skip plugin-declared servers), enforce a URL allowlist (non-permitted servers are silently removed after merge), and ship enforced base servers users cannot remove.[9] [35]

9.2 The ADE as MCP server: a delegable specialist

Run in server mode, CoCo speaks MCP over stdio to any MCP client (Cursor, Claude Desktop, other agents), exposing tools that hand the caller the full CoCo agent loop plus Snowflake catalog search, Cortex Analyst, and Cortex Agents discovery.[9] Snowflake leans into this cross-agent posture with Snowflake-Labs' subagent-cortex-code, an installable skill and CLI tool that routes Snowflake-specific operations from Claude Code, Cursor, Codex, Copilot, or Windsurf to Cortex Code, with routing rules, approval and audit security envelopes, and headless execution.[32] Summit extended the same idea into first-party channels: a Claude Code plugin, VS Code and Excel extensions, and a Slackbot that executes under the invoking user's role.[16] [27] [30] [39] Read that as an org chart: your general-purpose agent keeps everything else, and the ADE is the specialist it consults for anything wearing a fully qualified table name.

9.3 Plugins and profiles: shipping the whole desk

By now the ADE is a small ecosystem: a handbook, two skills, a subagent, four hooks, two MCP servers. A plugin is the deployable quantum that bundles all five extension surfaces under a single manifest, shareable from a git repository, installable from the official marketplace, or shipped inside a Snowflake connection profile.[1] [10] One install, five surfaces:

glacier-ade/                       # the ADE, boxed for the whole team
├── .cortex-plugin/                # or .claude-plugin/ (.cortex-plugin wins if both)
│   ├── plugin.json                # manifest (required)
│   └── activation.md              # optional; surfaces a re-enable skill when inactive
├── skills/data-product/SKILL.md   # auto-discovered by convention
├── agents/data-quality-inspector.md
├── commands/intake.md             # custom slash commands ride along too
├── hooks/hooks.json
└── .mcp.json

The manifest's component fields are optional; omit them and CoCo picks up the conventional subdirectories automatically, which is the documented recommendation.[10] At session start, or on /plugin reload, every active plugin's contributions merge into the live runtime: skills join the registry tagged with their origin, subagents join the search path, slash commands register, hooks merge under the fixed priority order from Section 7, and MCP servers join the connection manager at lower priority than user and profile servers, skipped entirely if the administrator disabled user MCP.[10] A plugin declaring requiresSandbox: true starts the sandbox runtime for the session when available.[10] Develop with --plugin-dir or drop the folder into .cortex/plugins/ for auto-load; validate with cortex plugin validate (per-component reports); publish to git or use the registry-backed marketplace flows added in v1.0.65 with runtime reloads.[10] [8] Name collisions resolve by discovery order, a project plugin overriding a managed marketplace plugin of the same name, and the standing rule is to keep credentials out of manifests: MCP entries use env expansion or OAuth.[10] The desktop app even ships a plugin-creator skill that interviews you and scaffolds the folder.[11]

Where a plugin packages capabilities, a profile packages a working posture: each profile bundles a Snowflake connection, a model override, and settingsOverrides that slot in just under managed restrictions in the precedence chain.[22] [4] Field usage looks like cortex profile create prod-readonly and cortex --profile prod-readonly, with practitioners maintaining entirely different skill sets per profile: different brain, different toolbox, same CLI.[22] Profiles are also a distribution vehicle: cortex profile publish data-analyst --skill-stage @DB.SCHEMA.STAGE/skills/ publishes a profile referencing a shared skill stage, and connection profiles can carry plugins and MCP servers to a whole team, sitting at the top of the hook merge order and above user servers in MCP priority.[5] [10] Profiles gained richer capabilities alongside easier tool allow/deny controls in v1.0.28.[8] For Glacier Goods, that means an ade-dev profile with the full toolbox and an ade-prod-readonly profile whose posture is exactly what the name says.

Going On-Call: Automation Surfaces

Here is the punchline of hiring an engineer made of tokens: it never sleeps, which is convenient, because neither do data quality incidents. Once the handbook, playbooks, and guardrails exist, the interactive session stops being the point. The ADE's real shift starts when you close the laptop.

10.1 Headless mode: the Unix-filter ADE

The CLI is scriptable in the familiar Unix-filter pattern: -p "<prompt>" runs a single prompt, prints, and exits; -f request.txt reads the prompt from a file; --output-format stream-json emits structured output for pipelines; and -c plus --workdir pin connection and context for CI use.[3] Exit codes are documented for gating: 0 success, 1 general error, 2 configuration error, 3 connection error, 4 permission denied, 130 user interrupt, which composes cleanly with --sql-read-only and --plan for safe unattended runs; Snowflake's guidance for pipelines is PAT authentication rather than SSO.[3] [8] [23] The ADE's nightly rounds:

# nightly-freshness.sh: the ADE walks the floor at 2am
cortex -c ade-prod-readonly --workdir /srv/ade-starter --sql-read-only \
  -p "Run \$data-quality on GLACIER_PROD.ORDERS_360: freshness vs yesterday,
      row-count delta, null-rate drift on keys. Write reports/nightly.md.
      Summarize PASS or the top three findings in one paragraph." \
  --output-format stream-json > /var/log/ade/nightly.json

# gate downstream jobs on the ADE's verdict
if [ $? -ne 0 ]; then page_the_humans; fi

User-defined slash commands round out the macro layer: files in ~/.snowflake/cortex/commands/ (plugins can contribute more), managed with /commands, naming and collision handling expanded in v1.0.9. They are reusable prompts promoted to first-class verbs, one notch lighter than a skill.[4] [3] [10] [8] Built-ins worth knowing while you are in there: /doctor diagnoses the environment, /clear-cache resets caches, /docs jumps to documentation, /changelog shows release notes in-CLI.[22] [8]

10.2 Editors, SDK, and the cloud shift

Three more automation surfaces extend the same loop. ACP: CoCo implements the Agent Client Protocol so editors like Zed, JetBrains, VS Code, and Neovim can embed it as a local agent backend, the editor driving the session while CoCo streams responses, tool calls, and file diffs back; concretely, cortex acp serve (added v1.0.59) provides streaming editor sessions with native permission routing and diff-based edit previews, and since v1.0.77 editors can supply a session identity via _meta.sessionId.[1] [8] The Agent SDK (preview) exposes the same tools and agent loop to Python and TypeScript applications: file reads, command execution, codebase search, SQL execution, code editing; v1.0.77 added custom MCP tool definitions and hook callbacks at the SDK level, meaning the deterministic policy layer extends into embedded deployments too.[1] [8]

And Summit pushed the harness off the laptop entirely. Automations run CoCo on a schedule for recurring, event-driven workflows (monitoring, validation) with no manual trigger; Cloud Agents execute tasks launched from Snowsight in a secure cloud sandbox so nothing must stay open locally; and the Cloud Agent API is a REST endpoint through which CI/CD, Slack, cron, and internal applications can kick off CoCo runs.[16] [27] [30] Combined with the Slackbot, which executes strictly under the invoking user's role and permissions, the pattern is clear: the same harness semantics, invoked from wherever the team already works.[30] The February expansion made dbt and Apache Airflow first-class domains along the way: optimized skills with schema-, dependency-, and orchestration-aware understanding, /dbt and /lineage commands with lineage visualization, and a cortex airflow command family for testing DAGs and tracing schema-change blast radius; v1.0.59 added Postgres connection management and dialect-aware /sql, v1.0.28 shipped cortex browser for agentic web workflows, and cortex secret (v1.0.6) rounds out local credential tooling.[13] [3] [15] [8]

Step back and notice what happened to our job description. The ADE started as a chat window. It is now a scheduled worker, a Slack colleague, an editor backend, an embeddable library, and an MCP specialist other agents consult. Same handbook, same playbooks, same guardrails, every surface.

The Performance Review: Evidence and Caveats

Ninety days in, every hire gets a review, and so should the harness. Two quantitative claims exist, both Snowflake-run, both on ADE-Bench, the analytics and data engineering benchmark maintained by dbt Labs.[37] [26]

The controlled February comparison. On the dbt-plus-Snowflake ADE-Bench task set with the same underlying model, Claude Opus 4.6, in both harnesses, Cortex Code completed 28 of 43 tasks (65%) versus Claude Code's 25 of 43 (58%), and reached solutions with roughly 50% fewer total tool calls, including about 2x fewer file reads and 4x fewer bash commands, an efficiency Snowflake attributes to the SQL-native snowflake_sql_execute path enabling exploration inside the warehouse instead of around it.[13] This is the methodologically cleaner result, and it is exactly the harness effect from Section 1 in miniature: hold the model fixed, swap the scaffolding, watch the number move.

The Summit-era headline. A CoCo run scoring 72.1% on ADE-Bench versus 65.1% for both Claude Code and Codex, with Snowflake's data engineering blog adding 51% fewer tokens and 8% fewer steps against Claude Code on Opus 4.7.[26] [25] [37] The caveats matter as much as the numbers: the benchmark is independently maintained but the CoCo measurements are Snowflake's own, and as of early June 2026 no independent replication had been published.[26] Customer ROI figures circulating from the GA launch are vendor-published testimonials and should be weighted accordingly.[13] None of this makes the numbers wrong. It makes them a hypothesis you are equipped to test, because after ten sections you know exactly which mechanisms would produce them.

11.1 Where the harness is genuinely strong

Reading across the official material and independent reviews, four strengths are consistently corroborated. Context acquisition: RBAC-filtered catalog answers, live lineage and statistics, and one-sigil schema injection remove the file-spelunking tax that dominates generic agents on data work; this is the mechanism behind the measured tool-call efficiency, not just marketing.[13] [14] Governance depth: six-layer settings precedence, managed org policy, a typed permission system with risk classification, SQL-specific write gates, hooks as a deterministic policy plane, multi-tier sandboxing, and distribution channels that ride existing Snowflake RBAC; no other mainstream coding harness ships this much enterprise control surface in the box.[4] [5] [6] [17] Ecosystem openness: deliberate .claude/ path compatibility across skills, agents, hooks, and settings lowers migration friction to near zero for Claude Code teams, and the MCP server mode plus the first-party Claude Code plugin let CoCo behave as a Snowflake specialist inside whatever harness you already run.[5] [17] [32] [39] Field reception: hands-on reviewers found the tool immediately familiar and genuinely effective at Snowflake-specific work that generic assistants historically fumbled (account cleanup, Streamlit-plus-table scaffolding), while a working DBA described it becoming integral to daily SQL-analysis workflows within weeks of early access.[18] [33]

11.2 Where to be skeptical, and what it costs

The weaknesses are equally consistent. Baseline weight: roughly 7 KB of system-reminder scaffolding per turn buys reproducibility at the price of tokens, cache pressure, and latency; whether that trade favors you depends on how governed your environment needs to be, and it is the single biggest felt difference from vanilla Claude Code.[17] Drift from upstream: the hook event set and handler types diverge from Claude Code's documented surface, so ported automations need auditing rather than copying.[17] [5] Documentation lag: load-bearing behavior lives in undocumented environment variables and settings toggles (thinking effort, iteration caps, summarization threshold, background-agent enablement), and several pillars still carry preview labels in the docs: MCP, plugins, the Agent SDK, and Desktop, which Summit coverage announced as GA even as the docs and Snowflake's own June engineering blog kept the preview banner, a tidy little case study in why this tutorial cites the docs.[17] [20] [1] [24] [37] So version-pin anything you depend on. Availability and enablement friction: the product requires commercial account types with cross-region inference enabled, inherits any historical Snowflake Copilot disablement (fixable only through your account team), gates web search behind ACCOUNTADMIN enablement, and reviewers found MCP setup nontrivial.[23] [2] Memory defaults: cross-session context is off by default (AGENTS.md is your persistence primitive until you opt into the memory tool), and conversely, session transcripts persist to disk by default, so --private discipline belongs in your team norms.[23] [6] [17] And the perennial one: it still makes mistakes and needs supervision; the consensus practitioner verdict is leverage, not autopilot, with plan mode for anything you cannot easily undo.[33] [18] [23]

The Finished Onboarding Packet

Pulling it all together, here is the ADE's complete onboarding packet, annotated with the section that governs each piece. Every path shown is documented, and the .claude/ twins work identically where noted.

ade-starter/
├── AGENTS.md                        # the handbook: persona, conventions (Sec 4)
├── .cortex/                         # or .claude/ for skills, agents, settings
│   ├── settings.json                # project settings + hooks (Sec 4, 7)
│   ├── settings.local.json          # personal, uncommitted overrides (Sec 7)
│   ├── skills/
│   │   ├── staging-model/SKILL.md   # $staging-model playbook (Sec 5)
│   │   └── data-product/SKILL.md    # $data-product playbook (Sec 5)
│   ├── agents/
│   │   └── data-quality-inspector.md# the first direct report (Sec 6)
│   ├── hooks/
│   │   ├── ddl-blocker.sh           # deterministic policy (Sec 7)
│   │   └── audit-logger.sh
│   └── plugins/                     # auto-loaded project plugins (Sec 9)
├── .agents/skills/                  # cross-tool skills convention, v1.0.77+ (Sec 5)
├── reports/                         # the ADE's written work product
└── models/ dags/ semantic/ ...

~/.snowflake/cortex/                 # user/global layer (Sec 4)
├── settings.json  permissions.json  mcp.json  hooks.json
└── skills/ agents/ commands/ profiles/ memory/

And the order of operations, which matters more than any individual file. A minimal, high-leverage onboarding sequence: (1) write a sub-200-line AGENTS.md capturing the conventions you currently re-explain; (2) promote your two most repeated workflows to skills and your one most dangerous failure mode to a PreToolUse hook; (3) create a read-only profile for production connections and make --plan or --sql-read-only the default posture there; (4) only then reach for subagents and swarms, once the policy plane exists to contain them. Persona, then skills, then enforcement, then parallelism: the same progression Kumar's five-part series converges on, and it matches Snowflake's own best-practice guidance to keep requirements in Markdown, review privilege changes carefully, and let plan mode gate anything irreversible.[21] [15]

From there, the ADE roadmap writes itself, and it mirrors where Snowflake's own research energy is pointed: spend unreasonable amounts of time at the acquisition layer defining, annotating, and embedding business logic and data definitions, because that is the context every downstream agent inherits; publish one wide data product per business domain instead of a lattice of clever views, because agents pay per JOIN in reliability; and put a semantic view in front of each product, because natural language is becoming the query language of record and the semantic layer is where its accuracy is won or lost.[37] [16] [28] The previous post argued that in agentic software engineering, the specification is the durable artifact and code is the byproduct. The data version of that claim is the thesis of this whole build: the business meaning is the durable artifact, and the pipelines are the byproduct. Onboard your ADE accordingly, and it will return the favor with data your other agents can actually trust.

References