Eight questions to ask before switching on Agentforce Vibes for a team

Agentforce Vibes is Salesforce’s AI coding agent. Its agentic chat takes a plain-language request and “works directly in your workspace,” and its inline suggestions cover Apex, JavaScript, HTML and CSS, including Lightning Web Component files (VS Code Marketplace listing). The listing showed 939,350 installs when we read it.

A lot of teams are about to switch it on, or already have. We work with Salesforce teams on the rules around AI-written code, and these are the eight questions we ask first. For each one we quote what Salesforce, or another named source, says on a page we read on October 15, 2026, and link to that page. Pages change. Check the link before you rely on a line.

1. Did anyone decide to switch it on?

Salesforce’s settings page says it plainly: “Agentforce Vibes is enabled by default in supported editions.” An admin can turn it off in Setup, and “Einstein is the org-level toggle required for every AI feature” (Salesforce: Settings and Permissions). The same page says developers “must enable telemetry to use the Agentforce Vibes extension,” and can turn telemetry off afterwards “if your organization’s policy permits.”

So the default is on. If nobody made a decision, the decision was made for you.

Ask: who owns the toggle? Has anyone recorded who accepted the terms? Does your data policy cover the telemetry? A good answer: one named owner, a dated note of who accepted the terms, and a telemetry decision written down before the first install.

2. Is your org allowed to run it?

The settings page lists where it runs: “Developer, Enterprise, Partner Developer, Performance, and Unlimited Editions.” It is “Inoperable in: Group, Professional, and Essentials Editions,” and “Not available in: EU Operating Zone” (Salesforce: Settings and Permissions). The page adds that it “isn’t available in EU Operating Zone and Government Cloud due to data residency requirements.” The same guide’s table of contents also lists a page called “Agentforce Vibes in Government Cloud.” We did not read that page, so if you are in Government Cloud, confirm your case with Salesforce.

Ask: which of our orgs qualify? A good answer: a list of every org, with yes or no against each, and the reason.

3. What leaves the org, and what does masking cost you?

Prompts pass through the Einstein Trust Layer, which “can identify and mask personally identifiable information (PII) and payment card industry (PCI) data in prompts before sending them to the LLM” (Salesforce: Trust and Verification). That has a cost. The same page says: “When Einstein Trust Layer data masking is active, the context window is capped at 115K tokens regardless of the model’s native limit.” Salesforce’s advice is to plan your context accordingly.

A post dated August 3, 2026, on Jeff Douglas’s blog, written in the first person about the Vibes release, says “Salesforce’s contracts with third-party LLM partners prohibit them from retaining prompts or completions, and from training on your data” (jeffdouglas.com, “What’s new in Agentforce Vibes”). That is a statement about contracts. If it matters to you, ask for it in your own contract.

Ask: is masking on? Does the security team know about the context cap? Has anyone asked for the retention terms in writing?

4. How will you pay, and who reads the meter?

Salesforce’s pricing page, which says it “is provided for information purposes only and is subject to change,” lists Flex Credits at $500 per 100,000 credits and a flat fee of $125 per user per month, in US dollars (Salesforce: Agentforce Vibes Pricing). The page also says you can explore it “using free Flex Credits from Salesforce Foundations or by accessing it through a Developer Edition org.”

The billing guide explains the meter. “Usage is counted in 2,000-token increments and rounded up,” so a prompt with 6,500 input and output tokens is metered as four units. On the unmetered licence, the “Limit for premium models is 2,500 requests or 36 million tokens, whichever is reached first,” and limits “reset every 30 days after first use.” “Switching between models does not reset or bypass usage limits.” Consumption shows in Digital Wallet (Salesforce: Billing and Licensing).

Ask: which route are we on? Who checks Digital Wallet, and how often? What happens on the day a developer hits the cap in the middle of a sprint? A good answer: a named person, a weekly number, and a written fallback.

5. What can the agent do without asking?

“Agentforce Vibes acts directly in your workspace, creating files, modifying code, and running commands” (Salesforce: Trust and Verification). The Marketplace listing names “three session modes — Ask every time, Run safe defaults, and Bypass” (VS Code Marketplace listing). For teams starting out, Salesforce’s trust page recommends setting the default session mode to “Ask every time” and keeping “the command allowlist minimal.”

The August blog post says “Fresh installs land on Run safe defaults” (jeffdouglas.com). That is not the mode Salesforce’s trust page recommends for a team starting out. Neither is wrong. They describe different things: one is the default, the other is advice. Someone on your team has to pick on purpose.

Ask: which mode does each developer run, and who widens the allowlist? A good answer: “Ask every time” for the first month, and an allowlist that lives in the repo, where a change to it is reviewed like code.

6. Where do the team’s rules live, and who owns them?

Rules are always-on instructions to the agent. Project rules are “stored in .vibes/rules/,” and Salesforce says to “commit them to version control so the whole team shares the same standards.” Salesforce’s built-in rules “can’t be edited or deleted. You can only toggle them on or off.” “Project rules override global rules when both define the same guidance,” and “Rules consume context in every interaction” (Salesforce: Rules).

Ask: is .vibes/ in the repo? Who reviews a change to a rule? Has anyone switched off a built-in rule, and why? A good answer: rules in git, changed by pull request, and the built-in toggles left on unless someone wrote down the reason.

7. Will org-wide policies be enforced, or only suggested?

Salesforce is adding org-level governance. On the Vibes side, the page is marked Developer Preview and says “Don’t implement functionality in production with these commands or tools.” Admins set policies, “which end users can’t modify or turn off” (Salesforce: Org Policies (Developer Preview)).

Read the Considerations section on that page before you rely on it. “The system applies policies as system prompt instructions. Agentforce Vibes doesn’t verify or enforce that the LLM followed the policies. Policy application is best-effort at the prompt level.” On a fetch failure, “No governance policies are applied for that session. Agentforce Vibes logs the failure and continues.” And “This release doesn’t govern Model Context Protocol (MCP) servers, skills, and tools.”

Salesforce Help describes the governance feature in the release tool, now being renamed Lifecycle Center, differently. That page says governance “evaluates coding agent actions in real time,” and “If a violation is detected, Governance prevents the action” (Salesforce Help: How Lifecycle Center Governance Works). We read both pages on the same day. We do not know yet how the two relate in a given org, or which one describes the version you have. Test it in a sandbox before you count on it.

Ask: if a policy is an instruction to the model, what in our process is the actual check? A good answer: something outside the agent, run on the finished code, that fails the change when the rule is broken.

8. Who reviews the code, is it the same AI that wrote it, and who presses go?

Salesforce says it directly: “Human review isn’t optional” (Salesforce: Understand Agentic Development). The trust page says the output “is nondeterministic. The same prompt can produce different results across sessions. Always verify” (Salesforce: Trust and Verification). The settings page tells admins: “All AI-generated code should be reviewed before deployment to production” (Salesforce: Settings and Permissions). And the Marketplace listing: “You assume responsibility for how the outcomes of Agentforce Vibes are applied to your organization” (VS Code Marketplace listing).

Now look at what the agent does in the agentic workflow. It “generates the Apex class, handler, and test class together as a coordinated unit,” and it “runs tests, reads failures, and iterates toward a fix within the same task.” “You approve once and it executes all changes” (Salesforce: Understand Agentic Development). The builder writes the test and then grades itself against it.

Gearset’s write-up of Vibes makes the same point from the tooling side. It says the Trust Layer “has no mechanism to prevent this, such as enforcing code quality, testing requirements, or peer review processes that keep production stable” (Gearset blog), and it contrasts its own scanner with “asking an AI to check its own output.” Gearset lists Code reviews at $160 per individual contributor, per month on its pricing page (Gearset: Pricing). We mention the price because a scanner is one of the answers below, not because we sell it. We have no relationship with Gearset.

The tool that builds a change never approves it. Two reviews that did not write it, on the exact code, and a named person who says go.

Ask: who, or what, reviews each change, and is it independent of the thing that built it? Is the review tied to the exact code that ships, or to a version from Tuesday? Who presses go to production, and where is that written down? A good answer: two reviews by something other than the builder, both tied to a fingerprint of the exact files, a scanner where you have one, and one named person who says go.

Running the eight in one meeting

You do not need a project for this. Book one meeting with the person who owns the org, the person who owns releases, and one developer who already uses the tool. Put the eight questions on one page. Write an answer and a name against each, or write “not decided.” Questions with no answer are your list for next sprint.

The first five go quickly, because Salesforce has documented them and the answer is a setting or a contract line. The last three take longer, because they are about your own process, and no vendor page can answer them for you.

This is the rule we use, and the one we set up with teams: nothing reaches production unless two independent reviews pass on the exact code and a person says go. The builder never reviews its own build. A Salesforce team at an enterprise software company went from a 31-slide concept deck to production code in 38 days that way. The full record, including where the reviews missed, is in 38 days, six reviews, one script that says no.