How to Upgrade Einstein Bots to Agentforce (2026 Guide)

For two years the honest answer to "how do I upgrade Einstein Bots to Agentforce?" was "rebuild it." Bots and agents work differently: a bot follows a scripted decision tree, while an agent reasons over instructions and actions. There was no migration path, so most service teams just kept their bots running and planned a rewrite for some later quarter.

That changed in 2026. Salesforce now offers a way to generate an Agentforce Service Agent from an existing Einstein Bot, plus a developer-side upgrade workflow for teams moving several bots at once. It's not a magic button, and the output is a draft. But it turns a blank-page rebuild into a review-and-finish job.

Two Ways to Upgrade Einstein Bots to Agentforce

1. Create an AI agent from an Einstein Bot (in Setup). Salesforce Help documents a feature, currently labeled Beta, that analyzes your bot's dialogs, intents, and action steps and generates an Agentforce Service Agent. At Dreamforce 2026, Salesforce presented this as the Upgrade Agent, available through Agentforce Labs.

What it does, per Salesforce's documentation:

• Creates subagents from groups of dialogs with similar intents
• Generates agent actions from your bot's action steps
• Creates the agent as a separate record, so your bot keeps running while you review
• Requires you to activate the new agent before connecting it to channels

It's listed for Enterprise, Performance, Unlimited, and Developer Editions with Foundations or Agentforce 1 Editions. You start it from your Einstein Bots in Setup; Salesforce Help documents the steps. Salesforce's help page still labels it Beta, and we couldn't confirm a GA date.

Know its limits going in. A hands-on walkthrough reports that the converter doesn't design escalation paths, connect channels, set up grounding, or test anything. It gives you the structure; the rest is still your job.

2. The agentforce-bot-upgrade skill (for developers). Salesforce's open-source skills library (forcedotcom/sf-skills, covered in our agent skills guide) includes an agentforce-bot-upgrade skill for AI coding tools like Claude Code, Cursor, or Agentforce Vibes. It retrieves Bot and BotVersion metadata, writes an Agent Spec per bot, reconciles overlap across multiple bots, and then generates Agent Script agents. It supports an online mode (reads from your org) and an offline mode (reads metadata files you've already retrieved).

Use the Setup path for one or two bots and an admin-led project. Use the skill when you're moving several bots, already deploy with source control, or want the conversion reviewed in a pull request.

Step 1: Inventory Your Bots

Before you convert anything, find out what you have. These queries list your Einstein Bots and their versions:

SELECT DeveloperName, MasterLabel, Type, LastModifiedDate
FROM BotDefinition
WHERE Type = 'Bot'
ORDER BY LastModifiedDate DESC

SELECT BotDefinition.DeveloperName, VersionNumber, Status
FROM BotVersion
WHERE BotDefinition.Type = 'Bot'
ORDER BY BotDefinition.DeveloperName, VersionNumber

For each bot, record which version is active, which channels it's on, and roughly how many conversations it handles. Start with a bot that has real traffic but isn't your most critical channel.

Step 2: Understand How Bot Concepts Map to Agent Concepts

The agentforce-bot-upgrade skill publishes its mapping rules, and they're the clearest explanation we've seen of how the two models line up:

Two practical consequences:

• Transfers aren't rebuilt as actions. Handoffs to humans map to Agentforce's built-in escalation (in Agent Script, the @utils.escalate utility). Don't create a "Transfer to Agent" action; configure escalation and your Omni-Channel routing instead.
• Some actions come through as stubs. If the converter can't determine how an action step works, it flags it for you to build. Budget time for these.

Step 3: Generate the Draft Agent

In the Setup path, run the conversion on your chosen bot and version, then open the new Agentforce Service Agent in Agentforce Builder. In the developer path, run the skill against your org alias and bot version (for example --bots Order_Bot:v3), and review the Agent Spec and generated agent files before deploying.

Whichever path you use, read every generated subagent's instructions. Converted instructions describe what your bot did, which isn't always what you want an agent to do. Bots were often built around their limitations (rigid menus, "please choose 1, 2, or 3"). An agent doesn't need those, and leaving them in makes the agent feel like a bot with extra steps.

Step 4: Fill the Gaps

Expect to spend most of your time here:

1. Build stubbed actions. Wire them to the same Flows or Apex your bot used, or replace them.
2. Check action permissions. Agent actions run under the agent's user context. Confirm it can read and update exactly what the bot could, and nothing more.
3. Rewrite rigid dialogs as instructions. "Collect order number, then call Get Order Status" is fine. Five nested menus are not.
4. Ground knowledge answers. If your bot used Article Answers, note that it reached its final cutoff at the end of 2025. Ground the agent in Knowledge through Agentforce instead.

A Worked Example: The Order Status Bot

Here's what the shift looks like on the most common service bot there is.

The Einstein Bot version usually has a main menu dialog, an "Order Status" dialog, a slot that collects an order number with a validation pattern, an Apex or Flow action that looks up the order, a message that reads back the status, and a fallback that transfers to a live agent after two failed attempts.

After conversion, expect roughly:

• One subagent for order inquiries (the order status dialog plus related ones such as "where's my package" and "change delivery address", if they shared intents)
• A variable for the order number, with a guard so the lookup action only runs once it's collected
• The lookup as an action, wired to the same Flow or Apex, or flagged as a stub if the converter couldn't tell how it worked
• Escalation handled by the built-in escalation, not a custom transfer action

What you rewrite by hand is the instructions. The converted version will describe the bot's script ("Ask for the order number. If invalid, ask again. After two failures, transfer."). A better agent instruction says what good looks like: "Help customers check the status of an existing order. You need the order number before looking anything up. If the customer doesn't have it, offer to find the order by email address. Escalate if the order shows as lost or the customer asks for a person." The agent decides the conversation path; you define the goal and the boundaries.

Common Mistakes

• Converting every bot version. Convert the active version only. Old versions carry dialogs nobody uses.
• Keeping the menu. If the converted agent still opens with "Please choose from the following options," you've built a bot with extra latency.
• Skipping the action review. A stub that silently does nothing is worse than an error. Find and finish every one before testing.
• Testing only the happy path. Bots fail predictably; agents fail creatively. Your test suite needs off-topic, rude, and confusing inputs.

Step 5: Test Before Any Customer Sees It

Don't connect a channel until the agent passes a test suite built from your bot's real traffic. Take the 20 most common intents your bot handled and write test utterances for each, plus a few off-topic and adversarial ones. Agentforce Testing Center can run these as a suite, and our guide to testing and monitoring Agentforce agents walks through it.

Step 6: Cut Over Gradually

You don't have to switch everything at once. Salesforce has documented a pattern where an Einstein Enhanced Bot hands conversations to an Agentforce Service Agent through an Omni-Channel flow. That lets you route one intent, one queue, or one customer segment to the new agent while the bot handles the rest.

A sensible cutover:

1. Route one low-risk intent (order status, store hours) to the agent
2. Compare resolution and escalation rates against the bot for two weeks
3. Expand intent by intent
4. Deactivate the bot only when the agent handles everything it did

Should You Upgrade Your Einstein Bots Now?

If your bot works and nobody is complaining, you're not under a deadline. We found no published end-of-life date for Einstein Bots. But new investment is going into Agentforce, and features like voice, multi-agent orchestration, and the Agentforce Contact Center assume agents, not bots. The conversion tooling removes the biggest excuse for waiting.

Before you start, read why Agentforce pilots fail. A converted bot is still a pilot until it's proven in production.

Frequently Asked Questions

Can I convert an Einstein Bot to an Agentforce agent automatically? Yes. Salesforce can generate an Agentforce Service Agent from an existing Einstein Bot by analyzing its dialogs, intents, and action steps. The result is a first draft you review and finish, not a finished agent.

Does upgrading an Einstein Bot turn off the original bot? No. The generated agent is a separate record. Your existing bot keeps running while you review, test, and activate the new agent, so you can switch channels over when you're ready.

Is Salesforce retiring Einstein Bots? We found no published end-of-life date for Einstein Bots. They're still supported, but Salesforce's new investment is going into Agentforce, and the Agentforce Service Agent is the direct successor.

What doesn't carry over when upgrading an Einstein Bot to Agentforce? Actions whose implementation can't be determined need to be built or stubbed, scripted dialog flows become reasoning-based instructions, and you must retest everything. Transfers to humans map to Agentforce's built-in escalation.

---

Keep reading:

• Salesforce Agentforce Contact Center: What It Is and Who Should Care
• How to Test and Monitor Agentforce Agents in Production
• How to Set Up an Agentforce Agent Without Code in Salesforce 2026 (Step-by-Step)