Snowflake gave CoCo and CoWork a background shift. Keep an action ledger

THE SIGNAL IN ONE SENTENCE

The agent keeps working after you close the laptop. That is useful right up to the moment nobody can reconstruct what it did. Snowflake used its Expedition 2026 event to announce a larger background role for CoCo, its agent for data work, and CoWork, its agent for business work. Snowflake says upcoming Bots will run continuously, plan and complete tasks, use company tools and check in for critical decisions or final approval. The new Bots are not broadly available today. Snowflake labels them as coming to private preview soon. The surrounding pieces have a mixed release status. Skills and plugin sharing and the Cortex Agent SDK are generally available. Profiles, several connected surfaces and parts of model routing are in public preview. Some other model features remain in private preview. Keep those labels attached. A launch slide is not an availability matrix. The underlying direction is still important. CoCo Automations can run recurring jobs on a schedule or after an event or webhook. Snowflake says every run leaves an audit trail and task history, and that users can suspend or rerun work. Its Async Agent API can continue multistep work in the background and resume after an interruption. CoCo can operate through Snowsight, desktop, command line, mobile and Slack. CoWork can move from governed data to dashboards, documents and recurring business workflows. Snowflake says these agents inherit the user's access rights, role context and permissions. It also says shared skills, profiles, project-scoped memory and connectors can carry company context into a new session. In the CoCo workflow, an automation runs as the person who created it, so that person's grants and policies apply. That is a sensible boundary. It is not a complete record. Background work changes the shape of human oversight. In a chat session, a person can watch the model propose an action and interrupt it. In an overnight automation, the person usually reviews evidence after a chain of tool calls has already happened. A final check mark cannot explain which identity the agent resolved, which permissions were active, which memory it loaded, which version of a shared skill it used, what it sent to each tool or which side effects survived a retry. A background agent without an action ledger is just a very confident night shift with no timecard. Give every run an idempotent job identifier. Store the trigger, schedule, requesting owner and execution identity. Snapshot the exact role, grants and data scope at start. Record the model, instructions, skill and plugin versions, connector configuration and memory version that shaped the plan. Then record every tool call. Keep the destination, parameters, input and output fingerprints, timestamps, error state and retry count. Record files created, queries issued, messages sent, records changed and external systems touched. If the job pauses and resumes, preserve the resume point and show which earlier effects are already committed. This is where idempotency stops being an architecture word and becomes a way to avoid emailing the same customer twice. Approval needs its own evidence. Store what the agent proposed, what evidence the reviewer saw, who approved it, when they approved it and exactly which actions that approval covered. If the plan changes after approval, ask again. Place the gate before an irreversible or external side effect, not at the end of a long run. A person approving a polished report after the agent has already changed source records is reviewing the receipt, not controlling the purchase. Memory deserves similar treatment. Snowflake says users can view, update and delete memories, and its CoCo post says project-scoped memory is intended to keep context from leaking between projects. Useful controls, yes. But a memory can be correctly scoped and still be stale. Version every memory used by a job. Record when it was created, who changed it, which project owns it and what evidence should invalidate it. When an employee changes roles, a customer revokes consent or a policy changes, old context should not quietly keep steering new work. Shared skills and plugins create another moving part. Snowflake says administrators can certify shared versions. The ledger should preserve that certified version for each run. Otherwise a workflow that succeeded Monday can fail Wednesday after an invisible instruction or connector change, while both runs carry the same friendly name. Cross-tool jobs also need one trace identifier. The same identifier should follow work from a scheduled trigger into Snowflake, Slack, a spreadsheet, a generated document and mobile approval. Without it, every system shows a fragment and nobody can prove the fragments belong to one job. The practical safeguards are wonderfully unglamorous. Use least privilege and short-lived credentials. Start with a dry run. Put low-volume canaries ahead of broad schedules. Set cost, time, concurrency and side-effect budgets. Add a kill switch that stops queued and running jobs. Keep a rollback plan beside each reversible action and record whether rollback actually worked. These controls fit the jobs Snowflake describes: checking failed data tasks, preparing meeting briefings, reviewing pipeline health, building recurring analyses and turning findings into dashboards or documents. They also help a reviewer distinguish a job that finished cleanly from one that merely stopped talking. Snowflake reports that CoWork was used by more than 5,800 accounts and CoCo by more than 9,100 accounts. The company says those figures are based on weekly usage averaged across the final four weeks of the quarter that ended July 31, 2026. They are company-reported adoption measures, not evidence of productivity, safety or low failure rates. The same caution applies to the feature claims. Snowflake's announcement and engineering posts describe intended controls and workflows. They do not provide an independent audit of permission enforcement, error rates, approval quality, rollback success or the consequences of stale memory. That is not a reason to ignore background agents. It is a reason to make their evidence as durable as their output. Let the agent work in the background. Keep its evidence in the foreground.