How to transition from Einstein Bots to Agentforce seamlessly

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. 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 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.

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.

#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, 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.

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.