Snowflake has opened a public preview of CoCo automations, a feature that puts AI agent runs on a schedule. Register a single prompt and the agent executes periodically inside a Snowflake-managed sandbox, even with your terminal or browser closed. Automations created from the CLI and from Snowsight are the same object, and the feature is available in all commercial regions on AWS, Azure, and Google Cloud.

One prompt is all you register

The idea behind automations is straightforward: write what you want done in plain language, then choose how often it should run. Every execution leaves behind a Cortex thread, so you can open it later and inspect the agent's messages, tool calls, results, and final response.

Snowflake lists uses such as generating a daily performance recap, checking metrics for anomalies, monitoring warehouse usage and cost, checking data freshness, running periodic data-quality or repository-maintenance workflows, and producing a scheduled digest from a connected MCP server. In other words, the kind of work someone used to catch by glancing at a dashboard each morning.

In Snowsight you start from a template or from scratch, then enter a title and instruction, pick the model, and configure frequency, days, time, and time zone. You can also ask CoCo conversationally, along the lines of asking it to check yesterday's pipeline failures every weekday at 9 AM and write a short summary. From the CLI it looks like this:

cortex automation create \
  --name pipeline_health \
  --prompt "Check pipeline failures from the last hour and summarize the likely causes." \
  --schedule "every 60 minutes"

Schedules accept intervals such as every 4 hours, as well as forms like daily at 9am or every Tuesday at 1:15pm. When you list several weekly times at once, the CLI may create more than one underlying task.

Runs happen in a sandbox Snowflake provides

Each automation is stored as an AGENT TASK in your personal database. When the schedule fires, Snowflake runs the saved prompt as the user who created it, starts CoCo inside a managed sandbox with a working directory prepared, and records task state, timing, query ID, and errors in task history. No warehouse is required.

When you create an automation from the CLI, your workspace stage is mounted as the working directory, so files written there persist across runs. You can mount a different stage instead, or skip the mount entirely and treat the workspace as ephemeral.

Permissions follow the person who created it

This is where operational care matters most. Automations use a caller's-rights model: each run executes as the creating user, with that user's default role and default secondary roles active. The role that happened to be active in the CoCo session at creation time is not recorded. A prompt that worked interactively can fail on a schedule, or return incomplete results, because of that mismatch.

On top of that, the EXECUTE AGENT TASK privilege required to use automations is granted to the PUBLIC role by default. Unless an administrator changes it, every user in the account can create scheduled runs. To narrow that down, revoke the privilege from PUBLIC first, then grant it to the roles that need it.

REVOKE EXECUTE AGENT TASK ON ACCOUNT FROM ROLE PUBLIC;
GRANT EXECUTE AGENT TASK ON ACCOUNT TO ROLE automation_user;

Because runs are unattended, the interactive tool permission prompts are disabled. Any tool available to the run can execute without waiting for approval, and Snowflake states plainly that destructive or irreversible actions should not be scheduled unless the prompt, privileges, connected tools, and target objects are deliberately configured for it. It is also worth remembering that if a user's default secondary roles include every role granted to them, a run can reach a very wide surface.

A failing hook still reports success

You can attach bash commands as hooks that run before and after each execution. They do not consume an agent turn and behave identically every time, which suits fixed work such as cloning a repository or cleaning up afterwards.

The behavior has sharp edges, though. A hook that exits with a nonzero status does not fail the run. If the pre-run hook fails, the sandbox stays unavailable, and the agent still starts and reports that it cannot do the work, while task history records the run as succeeded. If a post-run hook is what publishes the result with a git push, the output can be lost while the run still shows success. The mounted workspace stage does not support appending to an existing file, so Git trips over its reference log, and Snowflake recommends cloning outside the mounted workspace when a hook needs to commit. Task state alone is not enough; the thread transcript has to be read.

Limits during the preview

The shortest supported interval right now is once per hour. The CLI parser will accept shorter values, but they are not supported in the preview. Threads and run history are retained for two months, schedules are strictly time-based with no event triggers, and you cannot attach to a run in progress or resume it interactively. The feature is not available in government, FedRAMP, DoD, VPS, or China deployments. During the preview, user-created automations incur standard task billing on top of token consumption for each run.

Summary

CoCo automations moves the interactive agent into something that runs on its own at a set time. Keeping everything inside the data platform and leaving each run as an inspectable thread looks like a sensible design. The items to verify before production, however, are clear: permissions are tied to the creator's default role, EXECUTE AGENT TASK ships granted to PUBLIC, and a failed hook is recorded as a success. The more autonomous the run, the more the first manual execution and a careful read of its transcript pay off.