Migrating Einstein Bots to Agentforce: Why It Is a Rebuild, Not an Upgrade?
Salesforce documentation calls it a "transfer." Salesforce's own launch announcement calls it an "upgrade." Agentforce demos make it look seamless.
None of these describes what actually happens when an org tries to migrate Einstein Bots to Agentforce.
What actually happens: you rebuild. Not because Salesforce failed to ship a migration tool. Because the two systems share zero authoring objects.
Einstein Bots run on dialog trees and NLU models announced at Dreamforce 2017. Agentforce runs on an LLM, a reasoning engine, Topics, and Actions released in 2024.
This is not a version upgrade. It is a platform change. Here is what that means for your 2026 roadmap.
You Cannot Upgrade an Einstein Bot to an Agentforce Agent
Einstein Bots are rule-based systems. Every dialog, every response path, every variable must be manually authored. The bot follows a script. If a customer question falls outside that script, the bot fails.
Agentforce is LLM-driven. The Atlas Reasoning Engine interprets customer intent, selects appropriate Actions, executes them autonomously, and decides what to do next. There is no dialog tree. There is no script.
The two systems do not share a single authoring component. No dialog node becomes a Topic. No NLU model feeds the reasoning engine. No conversation variable carries over.
Salesforce has released "Create AI Agents From Einstein Bots" in Beta. It scaffolds a new agent using your bot as a reference. It does not port your implementation. What it does and does not do matters enough to address separately below.
Einstein Bots vs Agentforce: Two Different Machines
The gap between these systems is not incremental. They solve the same problem with entirely different architectures.
| Dimension | Einstein Bots | Agentforce |
|---|---|---|
| Core architecture | Dialog tree + NLU intent matching | LLM + Topics + Actions + Atlas Reasoning Engine |
| Authoring model | Dialog nodes, branches, named variables | Natural language Topic instructions, Flow/Apex-backed Actions |
| Escalation to human | "Transfer to Agent" dialog step, single Omni-Channel queue | Escalation Topic + Outbound Omni-Channel Flow (autonomous decision) |
| Data handling | One named variable per input (first name, email, description) | LLM maintains conversational context; conversation variables still exist for structured data passing |
| Infrastructure | Basic Omni-Channel + bot license | Data Cloud, Einstein Trust Layer, Omni-Channel Flows + Enhanced Messaging, Agentforce license |
| Pricing | Per-user (bundled with Service Cloud editions) | Flex Credits ($0.10 per action), per-conversation ($2), or per-user ($125/mo) |
Both handle customer service automation. That is where the similarity ends.
For a deeper look at how Agentforce works under the hood, including the reasoning engine and Action framework, see our technical breakdown.
What the Architecture Actually Changed
Authoring model. Einstein Bots required an admin to build every possible conversation path. A billing dispute needs a billing dialog branch. A different phrasing of the same question needs additional NLU training. Every variation is explicit authoring work.
Agentforce replaces this with Topics and Actions. A Topic defines a job to be done, described in plain language. Actions are executable steps: Flows, Apex classes, Prompt Builder templates, or External Service / MuleSoft API calls.
The reasoning engine matches customer intent to the right Topic and Action in real time. No pre-scripted path exists.
An Einstein Bot with 40 dialog nodes maps to zero Agentforce dialogs. The platform has no dialog objects. What maps are the underlying business logic units: the Flows, the Apex classes, the integrations. The conversational routing layer must be designed from scratch.
Escalation model. In Einstein Bots, escalation is a dialog step. You add a "Transfer to Agent" node, configure a queue, and you are done.
In Agentforce, escalation is an autonomous decision. The agent determines it cannot resolve the issue, triggers the standard Escalation topic, and routes through a dedicated Outbound Omni-Channel Flow. A separate Inbound Flow handles initial customer routing.
These two flows must be authored independently. The Outbound Flow is linked in the service agent's Connections tab; the Inbound Flow is configured at the messaging channel or routing configuration level. This two-flow escalation architecture is absent from most implementation guides and is the component teams most frequently misconfigure.
Data handling. Einstein Bots require a named variable for every piece of customer input. First name, last name, email, phone, case description: each is a separate variable object passed to an action step.
Agentforce significantly reduces this burden. The LLM maintains conversational context and retrieves Salesforce record data directly from the org. However, Agentforce does not eliminate variables entirely: conversation variables and context variables still exist for structured data passing between Actions and deterministic control. The difference is scale: an Einstein Bot with 20 custom variables might need 3-5 Agentforce conversation variables for the same use case.
What "Create AI Agents From Einstein Bots" Actually Does
Salesforce released Create AI Agents From Einstein Bots (Beta) as the closest thing to a migration path. Here is what it does.
The tool reads your bot's structure and scaffolds a new Agentforce service agent. It generates Topics and initial Actions based on your existing intents and dialogs. Your existing bot stays active after the agent is created, allowing a gradual transition.
What it does not do:
Port your NLU training data
Migrate conversation variables or map them to Agentforce context
Configure escalation flows (Inbound or Outbound)
Set up Omni-Channel routing or fallback queues
Create Einstein Trust Layer policies for data access
What you get: a scaffolded starting point, not a working agent.
What you still build: every Action implementation, every Topic instruction, the full escalation architecture, routing configuration, Presence Status assignments, and Trust Layer policies.
In our experience, the tool provides a structural starting point, but the majority of the implementation effort remains ahead of you.
This tool is in Beta as of March 2026 and requires contacting Salesforce Customer Support to enable. It is available in Enterprise, Performance, Unlimited, and Developer editions. Verify its current scope in your org before building it into project timelines.
The Rebuild Map: What to Throw Away, What to Keep
Not everything in your Einstein Bot implementation is lost. The useful rule: business logic survives, conversational logic does not.
| Component | Action | Why |
|---|---|---|
| Dialog nodes and branches | Rebuild as Topics + Actions | No equivalent object in Agentforce |
| NLU intent training data | Retire | Atlas Reasoning Engine handles intent natively |
| Named conversation variables | Mostly retire | LLM handles context; a few Agentforce conversation variables replace dozens of bot variables |
| "Transfer to Agent" step | Rebuild as Escalation Topic + Outbound Flow | Different architecture entirely |
| Flows used in bot actions | Reuse (minor updates possible) | Valid Agentforce Action sources |
| Apex classes in bot actions | Reuse | Transfer directly if properly invocable |
| Omni-Channel queue config | Partially reuse | Queue reusable; routing config needs rework |
| Case creation and record logic | Reuse | Business logic in Flow/Apex is portable |
| External API integrations | Reuse | Agentforce Actions support the same patterns |
If your team invested in Flows, Apex, and integrations, that work carries forward. If the investment was primarily in dialog branches and NLU training, it does not.
Before committing to timelines, audit your existing bot at the component level. See our analysis of common Agentforce implementation pitfalls for what to watch for during the rebuild.
The Infrastructure Your Org Needs Before You Start
Agentforce has infrastructure prerequisites that Einstein Bots never required.
Data Cloud. Data Cloud activation is a technical prerequisite for Agentforce (the Trust Layer and audit logging depend on it). Enterprise Edition and above can activate a zero-cost Data Cloud SKU to meet this requirement. A full Data Cloud implementation with paid credits is not required on Day 1, but it unlocks unified customer profiles and cross-object context that make agents significantly more capable over time.
Einstein Trust Layer. Every LLM call passes through the Trust Layer for audit logging and toxicity filtering. However, data masking is currently disabled for Agentforce agents. This means pattern-based and field-based masking that protects data in other Einstein AI features does not apply to agent conversations. For regulated industries (financial services, healthcare, public sector), this gap requires alternative data protection controls. Mapping which Salesforce fields each agent can access, and how sensitive data is handled in agent responses, is a compliance design exercise that must happen before go-live.
Omni-Channel Flows. The two-flow escalation architecture requires Omni-Channel Flows with Enhanced Messaging channels, not basic queue-based routing. If your org still uses legacy Omni-Channel routing, that upgrade is a prerequisite.
Licensing. Salesforce now offers multiple Agentforce pricing models: Flex Credits ($0.10 per action, consumption-based), per-conversation ($2), and per-user licenses ($125/user/month). Einstein Bots were bundled per-user with Service Cloud editions (25 conversations/month per license); Agentforce pricing is consumption-based or per-user add-on. At $0.10 per action (1 action = 20 Flex Credits), high-volume orgs need a usage modeling exercise before procurement. Note: Salesforce Foundations (free for Enterprise Edition and above) includes an initial Flex Credit allocation to get started. The new Agentforce pricing model has details on credit consumption patterns.
A Realistic Re-Platforming Plan for 2026
Einstein Bots have no announced end-of-life date as of March 2026. That creates a false sense of runway.
The real constraint is not Salesforce's deprecation timeline. It is your org's release calendar, your team's Agentforce experience, and the widening gap between what Einstein Bots can do and what customers now expect from AI-assisted service.
Phase 1: Audit (2-3 weeks). Catalog every dialog node, NLU intent, Flow, Apex action, and integration in your existing bot. Map each to rebuild, reuse, or retire. Identify Data Cloud and Omni-Channel gaps. This output is your scope document.
Phase 2: Design (3-4 weeks). Define Topics and Actions for each bot use case. Author Trust Layer policies. Design the escalation architecture. Get Flex Credit usage estimates approved.
Phase 3: Build (6-12 weeks). Build Actions first (Flows and Apex), then Topics, then escalation flows. Test each conversation path against the edge cases your Einstein Bot handled through explicit dialog branches. Agentforce 3.0 introduced improvements to the Action framework that can accelerate this phase.
Phase 4: Parallel run and cutover (4-6 weeks). Run Agentforce alongside Einstein Bot in test environments. Compare resolution rates. Cut over channel by channel, not all at once.
In our assessment, a realistic total for a mid-complexity bot is 4-6 months, audit to production. A single-use-case bot moves faster. A bot with 40+ dialog nodes and multiple channels takes longer.
The cost equation favors action. Einstein Bots on per-user licenses include a fixed conversation allocation regardless of whether the bot resolved 100 or 10,000 inquiries. Agentforce on Flex Credits scales with actual usage, which means the cost model rewards agents that resolve issues in fewer steps. For most mid-volume orgs, the per-action model is more cost-efficient than the per-user allocation it replaces. But you need usage data from Phase 4 to prove it internally.
For orgs that need both systems during transition, the hybrid architecture (Enhanced Bot + Agentforce Service Agent in the same contact center) is supported. The bot handles initial qualification; the agent handles resolution. This is a valid bridge strategy, not a permanent architecture.
If your org deployed Einstein Bots before 2024, you have recoverable assets: Flows, Apex classes, integrations. The conversational layer is not one of them.
If your org built Einstein Copilot configurations in 2024, the same principle applies. Copilot Actions may partially map to Agentforce Actions, but the orchestration model changed.
The teams that move fastest in 2026 are the ones that stop looking for a migration path and start planning a rebuild. The scope is real. The timeline is manageable. Business logic transfers. Conversational logic does not.
Ready to scope your Einstein Bot re-platforming?
Concret.io builds Agentforce implementations for Salesforce orgs navigating this transition. If your team needs a component-level audit, a rebuild plan, and a realistic timeline before committing, start here.
