# Snowflake Cortex Coding Agent Adds Reasoning Controls and Stage Mounts

Snowflake adds reasoning effort, system instructions and stage mounts to Coding Agent, alongside Cortex Code skills for interactive analytics.

By Paras Madan | 2026-10-28


Snowflake has added reasoning controls and stage mounts to its Cortex Agents Coding Agent API. The October 28 update gives developers more control over a managed coding session. It follows new Cortex Code skills for configuring interactive analytics and testing whether queries meet a latency target under load.

These updates address different parts of the same workflow: supplying an agent with the right files and instructions, then checking the behaviour of the system it helps build.

## Three new Coding Agent request controls

The [October 28 release note](https://docs.snowflake.com/en/release-notes/2026/other/2026-10-28-cortex-agents-coding-agent-thinking-effort-stage-mounts) adds three fields to requests using `code_toolset_all`.

`thinking_effort` selects reasoning effort. The accepted values range from `minimal` through `max`, but each model supports only a subset. Requests above a model's supported range are reduced to its highest accepted level. Omitting the field preserves that model's default.

`instructions.system` appends instructions to the managed coding-agent prompt. It does not replace the existing instructions for the sandbox, tools or skills. That lets an application add its working requirements without treating the field as a replacement for Snowflake's managed setup.

`stage_mounts` makes ordinary Snowflake stages and versioned objects available inside the sandbox. Supported versioned objects include notebooks, Streamlit apps, workspaces and agents.

## Choose the mount and access deliberately

Snowflake's [Coding Agent guide](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-coding-agent) distinguishes stage mounts from `workspace_mounts`, which remain the route for a persistent, writable workspace at its live version.

A stage mount can select a version and a custom sandbox path. Its `readonly` setting defaults to false, so an application that only needs an agent to inspect source material should explicitly choose read-only access. Each mount needs a stage name, a stage-type flag and a path. Versioned stages also require their namespace; conflicting mount paths are rejected.

The hosted agent can be called through REST, SQL or a Snowflake-managed MCP server. API access requires an appropriate Cortex database role, and REST calls also need an authorization token. The full coding toolset cannot appear in the same request as the separate `code_execution` tool.

For an internal application, a useful first test is to mount a specific input version read-only and ask for an analysis without allowing edits. Add writable output locations only where the workflow needs them. This makes it easier to distinguish a bad answer from an unintended file change during testing.

## New skills test interactive analytics under load

The [October 27 skills announcement](https://docs.snowflake.com/en/release-notes/2026/other/2026-10-27-interactive-cortex-code-skills) introduces `snowflake-interactive` for query suitability, clustering and warehouse configuration. It works in Cortex Code CLI, Desktop and Snowsight.

The companion `interactive-benchmark` skill is available in CLI and Desktop, not Snowsight. It checks a query against a latency goal under concurrent use.

According to the [interactive skills guide](https://docs.snowflake.com/en/user-guide/interactive-skills), benchmarking deploys an API and a Locust load generator to Snowpark Container Services. Before starting, the agent asks the user to confirm the scope, including maximum warehouse size, cluster count and escalation iterations.

Each load test runs for three minutes. The agent can adjust capacity and repeat the test within the confirmed limits, then produce an HTML report and offer to remove or retain the benchmark resources. Defaults include a one-second P95 goal and 50 concurrent users; these are test settings, not promised performance.

Running it requires local dependencies, a configured Snowflake connection, access to Snowpark Container Services and privileges to create the benchmark resources and public service endpoints.

The practical benefit is a more reproducible check than asking an agent whether a query looks fast. Keep the confirmed resource limits with the report, review whether the load resembles real usage, and decide what to retain when the test ends.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn developer-platform updates into clear explanations of what changed, how to use it and where the limits matter.

[Book a 30-minute call](https://cal.com/paras-madan/30min).