Architecture

The Warehouse Gains an Agent Control Surface: Snowflake's thinking_effort, stage_mounts, and dbt's Agents Schema

By IdeaBosqueLast updated: October 29, 2026

On October 28, 2026, Snowflake shipped three new controls on the agent:run API of Cortex Agents: thinking_effort, instructions.system, and stage_mounts (Snowflake release notes). A warehouse runtime now exposes the three things agent platforms traditionally keep for themselves — how hard the model thinks, what house rules the runtime enforces, and which versioned artifacts the agent may mount. The same month, Fivetran and dbt Labs completed their merger "to create the data infrastructure for trusted AI agents" and the combined platform carries an Agents Schema that gives agents warehouse-native context instead of ad hoc extracts (Fivetran press release).

This article maps the three Snowflake control surfaces, the context layer arriving beside them, and the boundary they do not close: approvals, cross-tool policy, and the audit trail still belong to the orchestration layer above the warehouse. For a lean team — one Snowflake account, two dbt developers, agents starting to run scheduled work — these are the first knobs you can set inside the warehouse itself, and knowing what they do and do not bind is the difference between governance and theater.

Key takeaways

Snowflake shipped three agent controls on October 28, 2026 — thinking_effort (minimal through xhigh, per-model subsets), instructions.system (appended system instructions inside the runtime), and stage_mounts (versioned stage mounts) on the Cortex agent:run API (Snowflake release notes).
stage_mounts binds artifacts by version, not by branch — notebooks, Streamlit apps, workspaces, and agents mount as versioned stages; writable workspace_mounts stay unchanged at version live (Snowflake release notes).
dbt and Fivetran's completed merger ships the Agents Schema — the merged platform's stated purpose is "the data infrastructure for trusted AI agents," putting governed context rows where agents consume them (Fivetran press release).
dbt × Amazon Redshift data sharing (documented by dbt on October 9 and by AWS on the big-data blog) moves multi-cluster pipelines without moving a byte — governed shares plus SVV_* metadata APIs and a datasharing config replace extract-then-copy (dbt blog; AWS big-data blog).
The knobs bind effort, instructions, and mounts — not policy — approvals, revocation, and audit across the warehouse, NetSuite, HubSpot, and the rest of the agent's reach stay with the orchestration layer.

What shipped on October 28, and where each control sits

thinking_effort is the reasoning-effort knob: a range from minimal to xhigh, with per-model subsets that constrain which values a given model accepts. Practically, it is the call that moves model effort from an API-side default into a per-run setting the warehouse records. A scheduled agent that reads a freshness table does not need the same effort budget as one that reconciles invoice line items; until October 28 that distinction lived in whatever harness invoked the model, and now the warehouse executes it as a declared parameter of the run.

instructions.system appends system instructions inside the runtime. This is the house-policy slot: the operating rules your organization wants attached to every agent run — what the agent may summarize, what it must flag for a human, how it should handle missing context — travels with the invocation instead of living in a prompt template maintained by whoever built the agent. The honesty marker matters here: appended instructions are not a permission system. They shape behavior inside the runtime; they do not revoke anything.

stage_mounts is the artifact boundary. The agent:run API now accepts versioned stage mounts — notebooks, Streamlit apps, workspaces, and agents themselves — while writable workspace_mounts remain unchanged at version live. An agent bound to a versioned stage sees a pinned artifact set, not whatever is on the branch right now. That is the same instinct behind pipeline pinning and manifest pinning elsewhere in the agent stack, expressed at the warehouse boundary where the artifacts actually live.

The diagram below maps the three control surfaces against the layers above and below them — the orchestration layer where policy stays, and the context and movement layers arriving underneath.

The context layer arrived first

Controls only matter against something, and the something arrived on the context side first. Fivetran and dbt Labs closed their merger with an explicit thesis: the combined company exists to build "the data infrastructure for trusted AI agents" (Fivetran press release). The Agents Schema carries that thesis into the warehouse — governed, modeled rows that an agent consumes the way a dashboard consumes a metrics table, rather than the ad hoc extract an agent assembles by trial and error against a SQL endpoint.

The movement question gets the same treatment. dbt now supports Amazon Redshift data sharing, and AWS's big-data blog documents the multi-cluster pattern — SVV_* metadata APIs and a datasharing config that build multi-cluster pipelines without copying a byte (dbt blog; AWS big-data blog). For an agent, this is the difference between an environment assembled from governed shares — where lineage and access rules hold — and one assembled from extracts, where every copy is a new access question. Dagster's repositioning around the same thesis ("Data your team trusts. AI that runs on it.") says the same thing from the orchestrator's side of the fence (Dagster).

Read together, the three surfaces form one pattern: context is governed where it is modeled, movement is governed where it is shared, and effort, instructions, and mounts are governed where the run happens. That is a warehouse-first answer to a question agent platforms have been answering with bespoke code.

What the knobs leave open

What the controls do not bind is policy across systems. An agent that reads warehouse pricing models, checks BigCommerce stock, and writes approved quotes back to NetSuite crosses three vendor boundaries and one protocol boundary. The Snowflake parameters govern exactly one of those boundaries; nothing in the release notes revokes a BigCommerce token, and nothing in instructions.system produces an audit record in NetSuite. Approvals, revocation, and the single cross-tool audit trail have to live with the orchestration layer — the module pattern that wraps each system as typed tools with their own authentication and logging (MCP module code standard).

There is an honest limit to state plainly: the release notes document parameters, not guarantees. Audit behavior for agent:run calls — what is logged, retained, and queryable — is not something the notes we reviewed specify, and per-model subset support means one team's xhigh is another team's unavailable setting. Treat the three controls as declared inputs, verify the audit trail on your account, and keep the kill-switch above the warehouse (AI governance checklist).

A lean-team read

For a mid-market team running its first scheduled agents against the warehouse, October 28 changes the setup conversation in five ways. Inventory which agents touch the warehouse at all — scheduled ones first. Set thinking_effort consciously per workload: a freshness check at minimal, reconciliation at higher effort, and record which tasks got which budget, because that mapping is your per-unit cost story. Put house policy in instructions.system once instead of maintaining it across every prompt template. Bind scheduled agents to versioned stage mounts, so a Streamlit dashboard the agent reads is the version someone tested, not the one that changed this morning. And keep approvals and revocation in the orchestrator's manifest — the warehouse controls what a run looks like; the orchestrator controls what a run is allowed to do and leaves behind.