Winter ’27 is landing in most production orgs over the weekends of 3 and 10 October 2026, and it quietly changes what an Agentforce agent is. The new Agentforce Builder is built on Agent Script, so an agent is no longer a pile of prompts and toggles in Setup — it’s a script with explicit rules, variables, and topics that you can read, diff, and deploy. That makes Agentforce Agent Script the most important change in the release for anyone running agents in production. The question isn’t whether your team can write it. It’s whether you’ll treat it like code or like configuration.
What actually changed in Winter ’27
Agent Script mixes two kinds of logic in one definition: natural-language instructions the model reasons over, and deterministic rules it has to follow every time — a variable that must be set before a topic runs, a calculation that can’t be left to the model, a hand-off that only fires under a specific condition. In the new builder you can edit the same agent as a document, as a low-code canvas, or as the raw script, then simulate it in one click and inspect the reasoning trace.
The bigger shift is underneath. Because the agent now has a scripted, portable definition, it can be retrieved as metadata, committed to Git, and promoted between orgs with the same tooling you already use for Apex and Flows. Winter ’27 also adds side-by-side version comparison inside the builder. Taken together, agents have stopped being click-only artefacts and started behaving like source code.
Why “it’s just config” is the expensive mistake
Here’s the failure we’d expect to see first. A service agent works well in a sandbox. Someone tweaks a topic instruction directly in production to fix a customer complaint. Two weeks later a second admin rebuilds the sandbox version from memory and redeploys it, silently undoing the fix — and nobody can say which wording was live on which day when an escalation lands.
That’s not an AI problem. It’s the same drift problem every Salesforce team learned to solve for Apex a decade ago, and the answer is the same: one source of truth, a reviewed change, a known promotion path. Agent Script finally makes that possible for agents. Teams that keep editing agents straight in production will lose the audit trail they’ll need the first time a regulator, an auditor, or an angry customer asks why the agent said what it said.
Four habits for running Agent Script like code
Put every agent in version control. Retrieve the agent definition into the same repository as the rest of your metadata. A pull request that changes a guardrail should look exactly like a pull request that changes a validation rule: a diff, a reviewer, a reason.
Review the rules, not just the prose. The deterministic parts of a script — conditions, variables, which actions a topic may call — are where an agent gains or loses the ability to change records or message customers. Those lines deserve the same scrutiny as an Apex trigger. It’s the reason we have a certified engineer sign off on every AI output before it ships, and agent definitions are no exception.
Gate promotion on tests. One-click simulation is useful while you’re building, but a regression suite is what protects you afterwards. Keep a set of real utterances with the expected topic and action, and run them on every change before the agent moves from sandbox to production — the approach we set out in agent validation: proving Agentforce is ready.
Deploy agents through the pipeline, not around it. Agents should ride the same governed path as every other change: developer sandbox, integration, UAT, production, with a gate at each step. If you already run governance-first CI across multiple orgs, agents slot straight in. If you don’t, Winter ’27 is a good reason to start. And the sandboxes those tests run in need realistic, related data — the job iSyncSF does in sandbox seeding without broken lookups — or the tests pass for the wrong reasons.
Inventory before you refactor
Not every existing agent moves to the new model on day one. Some partner write-ups note that agents created before Winter ’27 may continue to be managed the older way for a while, so before you plan any rework, list every agent in every org, where it’s managed, who owns it, and whether its current definition exists anywhere outside production. That inventory is usually a short, uncomfortable document — and the most useful one you’ll write this quarter.
It’s also worth checking who can build. With Agentforce now switched on by default in eligible editions, the Manage AI Agents permission is the real gate. A tidy Git workflow doesn’t help if a dozen people can still edit agents directly in production.
How we help
We set up Agent Script delivery the way we set up any serious Salesforce change: agents in source control, a review standard for guardrails and actions, a regression suite, and a promotion path through properly seeded sandboxes. We build AI-native — our own agents draft and test the scripts, and we absorb that token and compute cost — but every agent definition is reviewed by a certified Salesforce engineer before it goes anywhere near a customer. You get agent speed with the audit trail an enterprise needs.
Key takeaways
- Winter ’27 makes Agent Script the basis of the new Agentforce Builder — agents now have a readable, portable definition.
- Treat that definition as code: version control, peer review of rules and actions, and tests that gate every promotion.
- Inventory existing agents and tighten who holds Manage AI Agents before you refactor anything.