Salesforce has made the call: Einstein Bots are a dead end. The agentforce vs einstein bots migration path is not optional planning for 2027; it’s an active architectural decision that affects your data model, your Flow topology, and your AI governance posture right now. Orgs that treat this as a simple “lift and shift” will rebuild twice.
The core issue is that Einstein Bots and Agentforce are not the same category of product wearing different names. Einstein Bots were scripted dialog trees with intent classification bolted on. Agentforce is a reasoning system. The Atlas Reasoning Engine doesn’t follow a decision tree; it plans, selects Actions, evaluates intermediate results, and iterates. That architectural difference has real consequences for how you model the migration.
A clarification worth making upfront: Agentforce can run without Data 360. A narrow authenticated journey can still use authoritative CRM records and existing verification. Data 360 becomes relevant when the use case needs identity resolution or a unified profile across systems. Authentication alone does not make Identity Resolution a universal prerequisite.
Why Einstein Bots Architecture Doesn’t Port Cleanly
Salesforce has released a Beta scaffolding tool called “Create AI Agents From Einstein Bots” that uses your existing bot as a reference to stub out a new Agent structure. That’s useful for orientation. It’s not a migration. Dialog nodes do not become Topics, NLU models do not feed the Atlas Reasoning Engine, and conversation variables do not carry over. The two systems share zero authoring objects, which means every piece of logic requires a deliberate rebuild decision.
Einstein Bots were built around Dialog nodes: a linear or branching conversation structure where each node handled a specific intent and routed to the next. The bot’s “intelligence” was mostly slot-filling: collecting variables and passing them to a Flow or Apex action at the end.
Agentforce inverts this. Instead of a dialog tree, you define Topics (the scope of what the agent handles), Actions (the tools it can invoke), and Instructions (behavioral guardrails). The Atlas Reasoning Engine, now running on the Agentforce 3 architecture with roughly 50% lower latency than earlier versions, decides at runtime which Actions to call, in what order, and whether to ask for clarification. There is no node-by-node script to migrate because the concept doesn’t exist in the target architecture.
This means your Einstein Bot dialogs are not migration artifacts. They’re requirements documentation. The actual migration work is re-expressing those requirements as Topics and Actions, not converting nodes into equivalent Agentforce constructs.
A common failure pattern in enterprise orgs: teams export their Einstein Bot dialog maps, try to create one Agentforce Action per dialog node, and end up with 40-plus granular Actions that the Atlas Reasoning Engine struggles to sequence correctly. The right ratio is closer to one Action per discrete business capability, not per conversation step. A “check order status” dialog with five nodes becomes one Action that returns a structured order object. One capability, one Action, clean output contract.
The Data Layer Is Where Migrations Actually Break
Einstein Bots often stored conversation context in session-scoped variables. Agentforce can use CRM records, Knowledge, Actions, and, where required, Data 360 profiles. The migration problem is deciding which context is transient, which belongs in a system of record, and which needs cross-system identity.
In practice, orgs discover that their Einstein Bot logic was compensating for data quality issues. The bot would ask the customer for their account number because the identity matching was unreliable. It would re-collect email addresses because the Contact record was stale. When you migrate to Agentforce and connect it to Data Cloud’s Identity Resolution layer, those compensating behaviors either become unnecessary or need to be replaced with explicit data quality rules.
If the approved use case relies on a Data 360 unified profile, run Identity Resolution against representative records before go-live and measure ambiguous, false-positive, and unresolved matches. If the use case does not need cross-system identity, do not add Data 360 merely because the interaction is authenticated.
Data Graphs matter here too. If your Agentforce Actions need to retrieve related records (orders, cases, entitlements), pre-computing those joins as Data Graphs dramatically reduces Action latency. An Action that queries live CRM relationships at runtime will be noticeably slower than one reading from a materialized Data Graph. At scale, that latency difference compounds across thousands of concurrent sessions. (See data-cloud-agentforce-foundation-architecture for the full dependency model.)
Flow Orchestration: What to Keep, What to Rebuild
Einstein Bots called Flows as terminal actions. The bot collected inputs, then handed off to a Flow to do the actual work. That pattern is partially preserved in Agentforce, but the relationship is different.
Agentforce Actions can invoke Flows, but the agent doesn’t hand off control. It calls the Flow as a tool and receives a result. The Flow needs to be designed as a discrete, callable unit with clear inputs and outputs, not as a full conversation handler. Many existing Einstein Bot Flows were built to handle the entire post-collection logic including error handling, retry loops, and user-facing messaging. Those need to be decomposed.
The practical rule: any Flow that contains messaging to the end user needs to be refactored. Agentforce owns the conversation layer. Flows should be pure business logic: query, update, create, return a result. The agent decides what to say about that result.
This is also where Apex enters the picture. Einstein Bot integrations that called external systems via Apex invocable methods can often be preserved as Agentforce Actions with minimal changes, provided the method signatures are clean. The bigger issue is error handling. Apex called from Agentforce needs to return structured error states that the Atlas Reasoning Engine can reason about, not throw exceptions that surface as generic failure messages.
Governance and Testing Before Go-Live
Einstein Bots had a relatively simple testing model: walk through dialog paths manually and verify slot collection. Agentforce testing is fundamentally different because the agent’s behavior is non-deterministic at the reasoning layer. The same input can produce different Action sequences depending on context.
The Agentforce Testing Center provides a structured environment for defining test scenarios against Topics and Actions. You’re testing behavioral envelopes, not specific paths. Define the acceptable range of responses for a given input, not the exact sequence of steps. This requires a different mindset than dialog path testing, and teams that don’t make that shift explicitly tend to under-test edge cases until production surfaces them.
Governance requirements also shift. Agentforce generates reasoning traces through the Atlas Reasoning Engine that can be logged and audited. For regulated industries, this is an improvement over Einstein Bots’ limited audit surface: you can demonstrate what the agent considered before taking an action. But it requires explicit logging architecture, not just enabling the feature. With Agentforce 3’s expanded LLM options (including Anthropic Claude Sonnet via Amazon Bedrock for high-compliance environments), the logging architecture also needs to account for which model handled which interaction.
Instructions deserve particular attention during migration. The behavioral guardrails you set in Instructions are the primary mechanism for preventing the agent from doing things your Einstein Bot couldn’t do by construction. A scripted bot couldn’t go off-script. An Agentforce agent can, unless Instructions explicitly constrain the scope. Every capability boundary that was implicit in your dialog tree structure needs to become explicit in Instructions. This is not optional cleanup; it’s the governance work that determines whether your agent behaves predictably in production.
For organizations working through the broader architectural implications of Agentforce deployment, /guides/agentforce-architecture covers the governance and design patterns in depth.
A Practical Migration Sequencing Framework
The migration sequence that consistently works in enterprise contexts follows four phases, and the order matters. Salesforce’s Beta scaffolding tool can inform Phase 1, but it doesn’t replace any of the four phases.
Phase 1: Capability inventory. Document every Einstein Bot dialog as a business capability, not a technical artifact. “Collect billing address” is not a capability; “update billing information for authenticated customer” is. This reframing is what makes the Topics and Actions design tractable. The scaffolding tool’s output is useful input here, not a finished product.
Phase 2: Data foundation. Identify authoritative records and freshness requirements. Add Data 360 Identity Resolution and Data Graphs only where the use case requires cross-system profiles or assembled context, then validate resolution quality before relying on it in Actions.
Phase 3: Action and Flow refactoring. Build Actions bottom-up from your capability inventory. Refactor existing Flows to be pure business logic. Test Actions in isolation using the Agentforce Testing Center before assembling them under Topics.
Phase 4: Behavioral validation. Define behavioral envelopes for each Topic. Run structured tests against edge cases: unauthenticated users, ambiguous requests, multi-intent inputs. Validate Instructions are constraining scope correctly. Only then move to production traffic.
Orgs that compress phases 1 and 2 consistently hit the same problems: identity resolution failures at runtime, Action latency issues from unoptimized queries, and agent behavior that’s hard to debug because the data layer is inconsistent.
The timeline for this sequence in a mid-complexity Einstein Bot deployment (10-20 dialogs, 3-5 integrated systems) is typically 10-14 weeks. Orgs that plan for 4-6 weeks are setting themselves up for a rushed Phase 4 that skips behavioral validation, which is exactly where production incidents originate.
The longer-term consequence matters too. Orgs that delay past the Salesforce Einstein Bots end-of-life milestone lose access to platform updates and support, and they end up rebuilding under deadline pressure rather than under architectural control. The migration debt compounds the longer the decision is pushed: what costs 12 weeks of planned work in 2026 becomes a forced 20-week scramble in 2027 with simultaneous business disruption.
Key Takeaways
- Treat Einstein Bot dialogs as requirements documentation, not technical artifacts. Re-express them as Topics and Actions. Node-by-node conversion produces 40-plus granular Actions the Atlas Reasoning Engine can’t sequence.
- Identity Resolution must stabilize before Agentforce goes live. Otherwise expect duplicate records and misattributed interactions at scale.
- Refactor every Flow that talks to the user. The agent owns the conversation layer, and Flows return structured results.
- If a behavioral guardrail was implicit in your dialog structure, it has to become an explicit Agentforce Instruction. Non-deterministic reasoning has no implicit scope.
- Plan for 10-14 weeks across four sequential phases. Compressing the data foundation phase is where production incidents originate.
