You open Setup, type Agentforce Agents into Quick Find, and reach for the New Agent button you have clicked a dozen times this year. It is not there. It did not move to a submenu or hide behind a permission. Salesforce removed it on purpose.

Agent creation now happens in one place: the new Agentforce Builder, which lives inside a standalone app called Agentforce Studio. You reach it from the App Launcher, not from Setup. If your muscle memory has been routing through Setup all year, that alone is a small adjustment for every builder on your team.

One part deserves saying clearly, because the panic in my inbox has been out of proportion to the facts. Nothing was switched off. Agents you built in what is now called the legacy builder keep running, and you can still edit, version, activate, and deactivate them. What you cannot do is create anything new there. New voice agent creation stopped the same week. And Salesforce has said plainly that no further features are planned for the legacy builder.

How we got here

The legacy builder asked you to write instructions in English and trust the model to work out the rest. Which subagent handles this question. Which action runs first. Whether the refund check happens before or after the eligibility lookup. Atlas read your intent and picked a path.

That works right up until it doesn’t. And when it fails, you are debugging a probability, not a program. Ask the same question twice and you can get two different sequences, which is tolerable for a knowledge lookup and unacceptable for a loan application or a returns workflow with a compliance step in the middle.

Agent Script attacks this from a different angle. It is a compiled language: you write script, it produces a structured specification called the Agent Graph, and Atlas executes that. So the sequence is no longer something the model decides fresh on every turn. It is something you declared, and the engine follows.

Salesforce calls the result hybrid reasoning, and the name is more literal than most product names. You mark the places where the model should reason freely, and you mark the places where execution must be exact. The model keeps the conversation. The script keeps the workflow.

What teams are reporting after the rebuild

There is a second benefit that gets less airtime and matters more in production: latency. An agent following structured logic does not re-evaluate every subagent and every action on every single turn. It already knows where it is.

Here is a complete, if trivial, agent. Six blocks, and you can guess what most of them do.

AGENT SCRIPTsystem:
    instructions: "You are a friendly and empathetic agent that helps customers with their questions."
    messages:
        error: "Sorry, something went wrong."
        welcome: "Hello! How are you feeling today?"

config:
    agent_name: "HelloWorldBot"

variables:
    isPremiumUser: mutable boolean = False
        description: "Indicates whether the user is a premium user."

start_agent hello_world:
    description: "Respond to the user."
    reasoning:
        instructions: ->
            if @variables.isPremiumUser:
                | ask the user if they want to redeem their Premium points
            else:
                | ask the user if they want to upgrade to Premium service

Two characters carry most of the meaning. The arrow opens a block of deterministic logic that the engine evaluates before anything reaches the model. The pipe marks a line of natural language that gets sent to the model as a prompt. Everything else is scaffolding around that one distinction.

Look at what the conditional is doing. The choice between two prompts is not a judgement call anymore. It is an if statement reading a variable, resolved before the model sees a single token. The model still writes the sentence, and it writes it well. It just no longer decides which sentence it is writing.

Action chaining, which is where the real work happens

Most production agents fail on sequence, not on wording. This pattern is the fix.

AGENT SCRIPTreasoning:
  instructions: ->
    run @actions.check_eligibility
      with user_id=@variables.user_id
      set @variables.is_eligible=@outputs.eligible

    if @variables.is_eligible == True:
      run @actions.fetch_offer_details
        with user_id=@variables.user_id
        set @variables.offer=@outputs.offer

      | Present the offer: {!@variables.offer}
    else:
      | Explain that the user is not eligible for this offer.

The eligibility check runs first. Always. Not usually, not when the model remembers, not when the instruction was phrased well enough that day. The offer lookup only happens on a true result, and the model is handed a variable it cannot invent. If you have ever watched an agent cheerfully offer a discount to someone who did not qualify, this is the shape of the fix.

Salesforce gives you two routes. They are not competing options so much as two speeds, and the good news is you can use both on the same agent.

My recommendation, and Salesforce says something similar in its own migration guidance: convert first even if you plan to rebuild. The conversion gives you a working reference implementation of your own agent in the new language, which is a far better teaching document than any tutorial. Then refine it before you go live.

Where you are today changes the answer

Timing is doing you a favour this cycle. The Winter ’27 sandbox preview window opens at the end of August, which hands you a full copy of your own org running the next platform version while production carries on undisturbed.

Check Salesforce Trust for your specific instance rather than trusting the general weekend list, because instances move between releases and the generic date is not always yours.

I like this change. I want to be clear about that before I start listing the things that will bite you, because the criticisms below are not arguments against migrating.

Conversion gives you parity, not improvement

The upgrade flow translates your configuration faithfully. That is the point of it. But faithful translation of vague instructions produces vague script, and none of the case studies got their numbers from the conversion step. They got them from the redesign afterwards. If you convert and activate on the same afternoon, you have changed your tooling and nothing else.

Rollback is a manual act

Activating the rebuilt agent automatically deactivates the legacy original. It is not deleted, and you can reactivate it, but that is a decision someone has to make under pressure at the worst possible moment. Do not archive or delete the legacy version in week one. Leave it sitting there being useless until you are genuinely confident.

The permission model shifted underneath you

Building in Studio no longer requires admin level permissions, which is a real usability improvement and a governance question nobody put on the roadmap. Setup access used to be your access control by accident. Decide deliberately who can author and activate a production agent, and write it down, before somebody discovers the gap for you.

Preview sandbox metadata does not deploy backwards

Anything you create or edit using Winter ’27 features or the new API version in a preview sandbox cannot be deployed to production until production itself upgrades in October. Plan the sequence accordingly, or you will build something excellent in September that has to sit on a shelf.

Testing consumes the same wallet production does

Running realistic test volumes through an agent draws on your credit consumption. Track sandbox usage separately so a thorough regression pass does not quietly eat capacity you budgeted for customers.

Strip away the release notes and one property remains. Your agent used to live across a dozen screens and one person’s memory of why they configured it that way. It now lives in a file you can read top to bottom, review in a pull request, diff against last month, and hand to somebody new without a meeting.

Salesforce spent a decade teaching this community that clicks beat code. Then it looked at AI agents, the least predictable thing it has ever shipped, and reached straight for a language. Read that as an admission rather than a contradiction: some problems only behave once somebody writes them down.

So the question I would put to your team is not whether to migrate. It is simpler and slightly more uncomfortable. Can anyone in the room describe exactly what your production agent does, step by step, without opening Setup? If the answer is no, the file is not overhead. The file is the whole point.