A workflow that runs for days outlives the change window

Salesforce’s Winter ’27 announcement, published August 31, 2026, says agents now run entire workflows rather than assisting one task at a time. The examples the post gives are qualifying pipeline, resolving service cases, booking appointments, and underwriting risk, and the release goes generally available on October 12, 2026. Read that list as an operations person and one thing stands out. Every item on it takes longer than a single request, and some of them take days.

That duration is the part we think deserves its own planning line. An agent that answers a question lives and dies inside one transaction. An agent that qualifies a lead over a week of emails, or works an underwriting file while a broker sends documents, is still running when your Tuesday deployment goes out. Somebody owns that run, and on most org charts we have seen, nobody has been told it is them.

The agent now has a release cycle of its own

The post also describes Agent Skills and Plugins, with what Salesforce says is over 100 prebuilt skills at launch. Each skill an agent uses is a dependency, and dependencies get updated. If a prebuilt skill for appointment booking changes behaviour in a later patch, every agent that calls it changes with it, whether or not the team that owns that agent asked for the change.

Admins already manage this for flows and managed packages. The difference with agents is that the definition, the skills, the prompts, and the data model can each move on a different cadence, and the business owner who signed off on the agent’s outcomes usually only reviewed the first version. We’d want a named owner for the agent definition as a whole, someone whose job includes reading what changed in a skill before the next run picks it up. Building the agent was the easy half. Keeping it running through a year of patches is the half that needs a name on the org chart.

Who owns the runs in flight when something changes

Take a Service Cloud org where an agent resolves cases across Slack, voice, and an older ticketing system, which is exactly the cross-channel reach the post describes. A release manager pushes a change to the escalation flow at 6pm. Forty cases are mid-resolution. Whether those forty runs finish on the old flow, pick up the new one halfway, or stall and wait for a person is the question the announcement leaves open, and it is the one we’d put to the Salesforce account team before October 12.

Our own view is that in-flight runs need an inventory before they need a policy. Someone should be able to list every run older than an hour, what it is waiting on, and which version of the agent started it. We wrote about the same gap for ordinary automation in where automation ownership breaks down, and agents make it worse, because the run can be waiting on a customer rather than a system.

Governed data has an owner, and the agent definition needs one too

Salesforce leans hard on the phrase governed CRM data, and our colleagues took that apart in why governed data matters for autonomous work. Data governance in most orgs is real. There is a data owner for Account, a steward for the picklists, and a review when a field changes. The agent that reads that data rarely gets the same treatment, and a long-running agent reads it many times over one run, so a field change on day two lands inside work that started on day one.

The practical fix is to put the agent on the same change board as the objects it touches. When the steward proposes retiring a case reason value, the agent owner is in the room and can say which running workflows still branch on it. Our governance hub carries the wider argument. The short form is that anything that acts on data needs a name next to it, the same as the data does.

Retirement is the step nobody schedules

Agents also get switched off. A pilot ends, a skill is replaced, a regulator asks for a change, or the team decides the underwriting agent should hand back to people for a quarter. With single-turn agents, off means off. With workflow agents, off means forty conversations that a customer thinks are still happening. We argued in June that agents need a pause button, and Winter ’27 turns that from a nice-to-have into a drain procedure: stop new runs, let existing ones finish or hand over, and record where each one landed.

The sibling question is what a finished run looks like when the work crossed channels, and how cross-channel work changes a completed case covers that. For lifecycle purposes the point is simpler. If you cannot say what completing a run means, you cannot say what draining one means either, and the retirement step stays unscheduled.

What to add to the calendar before October 12

Our readiness calendar piece laid out how to turn the announcement into dates. We would add three entries for anyone planning to run workflow agents. Before October 12, name the owner of each agent definition and write it next to the agent in whatever register you keep for integrations. In the first week after general availability, run one deliberate mid-run change in a sandbox and watch what happens to the runs already going. Before the first production agent starts a workflow longer than a business day, rehearse switching it off.

None of this is in the post, and we would be surprised if it were. Release announcements describe what the agent will do. The lifecycle is yours. The next time someone in a planning meeting says the agent runs the whole workflow now, ask who is on call for it on day three.