In a Salesforce deploy, the slow part is rarely the deploy command. It's working out what goes in the package, which tests to run and which org to hit, and then, when it fails, figuring out what the error means for this change. Both are language problems, and language is what models are good at.
Deploying is not a language problem. So when we designed an agent that takes a change from a plain request to a verified deploy, the first question wasn't "what can the model do" but "what must it never do". These are the four rules it runs under.
1. The model never touches an org
The model gets no credentials, no shell and no sf CLI. It gets a fixed menu of actions: validate, deploy, run tests, query, retrieve. It picks one and fills in the parameters; code checks them and runs the action with the sf CLI and git. If an action isn't on the menu, it doesn't exist.
That one rule removes a whole category of "the agent ran something creative" stories.
2. Humans approve at the right moments, not every moment
Approving every step is how people learn to click Approve without reading. So there are three gates:
- The plan. Components, target org, tests and risk on one card. Approve, edit or reject.
- A changed plan. If the fix after a failure changes the components or the scope, it comes back to you. A same-plan retry doesn't.
- Production. A check-only validation runs first, then a human click deploys. Always. Destructive changes too.
Sandbox steps run on their own while everything stays green.
3. "Done" means checked, never the model's word
After a deploy, code queries the org: is the Flow active, did the tests pass, does the profile have field access, does the validation rule actually block the case it was written for? The result is an evidence table. The model writes the summary from that table, not the other way round.
4. Every run is logged and capped
Plans, actions, approvals and outputs go into one log per run, with a cost cap the run can't go past and a limit of three retries on failures. When it stops, it says why.
What the model is actually for
Two jobs. Turning "add a Discount Approved checkbox to Quote, with a validation rule that blocks a discount over 20% unless it's checked, UAT only" into a plan a reviewer can read in 20 seconds. And turning a failed deploy into a sentence:
An existing test builds a quote with a 25% line discount and doesn't set the new checkbox, so the new rule blocks it. Fix: set the checkbox in that test's setup.
Those two jobs are its whole role. The rest is ordinary code.
Early access
We're opening this to a small group of Salesforce admins, developers and release folks first. If deploys are a weekly pain for you, the page is here: https://made-by-asking.pages.dev/deploy/?utm_source=devto
There's one optional question on the form, and the answers decide what gets built first.
AI-assisted: drafted with Claude Code; reviewed and edited by a person.
Top comments (0)