Bring your own AI Salesforce tooling: the one rule that decides

One rule sorts every bring your own AI Salesforce decision: who chooses the model that drafts the change. If the team chooses, the model, the key and the bill stay with the team, and the tool's job shrinks to review and deploy. If the vendor chooses, the model question moves to the vendor. For a small admin team that already pays for an AI assistant, the first answer usually holds up better; for a team with no AI policy at all, a hosted agent may be the easier start. Vendor pages below were read on 1 Oct 2026.

What the bring your own AI Salesforce rule should decide

The rule is a routing rule, and it should decide one thing: where a model change lands. When a better model ships, or the security team narrows the approved list, somebody has to switch. Under a bring your own AI Salesforce setup, that switch is a settings change on the team's side. Under a hosted agent, the switch is most likely the vendor's to make, on the vendor's timing. Every other property of the tool, from review flow to who carries the AI bill, follows from which side of that line it sits on.

Where each vendor puts the choice today

According to Gearset's public roadmap, read 1 Oct 2026, "Gearset Agent Bring-your-own-Key" is listed under Q4 2026 with the status Researching. That is not shipped, which suggests the choice sits with Gearset today; the Cam page, read the same day, shows no model or key policy, and the same roadmap lists an in-app AI credit monitoring dashboard in progress. Copado's Agentia page, read the same day, says "Agentia operates within Copado's secure boundaries" and shows no bring-your-own-model language, which reads as a vendor-hosted agent.

Salto and Hutte sit on the other side of the line. According to the vendor's page, read 1 Oct 2026, Salto lets teams "Connect Claude Code, OpenAI Codex, and other agents to your Salto workspace". According to Hutte's headless MCP page, read 1 Oct 2026, a team can "Connect Claude, Cursor or any MCP client". According to its GitHub README, read 1 Oct 2026, the Salesforce DX MCP Server is open source and runs locally; the server itself is free (Apache 2.0).

FlowSprite AI is a bring your own AI Salesforce tool, on the team-chooses side. Any AI the team brings drafts a Salesforce metadata change, and FlowSprite AI lands it as a pull request in the team's private GitHub repo. Changes are tested in a sandbox first, and a human approves before anything deploys. Production is never auto-touched, and every tool call the team's AI executes is audited. The MCP surface is role-scoped and tier-gated. The honest limit: FlowSprite AI does not pick or supply the model, so a team with no AI assistant has to choose one, and pay for it, before the first change can be drafted.

A constructed four-admin case: where a model switch lands

The numbers here are constructed for illustration. Four admins share one repo, and each ships about 10 changes a month: 4 x 10 = 40 changes. All four draft with the same approved assistant. In week one, the security team narrows the approved list and retires that model.

Under a bring your own AI Salesforce setup, each admin changes one setting in their own assistant. Three do it on Monday. The fourth is on leave and switches a week later. That admin's month is 10 changes, roughly 10 / 4 = 2.5 a week, so about 2 or 3 of the 40 changes, near 6 percent, get drafted by the retired model. Unless the team records which model drafted each pull request, a reviewer has no easy way to spot them.

Under a hosted agent, none of the four touches a setting. The switch, if the vendor offers one, happens once for everybody, so the 6 percent straggler gap does not open. The trade: until the vendor moves, all 40 changes come from whatever model the vendor runs, and the team cannot move first.

Where the rule handles a team badly

Add concurrency and the rule starts to cost something. A bring your own AI Salesforce setup assumes someone owns the AI decision. Change the case: if the four admins drafted on three different assistants, the team would have three models drafting changes into one repo, and nobody would have written down which one is approved. The case the rule handles worst is the admin with no AI seat at all: under BYO they cannot draft until procurement acts, while a hosted agent may cover them if their vendor seat includes the agent.

That is the edge where a hosted agent is easier, and it is a real one. A team without an AI policy, a key or a budget line has nothing to bring, and a hosted agent removes that step. According to Copado's Agentia page, read 1 Oct 2026, Agentia Advanced has a 14-day free trial with no credit card. Choosing BYO means accepting a new failure mode: a model swap on the team's side can change draft quality between Monday and Friday with no vendor release note to explain it.

The observable that says the rule is working

The adjustment worth making, once a team chooses BYO, is one line in the pull request template: which model drafted this change. It is one field per change and adds no new tool. In the case above, it makes the 2 or 3 stray changes visible. For a team that needs a hosted agent, skip it.

The observable is the share of merged changes over 30 days whose pull request names an approved model. Measured at merge time in the repo, the target is 100 percent. Anything below means a model is drafting changes outside the rule, and the bring your own AI Salesforce choice has quietly turned into nobody's choice. Check it monthly, and correct this note in place, dated, if a roadmap line moves.