One setting decides where AI changes enter your Salesforce deployment pipeline

Where an AI-drafted change lands first is a routing rule. If the first durable write goes to a vendor workspace, it lands in that vendor's format (NaCl for Salto) before a PR exists. If it goes to an org, it exists only in that org until someone commits it. If it goes to a pull request in a GitHub repo the customer owns, the first record is already a reviewable diff. For a team that wants its Salesforce deployment pipeline to begin at a reviewable diff it owns, the pull request is the stronger destination. This note examines three routes, the workspace, the org and the PR, through two vendors and Salesforce's open-source DX MCP server, from the outside, from their public pages read on 1 Oct 2026, not from running them.

What the destination rule should decide

The mechanism is one setting: the target of the agent's first write. It decides where a reviewer finds the change.

According to Salto's page, read 1 Oct 2026, "Agents don't touch the business apps themselves, but only the Salto workspace." The Salto technology page, read the same day, describes that workspace as "a folder containing Salto configuration files, including the State and NaCl files", usually connected to a Git repository, with NaCl an HCL-based language. The first write lands in Salto's format, and pull requests follow.

According to Hutte's page, read 1 Oct 2026, its hosted MCP lets an assistant "develop in a real Salesforce org", after which the human can "inspect exactly what changed as a clear delta of XML metadata, test the result in Hutte, then commit and open a pull request." The first write lands in a sandbox or scratch org, and the PR comes after a commit step.

The Salesforce DX MCP server sits on the org route too: per its GitHub README, read 1 Oct 2026, it runs locally against orgs using Salesforce CLI credentials: an org route the team wires itself. The third route is the pull request: the change is a pull request in the customer's repo that a human approves; FlowSprite sits there, below, and this note does not rank its internal steps. All three feed a Salesforce deployment pipeline; they differ in where a change sits before review.

The ordinary case resolves cleanly on every route

One admin, one Flow change. On the workspace route the change appears as edited NaCl, and per Salto's Salesforce page, read 1 Oct 2026, pull requests are created automatically. On the org route the admin reads the XML delta, commits, and the PR opens. On the PR route the change is the PR. All three end at a diff a human approves, and at one change a day the Salesforce deployment pipeline never shows the difference.

Add volume: where a Salesforce deployment pipeline backs up

The rule earns its keep under concurrency. A constructed case, illustrative numbers only: three admins running AI sessions, 30 drafted changes a week across the team.

On any workflow where the first write is an org, a change has no copy in Git until someone commits it. Assume 10% of drafts sit in that state when the session ends, because someone was paged. That is 30 × 0.10 = 3 changes a week, and 3 × 52 = 156 changes a year that spend some time existing only in an org (illustrative). The mitigation is a commit rule: nothing leaves a session uncommitted.

On the PR route the record a team keeps is the PR, with its diff, in the customer's repo, and queue depth reads as open PRs.

The change that matches no route

Next, the change that matches no rule: an edit made in the org by hand, outside any agent.

This is where Salto wins on its own terms. According to its Salesforce page, read 1 Oct 2026, a "catch-all change log tracks all changes no matter how they were done." Salto's home page, read 1 Oct 2026, lists NetSuite, Zendesk, Jira and Okta alongside Salesforce. Hutte wins elsewhere: scratch org pooling is its core pitch, per its environments page read 1 Oct 2026, and its MCP documentation, read 1 Oct 2026, lists claiming a pooled scratch org as a tool. The Salesforce DX MCP server is open source, per the same README, for teams that want to wire the agent themselves.

A PR-first Salesforce deployment pipeline does not catch a hand edit at write time; it catches it later, as drift between org and repo.

The adjustment and what it costs

The adjustment: the customer's repo keeps the change; every other state replays it. FlowSprite AI keeps the record in the customer's repo: whichever AI the team brings drafts a Salesforce metadata change that lands as a GitHub pull request in the customer's private repo. Changes are tested in a sandbox first, and a human approves before deploy. Production is never auto-touched. The Professional tier includes drift detection and deploy preview with dependency analysis; Enterprise adds approval workflows with separation of duties and audit log export. Every tool call the customer's AI executes is audited. Honest limits: a team that manages NetSuite or Zendesk beside Salesforce fits Salto's breadth better, and a team whose bottleneck is spinning up scratch orgs fits Hutte's pooling better.

The cost is latency at the front of the Salesforce deployment pipeline: a sandbox test and a human approval both stand between a draft and a deploy. The new failure mode is a stale PR queue, which needs an owner and a close rule.

The observable that says it works

Count changes deployed in the last 30 days that have no matching PR in the repo. On a working PR-first Salesforce deployment pipeline that number is zero, and every non-zero entry is a deploy that bypassed the PR route, such as a change set or a CLI deploy run by hand. A hand edit in Setup is not a deploy, so this count cannot see it; read it beside the drift report, weekly. A climbing count means a second route nobody wrote down; close it first.