I've been building Agentforce implementations since the platform launched, and Spring '26 is the first release where the developer experience feels like it was designed by people who actually build agents for a living.
Salesforce shipped a new Builder, a YAML-based scripting language called Agent Script, a proper DX toolkit for VS Code, and rebranded Sales Cloud to "Agentforce Sales" (more on whether that matters in a minute). There's a lot here. Some of it is useful today. Some of it is beta with sharp edges. Let me break down what I think actually matters.
Builder: Finally a Real Dev Experience
The original agent setup in Salesforce was... fine. Pick topics, assign actions, write natural language instructions, and hope the LLM interprets them the way you intended. For a simple service deflection agent, it worked. For anything with branching logic or business rules, you spent more time fighting the tool than building the agent.
Agentforce Builder replaces that with something that feels much closer to an IDE. Two modes:
Canvas View is a visual editor for conversation flows. Think of it like building a complex Screen Flow, but for agent behavior. You're laying out topics, branching conditions, and state transitions. If you need the agent to take path A when a customer is in segment X but path B for segment Y, you can define that visually instead of trying to explain it in a paragraph of natural language instructions and hoping the LLM gets it right.
Script View is a text editor with syntax highlighting, autocompletion, and validation. You're writing Agent Script directly. This is what gets me excited, because the number one question I hear from architects evaluating Agentforce is some version of "how do I guarantee it doesn't do something unpredictable during a business-critical process?" Script View gives a real answer.
The shift is that you can now make the predictable parts deterministic and leave the conversational parts flexible. Business rule? Use a script expression. Greeting and clarification? Natural language. That hybrid is exactly what production implementations need.
Agent Script: YAML for Agent Behavior
If you've written GitHub Actions workflows or CloudFormation templates, Agent Script will feel familiar. It's a declarative YAML language for defining agent behavior: the LLM configuration, API connections, variables, topics, and the logic that ties them together.
What makes it useful in practice:
Explicit transitions. You define when and why the agent moves between topics using conditions. Not "the LLM decided this was a good time." Actual if/else logic.
State management. Variables persist across turns. The agent tracks context through a multi-step interaction using defined variables instead of relying on the LLM to "remember" what happened three messages ago. If you've ever watched an Agentforce agent lose context mid-conversation, you know why this matters.
Deterministic business rules. The LLM doesn't decide whether a customer qualifies for something. Your conditional logic does. For financial services, healthcare, or anything compliance-adjacent, this is table stakes.
Script doesn't replace natural language instructions for everything. For open-ended conversation, summarization, or handling edge cases gracefully, natural language is still the right tool. Script just means you're no longer forced to use it for parts of the agent that need to be predictable.
Agentforce DX: Agents in Your CI/CD Pipeline
This is the one that'll quietly change how enterprise teams work with Agentforce. Agentforce DX lets you pull agent script files into your SFDX project and work with them in VS Code using the Salesforce CLI.
That means your agent definitions can live in Git. They can go through code review. They can flow through your Copado or GitHub Actions pipeline alongside your Apex and LWC. You can deploy agents the same way you deploy everything else.
Before this, agent configuration lived in Setup and was a pain to track across environments. No version history, no diff view, no systematic promotion from sandbox to production. DX fixes that.
Another addition worth noting: you can now expose Apex REST and @AuraEnabled methods as autonomous actions by annotating them and deploying a generated OpenAPI spec to the API Catalog. Your existing Apex codebase becomes an action library without rebuilding anything as invocable actions. That's a nice bridge for orgs with a lot of existing Apex.
The Honest Status Check
Builder and Agent Script are both beta in Spring '26. They work, but expect some friction.
Solid and production-ready right now: the core Agentforce platform (topics, actions, instructions), invocable Apex actions (still the most reliable extension pattern), standard actions (query records, run flows, call APIs), and the basic agent testing tools in Setup.
Beta but worth exploring: Builder is a significantly better authoring experience even with rough edges. Agent Script is powerful for complex use cases but the syntax and tooling will evolve. DX is functional but the documentation hasn't caught up yet.
I'd hold off on: Agentforce in Setup (the admin experience redesign) is in beta and very different from today's UI. Don't retrain your team on it yet. And the "Agentforce Sales" rebranding is mostly cosmetic right now. If you're mid-implementation, it might cause some confusion during rollout but it doesn't change how anything works.
How I'm Advising Clients Right Now
For new projects: design with Builder and Script in mind even if you build the first version on the current GA tools. Think about which parts of your agent need deterministic behavior (validation, routing, business rules) vs. conversational flexibility (greeting, clarification, summarization). Structure your topics and actions so they'll map cleanly to script when it goes GA.
For existing implementations: don't rewrite anything. But start getting agent metadata into version control via DX now. That investment pays off fast once Builder goes GA and you're iterating more frequently.
For enterprise orgs still evaluating Agentforce: Spring '26 is the inflection point. Builder addresses the predictability gap. DX addresses the deployability gap. Those were the two biggest blockers for production use, and both now have real answers. Time to plan your pilot.
Grab 30 minutes if you want to talk through what Spring '26 means for your specific Agentforce roadmap.