# How to transition from Einstein Bots to Agentforce seamlessly An Einstein Bot is a dialog tree with slots and menus. Agentforce Service Agent is not that tree. Keep the bot on every narrow path that already returns a correct answer, and move a single channel only after the topic is grounded. **Published:** 2025-12-16 **Canonical:** https://synconai.com/transition-einstein-bots-to-agentforce **Author:** SynconAI Architecture Team ## In short An Einstein Bot is a dialog tree. Agentforce Service Agent is not. It handles service issues without preprogrammed scenarios. Keep the bot on narrow paths that already return a correct answer. Move one channel, and only subagents you have grounded, with a tested handoff. Leave ambiguous topics on the bot until retrieval and permissions are finished. ## Sources - **Agentforce: What types of AI agents are there?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > Service Agent replaces traditional chatbots with AI that can handle a wide range of service issues without preprogrammed scenarios, improving customer service efficiency. - **Agentforce: How does Agentforce work?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > It starts with the Atlas Reasoning Engine, which breaks down the initial prompt into smaller tasks, evaluating at each step and proposing a plan for how to proceed until the complete answer or action is achieved. ## What to take away - A dialog that already collects one slot, calls one Flow, and stops can stay on the bot. - Service Agent does not reuse your menu. It needs a maintained source, one action, and a stop. - Move one grounded topic on one channel. Watch reopens and empty escalations before the next. - Complaints, money, and dialogs that already escalated stay as handoffs. Do not ask the agent to try harder. ## The guide The transition goes badly when it is treated as a rename. On the day Service Agent is switched on, the bot is switched off. A customer asks for the status of a case and gives a first name. The tree used to ask for the case number and stop when the match failed. The plan guesses the Account, answers with certainty about the wrong person, and the reply looks like an improvement because it is a full sentence. The record is someone else's. The slot that made the old path correct was the thing you retired. The bot remains a dialog tree: intents, slots, menus, and a branch when the match fails. Service Agent is a different thing. Salesforce describes it as handling a wide range of service issues without preprogrammed scenarios. If your current bot is correct because the scenario was programmed, switching the label does not preserve that correctness. The correctness lived in the branch. The Atlas Reasoning Engine breaks a prompt into smaller tasks and proposes a plan. That plan is useful on wording you could not draw as a menu. It is a poor replacement for a menu that already collected an Id and called a Flow. Use it where the sentence varies and a maintained source can still answer. Leave it off the path where the slot was the product. ## What stays on the bot Stay on the bot when the dialog is a narrow path with a right answer. Case status once the person has given a case number. A published location. A menu that creates a Case, sets a queue, and ends. Those dialogs are deterministic. The same input produces the same output, and a new starter with the dialog in front of them would be wrong to do anything else. Moving them for the sake of a single front door adds a plan where a slot was doing the job. List them. For each one, note the slot it collects and the Flow or assignment it calls. As long as that pair is correct, the bot keeps it. You can put an agent in front later, still calling the same Flow, after you have proof the plan collects the same slot and then stops. Proof is a trace, not a demo in which someone typed the case number because they already knew the happy path. The utterance to test is the one that used to fail the match. It should still reach a person, with the partial facts attached, rather than a guess. There is no prize for an empty bot. A bot that still owns five narrow dialogs is doing the work it was built for. Retiring it because the new agent can also speak is how you pay, in reopens, for a front door you did not need yet. The stalls that show up when people try to import the whole intent list anyway are set out in [the migration challenges](/challenges-migrating-to-agentforce). This page is the order of the move, assuming you have accepted that the lists are not the same object. ## What can move, and when Move a topic when three things are true. The answer comes from a maintained source the running user can see. The action is one call, not a reimplementation of a Flow. The handoff is tested: a person receives the record Id, the question in the customer's words, and what was already tried, including a refusal. Good first topics are questions where the wording varies and the answer is a current Knowledge article, with a hard stop when the article is missing or the user cannot see it. The plan is allowed to interpret the sentence. It is not allowed to invent the policy. If two articles disagree, the subagent is not ready, however varied the wording is. Disagreement is a content problem, and the plan will pick a paragraph. [The grounding checklist](/insights/agentforce-grounding-checklist) is the work that has to be finished before that topic faces a customer. A topic name and a confident instruction do not finish it. Do not move refunds, complaints, regulatory mentions, or any dialog that already escalated after one failed match. Those were handoffs. The new agent should not try harder on them. Trying harder is how a tree that knew its limit becomes a plan that talks past it. Agents escalate when the issue is beyond their scope. Keep that as a rule you wrote down, with the topics named, not as a hope about tone. A warm refusal that still offers a partial refund "to be helpful" is the plan talking past the limit you had already designed. | Path | Stays until | Moves when | | --- | --- | --- | | One slot, one Flow, a stop | The bot, for as long as that pair is correct | An agent calls the same Flow, collects the same slot, and stops, on a trace you have read | | Fixed menu that creates a Case | The bot | You still want it, and the create has not been reimplemented in instructions | | Wording varies, answer is one current article | Not a first demo of the menu | The running user can open the article, and a missing article hands off | | Refunds, complaints, a regulator, a failed match | A person, on the path you already have | You do not move these in order to make the new channel look complete | Read the last row twice. Completeness is the argument that puts dangerous topics on the new channel because the old channel is being "replaced". The old channel is not being replaced. It is being narrowed, on purpose, to the paths that were already correct. ::: warn A dialog that already escalated after one failed match keeps escalating. Asking Service Agent to handle that residue, because it can speak in sentences, removes a limit you had already designed. Beyond scope means a handoff, with the slot still attached. ::: ## Move one channel Pick one channel. Leave the bot in place on the others. On the chosen channel, enable only the topics that passed the three checks. Everything else on that channel still needs an owner: the bot's remaining dialog, or a queue. A channel with a hole, where some utterances have no owner, is worse than a channel you have not touched. The customer does not experience a phased plan. They experience a dead end, or a guess. Then watch that topic. Reopens. Escalations that arrived empty. Replies that quoted an article the channel user cannot open. A second search after the record Id was already known. If those are quiet, move the next topic on the same channel. A second channel comes after the first channel is dull. Dull is the success condition. It means a supervisor can look at the week and not have a story about a wrong Account. Do not use the quiet week as permission to move the narrow menus "while you are there". The menus were not the risk. Moving them adds a plan to a path whose value was that it had no plan. If you want a single front door later, earn it by having the agent call the existing Flow and stop. [That boundary, between a plan and a step that already has a right answer](/best-practices-automated-workflows-agentforce), is the same boundary on the way out of a bot as it is on a fresh build. ## How the cutover fails The sharp failure is turning the bot off on the day Service Agent is switched on. The tree was collecting the case number. The plan now guesses the Account from a first name and answers with certainty about the wrong person. The reply looks current. The record is someone else's, and the customer may not know enough to correct it before they act on the answer. Put the bot back on that path the same day. Do not spend the afternoon tuning the instruction to guess better. Guessing better is still guessing. The slow failure is moving the narrow paths first because they demo well, and leaving the messy topics on a bot nobody is maintaining. The narrow paths were never the problem. The demo was impressive because the slot still constrained the answer, and the audience mistook the constraint for the model. Move the narrow paths last, or leave them. Spend the transition on the topics where wording varies and the source is actually fit to quote. If those topics are not fit, the transition is a grounding project, and switching the front door will not make it one. A third failure sits between them. The handoff was tested with a patient colleague who already knew the Case. In production the escalation arrives as "customer needs help", and the colleague is not on the queue. The payload is part of the three checks, not a courtesy. Record Id, question, what was tried, what was refused. If any of those are missing, the topic has not moved. It has been abandoned in a new channel. ::: note Test the plan, not the farewell message. For a known case number, the only acceptable trace is a read of that Case and a stop. A second search "to be sure" is a failed test. Certainty is not a requirement. Stopping is. ::: A transition also fails when the running user is copied from the bot. The bot often ran as a wide integration user, because its job was to collect a slot rather than to quote a record. Service Agent quotes. The wide user then becomes the boundary of what a customer channel can hear. Set the running user to the channel before the first topic moves, and ask for a record that user should not open. A useful answer is a failed test, even when the facts are right. Do not widen sharing so the first week looks informed. The bot's dialog and the agent's topic will both be live on different channels for a while, and someone will file a defect that they disagree. Often they disagree because the article moved and the dialog line did not, or the reverse. That disagreement is useful. It is the drift you would not have seen if you had turned the bot off. Write it down against the dialog name on your list, and decide which text is the source. Do not fix it by pasting the dialog line into the agent instruction. You would be building the second copy the move was supposed to leave behind. ## The order of the work Week one, write the list. Slot, Flow, and whether the pair is still correct. Mark the dialogs that already escalate, and leave them marked. Week two, ground one topic whose wording varies, as the running user of the channel you intend to move, including a user who should be denied. Week three, turn that topic on for one channel, with the bot still owning everything else, and read reopens and empty escalations before you add a neighbour. Then stop adding. A dull channel is allowed to stay dull. The next topic has to pass the same three checks, not inherit a pass from the one beside it. A transition done in that order is slower than a rename, and it keeps the paths that were already right. A rename keeps nothing, and it spends the following month putting the slots back, usually under a different name, in the instruction. The instruction is a bad place to rediscover a menu you used to have. ## Questions ### Do we have to rebuild every Einstein Bot dialog? No. A dialog that collects one slot and calls one Flow should stay until an agent can call that same Flow and stop. Service Agent is not a dialog tree. It is for issues that do not have a preprogrammed scenario. Narrow, correct paths are not that, and retiring them for a single front door adds a plan where a slot was doing the job. There is no prize for an empty bot. ### Which topic should move first? One whose wording varies and whose answer is a maintained article the running user can see, with a tested handoff when the article is missing. Do not lead with the menu that already works. That menu demos well because the slot still constrains it. Do not lead with refunds or complaints. Those stay as handoffs. If two articles disagree, the topic is not ready, however varied the wording is. ### Can we switch every channel in the same release? No. Move one channel, and only the topics you have grounded. Leave the bot running elsewhere, including on the same channel for everything you did not move. Read reopens and empty escalations on that topic before you add another. A single cutover drops the slot collection the tree was doing for you, and the plan will guess an Account from a first name. ### What happens to dialogs that already escalated? They keep escalating. A failed match that used to reach a person should still reach a person, with whatever facts were collected still attached. Asking Service Agent to handle that residue, because it can speak in sentences, removes a limit you had already designed. Beyond scope means a handoff. A warm partial answer is the plan talking past that limit. ### How do we know a moved topic is safe? The plan reads the right record, cites a source the user can open, and stops. A known case number produces one read and no extra search. If the trace guesses an Account, or quotes an article the channel cannot see, the topic is not ready. Put it back on the bot or the queue the same day. Do not spend the afternoon teaching the instruction to guess more accurately. A better guess is still a guess. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce consulting (https://synconai.com/salesforce-agentforce-consulting).