The Agent Is Now a Pipeline Step: Keeping CoCo Automations and Cloud Agents Reproducible

Running Snowflake in the Agent Era, Part 4 of 4. An agent on a schedule is a pipeline step, and it needs the same review, versioning, and deploy path as everything else.

During the proof of concept for this post, one of our scheduled agent runs reported success. The result was wrong. The task did not fail, so the run state had nothing to say about it. The agent had simply done the job wrong, on a schedule, with nobody watching.

That was the moment I stopped thinking of agents as a chat window. An agent that runs at 3am, reads tables, and writes something somewhere is a pipeline step. And every other pipeline step on my platform is versioned, reviewed, and deployed through a plan. This post is about giving agents the same treatment.

In Part 1 of this series I listed “an automation running a nightly health check” as one of the reasons agent SQL is spiky. In this part that automation is the subject.

When the agent stops being a chat

The first three parts of this series treated agents as consumers. They burn compute (Part 1), they need an organization that governs them (Part 2), and they need budgets and quotas (Part 3). This part treats them as producers: something that runs on its own and changes things.

The tooling is now mature enough for that question to be real. Cortex Code (CoCo) CLI has been generally available since February 2026, CoCo in Snowsight since March 2026, and CoCo Desktop since July 2026. In the last few months, Snowflake added the two pieces that move CoCo from “a session I am watching” to “a job that runs without me”: automations and Cloud Agents.

Like Part 1, this was a proof of concept, not production. We tried CoCo automations, Cloud Agents, the CLI --cloud mode, and DCM Projects (generally available). DCM, short for Database Change Management, is Snowflake's way to describe objects as code in definition files and deploy them through a plan you review first. We used them on three kinds of work:

• Health and data quality checks on a schedule
• Drafting dbt models or DCM definitions for a human to review
• Investigating failed pipeline runs

I am keeping the scale qualitative. What matters here is not how many runs we did, but what the defaults did to us.

CoCo automations: an agent on a schedule

CoCo automations have been in preview since August 2026. An automation turns a saved prompt into a recurring, unattended CoCo run that executes in a Snowflake-managed sandbox, even when your terminal or browser is closed. Each run creates a Cortex thread you can inspect and continue later. An automation created in the CLI shows up in Snowsight and the other way around, because both create the same Snowflake object.

That object is the part a platform engineer should look at first. Each automation is stored as an AGENT TASK, a type of Snowflake task, in the PUBLIC schema of the user's personal database (USER$.PUBLIC), with an internal name that starts with COCO_ROUTINE_. It is owned by the user, not by a role. It needs no warehouse. By default the user's USER$.PUBLIC.DEFAULT$ stage, a file area in that personal database, is mounted at /workspace, the run's working directory, so files persist between runs.

Creating one from the CLI looks like this. This is the example from the documentation:

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

Two options matter for reproducibility. --prompt-file reads the prompt from a file instead of the command line, and --dry-run prints the generated task information and SQL without creating anything. Schedules are fixed and time based, such as daily at 9am or every Tuesday at 1:15pm with an IANA time zone. The minimum supported frequency is hourly, and there are no event triggers yet.

CoCo Desktop also has automations, but they are a different thing: saved prompts stored on one machine that run only while the app is open and the computer is awake. For pipeline work, I only consider the Snowflake-hosted kind.

Cloud Agents: the same agent, off your laptop

Cloud Agents are generally available in all commercial regions on AWS, Azure, and Google Cloud. Every CoCo session in Snowsight now runs in its own Snowflake-managed container, which means CoCo in the browser can run shell commands and Python scripts, and search the web once an ACCOUNTADMIN enables it.

The boundaries are what make this usable for pipeline work. The filesystem is scoped to the session. Outbound network access is restricted, not disabled: outbound HTTPS traffic (egress) only reaches an allowlist of package managers and build tooling, and only for reads, so installing a package works and publishing does not. External access integrations are not supported. Cloud Agents does not change any RBAC (role-based access control) settings or add SQL access, and for now it comes at no additional cost, with pricing possible in a future release.

The CLI has the same idea behind --cloud, which is generally available and which the docs describe as the CLI equivalent of Cloud Agents in Snowsight. Tools run in a Snowflake-managed container, your local files are never visible to the agent, and only the mounted /workspace persists. Everything written anywhere else is discarded when the session ends.

In the POC we used cloud sessions for two jobs: investigating failed runs, and drafting dbt or DCM code that a person would then review.

What surprised me

Three things caught us in the POC, and all three are documented. We just had not read that part of the page carefully enough.

Runs used the creator’s default role. Each automation run starts a task session whose primary role is the user’s default role, plus their default secondary roles. It is not the role that was active when the automation was created, and that role is not recorded on the task. So an engineer whose default role is powerful can create an automation in a careful session with a narrow role, and the automation still runs with the powerful one.

Everyone could schedule agents. Access to automations is controlled by the EXECUTE AGENT TASK account privilege, and it is granted to PUBLIC by default. In a fresh account, every user can schedule an unattended agent.

Nobody approves anything, and success is not correctness. Automation runs are unattended, so interactive tool permission prompts are disabled. That is the run I opened this post with: the task succeeded and the outcome was wrong. The documentation is direct about this. Task history is the authoritative source for run state and errors, but a successful task can still produce an incomplete business outcome. The transcript is where you find out.

The defaults I changed

None of these changes are clever. They are the same controls I would put on any service that can run SQL unattended.

First, the privilege. I revoked it from PUBLIC and granted it to a role for the people who are allowed to own automations. This is the documented pattern:

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

Second, the role a run actually uses. Because a run takes the owner’s default role, the users who own automations got a narrow default role. That role decides what a 3am run can touch, so it is the one to design, not the role in someone’s open session.

Third, interactive chats. User-managed Restricted Session Scope became generally available in September 2026 in CoCo CLI, CoCo Desktop, and CoCo in Snowsight. It restricts a single CoCo chat to read-only access or to selected roles, and it can only narrow privileges, never add them. We used read-only scope for chats. One caveat: the CLI --cloud mode does not support restricted session scope or --sql-read-only, and the CLI exits with an error if you combine them.

Fourth, the network. An ACCOUNTADMIN can block all non-Snowflake egress from Cloud Agents with the account parameter COCO_CLOUD_AGENTS_NON_SNOWFLAKE_EGRESS_DISABLED, which defaults to FALSE. We set it to TRUE.

Cost is Part 3’s story, so one line here: during the preview, every automation run incurs standard task billing plus CoCo token consumption. And as in Part 1, automation runs set a QUERY_TAG, so their queries can be traced by tag like every other pipeline.

Keeping agent work reproducible

Locking down defaults makes agents safer. It does not make their work reproducible. For that I use one rule: the agent proposes, the pipeline deploys.

An agent may look, check, and draft on its own. Anything that changes an object in Snowflake goes the same way a human change goes. The agent works on a branch, the change goes through a GitLab merge request, CI runs a DCM plan, and the deploy happens only after someone approves it.

DCM Projects are what make the last two steps work. They became generally available in August 2026. You describe the target state of databases, schemas, tables, tasks, and other objects in definition files with DEFINE statements, use Jinja for anything that differs between environments, and Snowflake works out the changes. Definition files can live in a Snowflake Workspace, a remote Git repository, or a local directory, and the docs recommend Git for versioning.

In CI, the plan step is the review artifact. In the Snowflake CLI form from the docs:

snow dcm plan --target PROD_US --save-output
# review the plan in the merge request, then after approval:
snow dcm deploy --target PROD_US

snow dcm plan shows what would be created, altered, or dropped without applying anything, and --save-output writes the result to the local out/ directory so CI can attach it. The documentation is blunt about the order: always run and review your PLAN output before running DEPLOY. It also notes that a successful plan does not guarantee a successful deploy, because DEPLOY computes a fresh changeset against the current account state.

Three more details make this reproducible rather than merely reviewed. Each DCM project object stores the immutable artifacts and definition files of every deployment, and SHOW DEPLOYMENTS IN DCM PROJECT lists them. The docs recommend one DCM project for each target environment, with the same definitions and different template values. And they recommend a separate owner role for production, held only by service users. That last one is the agent rule in different words: the agent never holds the production role.

Snowflake ships reusable GitHub Actions for DCM plan and deploy, but they are in preview and only available for GitHub. We run on GitLab, so those actions do not apply to us. The DCM TEST and PREVIEW commands are also still in preview.

The agent’s own instructions need versioning too. A prompt can live in a file and go in with --prompt-file, and --dry-run shows the task SQL before anything is created. Project skills for the CoCo CLI live in .cortex/skills/ inside the repository, so they travel with the code. Skill and plugin sharing across an account, through Cortex Extension objects, has been in preview since July 2026. What the automation page does not describe is any way to export or version an automation itself, so my recommendation is to treat a prompt file in Git as the source of truth, not the task.

If your repository lives in GitLab, a Git repository clone in Snowflake can sync it with all its branches, tags, and commits, and Workspaces can commit and push back to it.

Seeing what the agent did

The last piece is evidence. For every run I want two answers: did it run, and did it do the right thing. They come from different places.

Task history answers the first. The thread transcript answers the second: every message, tool call, result, and the final response. From the CLI, cortex automation doctor <name> shows recent runs and thread IDs, and cortex conversations transcript <thread_id> prints a run. Two details shaped how we check. A failing pre-run or post-run hook does not fail the run, so a green task can hide a broken hook. And threads and run history are kept for two months, so anything you need longer has to be kept somewhere else.

Options I considered

These are the options the documentation offers for getting an agent’s change into Snowflake, and how I weigh them against what the POC showed.

Let the agent deploy directly. It is the fastest path, and an automation can already run SQL. It lost because a run takes its owner’s default role, nobody approves its tool calls, and a successful task can still be the wrong outcome. A direct deploy leaves no plan for anyone to review.

Let the agent write directly in DEV only. This keeps the agent fast where mistakes are cheap. It lost because the docs recommend one DCM project per environment with the same definitions. A change the agent writes straight into DEV is not in those definitions, so DEV stops matching what reaches PROD.

Use Snowflake’s DCM GitHub Actions. They give plan and deploy steps out of the box. They are in preview and only available for GitHub, and we run on GitLab.

The agent proposes, the pipeline deploys. Branch, GitLab merge request, a DCM plan in CI, deploy after approval. It is slower than a direct write, and that is the point: every change has a plan someone approved.

Impact

This is what the setup makes possible for a team that adopts it. Reviewers see an agent change like any other change: a merge request with a plan attached, not a transcript to reverse engineer. Whoever is on call has one place, the transcript, to check that a green run did the right thing. For platform and security, the defaults we changed in the POC (revoking the PUBLIC grant, narrowing the default role, blocking non-Snowflake egress) close off the case where any user can schedule an unattended agent with a powerful default role and open egress.

It also changes the next decision a team faces: whether agents can move past a POC. With the same review path as human changes, that becomes a question about what the agent may propose, not about trusting it.

For a team starting out, the order matters: read the defaults section before creating the first automation, and design the default role first.

Durable definitions, variable agents

This series started with compute and ends with agents, and the principle stayed the same. In Part 1 I wrote about durable models on variable compute: hold the model of the workload steady and let compute flex underneath it.

Agents are the most variable thing I have put on the platform. The same prompt can produce a different plan tomorrow. So I hold everything around them steady: the role they run as, the network they can reach, the prompt in Git, and above all the path to production. The agent can explore, check, and draft as much as it likes. What reaches production is a reviewed definition and a plan someone approved.

A concrete place to start, before anyone schedules a first automation: check who holds EXECUTE AGENT TASK in your account (by default, PUBLIC does), and check the default role of every user who will own an automation, because that is the role a 3am run uses.

Running Snowflake in the Agent Era

Part 1: Stop Picking T-Shirt Sizes: What Running Adaptive Compute Taught Me

Part 2: From ORGADMIN to Control Plane: Organization Hub, Organization Users, and Premium Views in Practice

Part 3: Budgets, Quotas, and Monitors: The Cost Controls I Map Before Agents Go Wider

Part 4: The Agent Is Now a Pipeline Step (you are here)

The Agent Is Now a Pipeline Step: Keeping CoCo Automations and Cloud Agents Reproducible was originally published in Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.