Until recently, building an agent in Salesforce meant a lot of clicking inside each org. Testing, versioning and moving that agent from a sandbox to production was largely a manual craft.
With Agentforce DX, the agent becomes a code file that lives in your project and is validated, tested and deployed like any other metadata. At the same time, Salesforce has started requiring phishing-resistant MFA, which changes how admins log in to their orgs.
The two topics were the stars of a Vantegrate Thursday Class on June 11, with JuanMa, Esti, Josu and Fran. Here is the full walkthrough, organized so you can apply it on your team.
What Agentforce DX is and why it changes agent development
Agentforce DX is an extension for Visual Studio Code, Cursor or whichever editor you use, plus a set of Salesforce CLI commands. Its promise is simple: developing an agent should feel like developing in Apex or with Flows.
In practice, that means three things. The agent is written in readable text, it can be tested locally against an org, and it is deployed with the same pipeline as the rest of the project.
If you are just starting to explore AI agents, this approach saves you a lot of headaches when you move from a demo to production.
How to install it
The first step is to search for the official Agentforce DX extension in your editor's marketplace. Make sure it is the one published by Salesforce, because there are several with similar names.
The official documentation has a step-by-step guide. If your team works with Salesforce for developers, you probably already have the CLI installed and the process takes only a few minutes.
Create a project with the Agent Project Template
With the extension ready, you create a new project using the project with manifest option. A new template shows up there: the Agent Project Template.
The same list includes other templates, such as the ones for React apps on Experience Cloud.
When you create the project, Salesforce automatically generates the structure you need:
Bots, the agent definition the org sees.
Apex classes and Flows, which are usually the agent's actions.
GenAI Planner Bundle and GenAI Planner Templates.
Prompt templates, which already existed before.
AiAuthoringBundle, the new and most important metadata.
AiAuthoringBundle: the agent definition
The AiAuthoringBundle is the complete definition of the agent, and it arrived together with Agent Script. Before, deploying an agent across environments raised a lot of questions and sometimes forced you to configure it by hand in each org.
Like everything in Salesforce, it comes with an XML file for deployment. The template also includes a sample agent that you can use as a starting point or delete.
The agent as code: what is inside
The most striking part is that the agent can be read like a document. It is a structured text file that anyone with a bit of patience can understand.
At the top you find the system instructions (the classic "you are an agent that…"), the welcome message and the configuration. Then come the variables and the language the agent responds in.
The router, the agent's orchestrator
The central piece is the router. It is in every agent, whether for customer service, voice or employees.
The router decides which path to take based on what the person asks for. In the sample template it can check the weather, events or hotels, redirect to an out-of-scope topic, or ask for clarification when a request is ambiguous.
Topics are now called subagents
What you used to know as topics are now called subagents. Salesforce renamed them at its TDX event, but the concept is the same.
Each subagent has a description, its instructions and its actions. One comes by default: the escalation to a human, which can point to a Flow that routes through Omni-Channel to whoever is available.
Deterministic actions in Apex, Flow or Prompt Template
The weather example shows the idea well. The instruction tells the agent that, if someone asks about the weather, it should use the weather action and not make up an answer.
That action can be an Apex class, a Flow or a Prompt Template. This combines the judgment of the language model with predictable business logic.
Testing the agent: simulation and Live Test
Before testing, you need to authenticate against an org from the editor, with the usual browser login. After that, the new actions appear in the command palette: preview, validate, publish and open the agent in the org.
The preview offers two modes, and it is worth understanding the difference well:
Simulation: the agent runs locally from the project against the org, but every data change is rolled back. It is like running a Flow with rollback.
Live Test: the agent works with real data and can create or modify records.
In the class, Esti tried Live Test with an agent that had not been deployed yet and, as expected, it failed. The practical rule: test local agents in simulation and keep live mode for agents that are already published.
Agent Tracer: see how the agent reasons
With the simulation running, the Agent Tracer shows every step: the input message, the router's decision, the tools it triggered and the reasoning engine. There you can see, for example, that it detected a question about the weather and chose the right subagent.
It is a lot of information, but it is gold for refining. If you need the full detail, the option to open the JSON shows everything raw.
There is also a simulation history. It helps you adjust the agent until it does exactly what you expect.
Validate and publish without surprises
Since the agent is code, a misplaced comma can break it. That is why the validate command is the first step before any deployment.
In the demo, validation passed, but publishing failed: the agent was calling a weather Apex class that did not exist in the org.
The lesson is a valuable one: validation checks syntax, not dependencies. Before publishing, make sure every Apex class, Flow or Prompt Template the agent uses is deployed to the target.
With a real agent, one that used existing Apex and Flows, publishing worked. Salesforce generated a new version of the agent, visible both in the project and in the org.
From the editor to the DevOps pipeline
You can publish with a right click, from the command palette or from the Salesforce CLI. That last option is the one that opens the door to pipelines.
Behind the scenes, the process is always the same: validate the agent and then publish it. That is why you can integrate it with tools like Gearset or Copado, just like the rest of your metadata.
For teams that maintain several orgs, this is a huge change. The agent stops being a fragile configuration and gets versions, reviews and repeatable deployments.
Agent tests
The next step is testing agents in an automated way. The idea is to define cases like "when the user asks this, the agent has to answer that," and store them the way you store Apex or Flow tests.
Today that is handled with terminal commands and with the Testing Center in Setup. In the class, it was left for a deeper dive in another session.
Official Salesforce skills for working with your LLM
One of the most practical moments was the one about skills. A skill is, basically, a large instruction file with a few example resources that explains to your coding assistant how to work with something specific.
Salesforce published an official kit with skills for Agentforce DX. Among them are Developing Agentforce and Testing Agentforce, designed for developing and testing agents.
The kit is not limited to agents. It also includes skills for Data Cloud, OmniStudio, mobile, branding and integrations, which is very useful if you work with MuleSoft.
How to install them
You install them with a terminal command, which shows the list so you can choose with the space bar. Then it asks which assistant you want them for (Claude Code, Cursor, OpenCode or Antigravity, among others) and whether they will apply to all your projects or only the current one.
Skills can be edited and adapted to your team's rules. A classic example for Apex: reminding the assistant not to send emails inside a loop.
The included resources show what well-written Apex should look like, how to use a Flow inside the agent or how to handle an escalation. With that, your assistant stops improvising and starts following the platform's best practices.
Why Agentforce and not another AI?
A very honest question came in from the chat: isn't it more complicated to implement Agentforce than to set up another publicly available AI? The team answered with the same arguments it uses with customers.
Security and data already solved
The first point is the Einstein Trust Layer, which masks the data the agent processes, along with the zero data retention policy. With other tools, that whole security layer and access to CRM data have to be built from scratch.
If this topic concerns you, it is worth looking at how those who implement AI seriously approach platform security and data transparency.
Determinism and business context
The second argument is determinism. Agentforce combines the model's judgment with actions in code and Flows, and that gives it predictability where it matters most.
The third is that you are already standing on Salesforce. Existing objects, Flows, layouts and processes are reused, instead of building a separate backend.
Observability and the Formula 1 car
Fran explained it with an image: what you see in a technical demo is how the Formula 1 car is assembled. Once it is set up, developing looks a lot like writing good prompts.
They also told the story of a team that doubted its choice because an API took many seconds to respond. In fact, the visibility into how long each step takes was something they were getting from the Agentforce tools.
That said, it is not for everyone. If a company does not use Salesforce and has everything built on another CRM, migrating just for the AI probably makes no sense; for those already on the platform, it is worth learning about the Salesforce options and the plans and pricing before deciding.
Phishing-resistant MFA: the change that can lock you out
The second part of the class was the spiciest. Salesforce started requiring phishing-resistant MFA for privileged users, and the authenticator app code is no longer enough.
The official reason is the wave of phishing attacks. Fran added his own suspicion: it also targets the habit of sharing a single admin user among several people.
Who is affected
Privileged users are those who have any of these permissions, in their profile or in a permission set:
View All Data.
Modify All Data.
Customize Application.
Author Apex.
Watch out for a detail that came up live. These are system-level permissions, not the "view all" on a specific object.
The announced timeline
According to what they reviewed in the class, the change arrives first in sandboxes and then in production, in stages. You should check Salesforce's official communication to confirm which stage each org is in.
Since these schedules can move, always check Salesforce's official communication for your org. The important thing is not to find out the day someone cannot log in.
If you don't know where to start, our team helps prepare orgs for changes like this.
What a passkey is
A passkey is a cryptographic key stored on a device or in a password manager. It works with face unlock, fingerprint, Windows Hello or Face ID, and it can't be stolen with a fake email.
Traditional MFA used a code or a push notification from the authenticator. That code could be read out or forwarded, and that was the hole.
Sharing a passkey in a team vault
Many companies in the region don't pay for a license for every person who deploys to production. For that scenario, the team tested a solution that worked: storing the passkey in the Bitwarden team vault.
Each person has their own user in that vault. When signing in to Salesforce, the browser extension offers to use the stored passkey, and because it lives in the vault and not on a physical device, it can be shared.
In the class, they said the team plan cost about 4 dollars per user per month, the cheapest they found. Other options, such as 1Password, turned out to be more expensive.
If you work in regulated industries, such as financial services or healthcare, validate this practice with your security team. The ideal is still one user per person, with their own passkey.
How to prepare starting now
A short plan so you don't get stuck:
List who has privileged permissions in each org, including permission sets.
Set up passkeys for those users first in sandbox and then in production.
Install the Agentforce DX extension and create a test project with the agent template.
Add the official skills to your code assistant and test in simulation before publishing.
If you want to keep learning, at Vantegrate Pulse we publish guides for each Masterclass, and resources has downloadable material. And if you'd rather have us support you with Agentforce, DevOps or the login migration, you can book a demo.
Frequently asked questions
What is Agentforce DX?
It's an extension for Visual Studio Code and other editors, along with Salesforce CLI commands, that lets you develop Agentforce agents as code. With it you can create, test in simulation, validate and publish agents from your project.
What is the difference between simulation mode and Live Test?
In simulation, the agent runs against the org but reverts any data changes. In Live Test it works with real data and requires the agent to be already published.
Can you deploy agents with Gearset or Copado?
Yes, because publishing is also done from the Salesforce CLI. The pipeline validates the agent and then publishes it, just like the rest of the metadata.
Who needs phishing-resistant MFA in Salesforce?
Privileged users: admins and anyone with View All Data, Modify All Data, Customize Application or Author Apex. For them, the authenticator code is no longer enough, and they need a passkey or an equivalent method.
Can a passkey be shared among several people?
Technically yes, by storing it in the team vault of a password manager such as Bitwarden. Still, you should review it with your security team, because the recommended practice is one user per person.
