- Salesforce Managed Services
As of September 2026, Einstein and Agentforce are two different things running side by side in most Salesforce orgs, and neither one replaced the other. Einstein still owns the predictive layer and is still receiving updates. Agentforce is the agentic platform Salesforce now builds almost everything around. One agent type moved from one name to the other, and that single rename is responsible for most of the confusion people still carry.
If you came here because your Setup menu says Agentforce, where it used to say Einstein Copilot, the short answer is that nothing broke and nothing needs migrating. If you came here trying to work out what you should actually be running in 2026, that’s a longer answer, and the platform has moved considerably in the last nine months.
This guide covers where both products stand right now, what changed across 2026, which transitions are genuine rebuilds, and how to decide what to do about any of it.
TL;DR
Two products, one confusing label swap
Einstein and Agentforce run side by side in most orgs today, doing genuinely different jobs. Einstein predicts and scores from your CRM history. Agentforce reasons and acts. A single agent type moved between the two names, and that alone caused years of misreading.
Knowing which changes demand a project
Some shifts were pure branding and need nothing from you. Others share zero authoring objects and mean building from scratch. Getting that wrong is how teams either rip out working Einstein features or discover a rebuild three weeks before a deadline.
The 2026 picture nobody has updated
Agentforce ARR passed $1.5 billion in August, Claudeforce landed the same week, and Winter ’27 switches Agentforce on by default. Meanwhile, Salesforce shipped an Einstein Activity Capture update last month, which answers the retirement question outright.
Where Things Stand Right Now
Let’s anchor on current numbers rather than the launch-era figures that still circulate in most articles on this topic.
The 2026 Scoreboard
Salesforce reported its Q2 FY27 results on 26 August 2026, and the figures for Agentforce show a product line scaling fast:
- Agentforce ARR exceeded $1.5 billion, up over 240% year over year
- Agentforce and Data 360 combined ARR reached nearly $3.9 billion, up over 210% year over year
- 7.0 billion Agentic Work Units delivered to date, with 3.2 billion in Q2 alone, growing 97% quarter over quarter
- Data 360 ingested 104 trillion records in Q2, up 355% year over year, including 82 trillion via Zero Copy
- Salesforce raised full-year FY27 revenue guidance to between $46.1 billion and $46.4 billion
Those are adoption numbers for Agentforce specifically. There is no equivalent set of retirement announcements for Einstein, which is the first clue that the two products are not on a replacement trajectory.
What Actually Changed in 2026
A lot, and most of it is genuinely relevant to this comparison. Here’s the year so far in one place.
When | What happened | Why it matters here |
February 2026 | The new Agentforce reached GA with hybrid reasoning | Agents moved from purely probabilistic reasoning to a model that separates deterministic execution from LLM judgment |
14 February 2026 | Legacy Chat (Live Agent) retired | A hard cutoff. Orgs still running embedded chat had to move |
April 2026 | Topics renamed to subagents | Terminology only, but it means documentation now mixes both terms |
April 2026 | Headless 360 announced | Exposed platform capability as APIs, MCP tools and CLI, laying groundwork for what came later |
April 2026 | Agent Analytics and Agent Optimization reached GA | Post-deployment observability caught up with the build tooling |
26 August 2026 | Claudeforce announced with Anthropic | Claude becomes a reasoning model across Agentforce surfaces |
Winter ’27 release | Agentforce platform enabled by default for all licensed orgs | The setting disappears from Setup. Agentforce becomes the baseline rather than an opt-in |
Notice what isn’t on that list: any deprecation, sunset, or retirement of Einstein’s predictive features. That absence is the answer to the question most people are really asking.
The Rename That Started the Confusion
To understand why people still ask this question, you have to go back to the single event that caused it.
What Salesforce Actually Said
Salesforce renamed the Einstein Copilot for Salesforce agent type to Agentforce, explaining that this was part of growing its team of Agentforce agents and came with no changes in functionality. Permissions, UI elements and Help documentation were updated to match. In Setup, admins would start seeing Agentforce or Agentforce (Default) as the agent name and type.
The reassuring line, straight from the Salesforce release note, was that the change wouldn’t impact existing implementations. Agents carried on doing exactly what they did before, embedded in the same places in the same workflows.
So why did this cause lasting confusion? Because it landed in the middle of an enormous marketing push positioning Agentforce as a transformative new product. When the messaging around a name change is all about transformation, it’s genuinely hard to tell a relabelling from a replacement. Admins reasonably assumed their Einstein investment had been obsoleted.
The Competitive Backdrop
Worth knowing, because it explains why the name had to go rather than simply evolve.
Salesforce was in the middle of a sustained public campaign against Microsoft’s Copilot product. Marc Benioff had repeatedly criticised it in the press, and Salesforce’s own launch materials made a point of saying Agentforce went beyond chatbots and copilots. Continuing to sell your own product called Copilot while attacking a competitor’s Copilot is an awkward position. The rename resolved it.
That’s not cynicism, it’s just context. Understanding that the rename was partly a branding decision helps explain why it carried no functional weight.
The Naming Trail, Untangled
Part of why this topic stays confusing is that Einstein has been through several distinct phases, and people who joined the ecosystem at different points mean different things by the word. Here’s the sequence, because it clears up a lot of cross-talk.
Einstein began as a predictive layer, doing lead scoring, opportunity insights and forecasting off models trained on CRM history. That’s still what it does, and that generation of features is what remains live today. A generative phase followed, adding GPT-grounded content generation, email drafts and summaries. Then came Einstein Copilot, the conversational assistant embedded in the Salesforce UI, which reached general availability in April 2024 and was renamed nine months later.
So when someone says “we use Einstein,” the sensible follow-up question is which one. A team running Einstein Opportunity Scoring and a team that had Einstein Copilot deployed are in completely different positions with respect to this rename. The first team is unaffected in every way. The second team saw a label change and nothing else.
A quick glossary of what each current term actually refers to:
- Einstein on its own now generally means the predictive feature set inside Sales and Service Cloud
- Einstein Trust Layer is the security and governance layer processing every generative call, including Agentforce ones
- Einstein Studio remains the environment named in current release notes for model and prompt work
- Agentforce is the agentic platform, and also the name of the renamed default agent type
- Agentforce 360 is the bundled platform including Data 360 and Customer 360 Apps
- Atlas Reasoning Engine is the execution engine underneath Agentforce agents
- Subagents are what topics are now called, following the April 2026 rename
If a vendor or consultant uses these terms interchangeably, that’s a reasonable signal to ask more questions.
Rename vs Rebuild: The Table That Settles It
This is the distinction that actually matters for planning, and almost nothing written on this topic separates the two properly. Some changes were cosmetic. Others require building something from scratch. Here’s where each one lands as of September 2026.
What changed | Rename or rebuild? | What it means for you |
Einstein Copilot for Salesforce becomes Agentforce | Rename | Nothing to do. Permissions, workflows, integrations and custom actions all carried over untouched. |
Data Cloud becomes Data 360 | Rename | Same product, new name, now bundled into Agentforce 360. No migration required. |
Topics become subagents (April 2026) | Rename | Terminology only. Salesforce documentation currently contains a mix of both terms. |
Einstein Bots to Agentforce | Rebuild | They share zero authoring objects. Your dialogs, intents and entity definitions have no destination. This is a rebuild with a familiar requirement attached. |
Legacy Chat (Live Agent) to Messaging or Agentforce | Rebuild | Retired 14 February 2026. Not optional, and never a migration path. |
Einstein predictive features | Neither | Still live, still supported, still receiving updates in 2026. Agentforce does not replace them. |
Einstein Trust Layer | Neither | Kept its name and runs underneath every Agentforce generative call. |
If your situation sits in the rename rows, you can stop worrying about it. If it sits in the rebuild rows, you have a real project, and treating it as an upgrade is how teams end up surprised three weeks before a deadline.
What Einstein Still Is in 2026
The most common misreading of all this is assuming Einstein got absorbed entirely. It didn’t, and the evidence is more recent than most people realise.
The Predictive Layer Is Alive and Well
Einstein still owns the predictive side of Salesforce AI, which is a genuinely different category from what Agentforce does. These features are model-trained on your historical CRM data rather than generative:
- Einstein Lead and Opportunity Scoring, ranking what’s most likely to convert based on your closed-won history
- Einstein Case Classification, predicting case field values at creation and wrap-up
- Einstein Activity Capture, syncing email and calendar activity into CRM automatically
- Einstein Next Best Action, surfacing recommendations at the right moment inside a record page
- Einstein Prediction Builder, letting admins build custom predictions without writing code
- Einstein Conversation Insights, analysing sales calls for keywords and coaching signals
- Einstein Deal Insights and Account Intelligence, both shipped as part of Sales Cloud
None of these were renamed, replaced or deprecated. They appear in current Salesforce licensing documentation as active features. If you’re running Einstein Opportunity Scoring today, Agentforce has no bearing on it whatsoever.
Einstein Is Still Being Actively Updated
This is the detail that settles the argument, and it’s almost never mentioned in comparison articles.
In August 2026, Salesforce shipped an update to Einstein Activity Capture adding finer email and event exclusion controls. That is not the release cadence of a product being quietly wound down. Products on their way out get maintenance and security patches, not new configuration options.
The Einstein name also survives in tooling. Einstein Studio remains the environment named in current release notes, including the notice that Gemini 2.5 model requests will be rerouted to Gemini 3.5 on 20 October 2026, with Salesforce advising customers to test prompts in Prompt Builder and Einstein Studio beforehand. Salesforce is still writing the Einstein name into release notes dated months into the future.
The Einstein Name That Survived Everything
Here’s a detail that trips people up constantly. The Einstein Trust Layer kept its name, and it sits underneath Agentforce rather than beside it.
Every generative call an Agentforce agent makes passes through it. Secure data retrieval so grounding respects the executing user’s permissions. Dynamic grounding to inject real records at runtime. Data masking that swaps sensitive values for placeholder tokens before the prompt leaves the Salesforce boundary. Prompt defense. Toxicity scoring on the way back. An audit trail held in your own org. And a zero data retention policy with external model providers, meaning prompts aren’t stored or used for training.
So when someone asks whether they should use Agentforce or the Einstein Trust Layer, the question doesn’t quite parse. You use both, always, because one runs inside the other. There is no Agentforce deployment that doesn’t touch Einstein.
What Agentforce Became in 2026
Set the naming aside and there’s a real product shift underneath, which is exactly why this got confusing. Agentforce in September 2026 is a substantially different thing from what was renamed.
From Assisting to Acting
Einstein Copilot assisted. You asked it something, it drafted an email or pulled up a record, and you decided what happened next. A human stayed in the loop on every meaningful step.
Agentforce acts. An agent works through a multi-step request end to end, deciding which tools it needs, using them, checking whether the result solved the problem, and escalating to a person only when policy or genuine ambiguity requires it.
That sounds incremental in a sentence. Architecturally it’s substantial, because taking action demands a precision that suggesting an action doesn’t. If a copilot drafts a poor email, you delete it. If an agent issues a refund it shouldn’t have, that’s a real problem with a real cost.
Hybrid Reasoning Changed the Risk Profile
The most consequential 2026 development for anyone weighing this decision. The new Agentforce reached general availability in February 2026, shifting from purely probabilistic reasoning to a hybrid model.
Salesforce’s architect documentation is candid about why. In the previous model, every decision ran through the language model in real time. Minor variations in input or model version produced different action selections on identical requests. A workflow that passed in staging could behave differently in production, with no reliable way to reproduce an execution path for audit.
For open-ended support conversations, that variability is acceptable. For a loan approval or a patient triage process, it isn’t. As Salesforce’s own architects put it, “the agent decided” is not a defensible answer in a compliance review.
Agent Script, the declarative language for defining agent behaviour, now lets you pin critical steps as code the model cannot override, while leaving genuine judgment calls to the Atlas Reasoning Engine. If you’re weighing Agentforce against a rules-based Einstein Bot on predictability grounds, this closes a lot of that gap. We’ve covered the mechanics in detail in our guide to how Agentforce works.
Claudeforce Reset the Reasoning Layer
The newest development, and one most comparison content hasn’t caught up with yet.
On 26 August 2026, Salesforce and Anthropic announced Claudeforce, an expanded partnership bringing Claude’s reasoning together with Salesforce’s data, workflows, business logic and governance. It runs in two directions. Claude becomes available as a reasoning model across Agentforce surfaces, and Salesforce becomes available inside Claude through a plugin shipping with 37 prebuilt sales skills covering meeting preparation, deal health reviews and pipeline analysis.
The plugin went to select pilot customers first, with open beta expected in September 2026 and additional prebuilt skills launching later in the year. It’s made possible by AIforce, Salesforce’s enterprise harness that exposes business data and workflows to any agent through MCP servers, APIs and CLI tools, which itself builds on the Headless 360 work announced in April 2026.
Why this belongs in an Einstein comparison: it demonstrates how far the agentic layer has moved from anything Einstein Copilot was. Einstein Copilot was a chat interface inside the Salesforce UI. The current direction is CRM capability reaching agents wherever people already work, with governance travelling alongside it. Those are different product categories, not different versions of the same one.
Agentforce Is Becoming the Default
One more change worth planning around. In the Winter ’27 release, the Agentforce platform is enabled by default for all orgs with Agentforce access through their SKUs, licensing and editions. New orgs are enabled at creation and existing orgs get auto-enabled, with the Agentforce setting removed from the Agentforce Agents page in Setup.
Practically, this means the question shifts from whether to turn Agentforce on to whether you’re governing it properly once it’s on. Worth raising with whoever owns your org’s security model before it happens rather than after.
Agentforce vs Einstein: Side by Side
Pulling it together into the comparison people actually came looking for.
| Einstein | Agentforce |
What it does | Predicts, scores, classifies and recommends | Reasons, decides and executes multi-step work |
How it learns | Models trained on your historical CRM data | Grounded generative reasoning over live data |
Human involvement | Surfaces insight for a person to act on | Acts autonomously, escalating when policy requires |
Where it lives | Embedded in Sales and Service Cloud features | The agentic layer across the whole platform |
Pricing | Inside Sales and Service Cloud editions and add-ons | Separate models: per conversation, credits, or per user |
2026 status | Active, supported, still receiving updates | Where roadmap investment is concentrated |
Do they overlap? | Rarely. Different jobs entirely | Runs on the Einstein Trust Layer, so they interlock |
The framing that helps most: Einstein tells you what is likely to happen. Agentforce does something about it. Plenty of well-run orgs use Einstein scoring to prioritise and an Agentforce agent to action the result.
How They Work Together in Practice
The either-or framing breaks down quickly once you look at a real workflow, so here’s what a combined setup actually looks like.
Take a renewals process. Einstein Opportunity Scoring runs against your historical closed-won data and flags which renewals are at risk. That’s a prediction, generated from a model trained on your own patterns, and no generative AI is involved. An Agentforce agent then picks up the flagged accounts, pulls the contract terms and recent support history through Data 360, drafts contextual outreach, and books a call with the account owner. When it needs to quote a revised price, a deterministic rule stops it from going below an approved floor without a human sign-off.
Three different technologies, three different jobs. Einstein did the ranking. Agentforce did the reasoning and the doing. The Einstein Trust Layer masked the customer data on the way to the model and logged the whole exchange for audit.
Now consider what happens if you rip Einstein out because you assume Agentforce replaced it. You lose the scoring model, which means the agent has no prioritisation signal and works through accounts in whatever order it encounters them. You’ve replaced a trained predictive model with a generative one guessing at the same question, which is both more expensive and less accurate. This is a real mistake teams make, and it comes directly from misreading the rename.
Einstein Bots vs Agentforce Service Agent
For service teams specifically, this is the comparison that matters most. The differences are structural rather than incremental.
| Einstein Bots | Agentforce Service Agent |
How it decides | Matches input to intents you mapped in advance | Reasons over the request and selects actions at runtime |
Handling the unexpected | Falls back or dead-ends when phrasing is unfamiliar | Attempts to work the problem, asks clarifying questions |
Multi-step requests | One dialog at a time along paths you built | Handles several outcomes in one continuous thread |
Maintenance | Retrain the NLU model, extend the dialog tree | Refine subagent scope and action descriptions |
Cost shape | Predictable regardless of conversation length | Consumption scales with reasoning loops and actions |
Best fit | High-volume, genuinely predictable questions | Varied requests needing real resolution, not deflection |
Note the cost row, because it cuts against the assumption that newer is always better. If your bot handles ten thousand identical password reset requests a month with a high containment rate, a scripted tree may genuinely be the cheaper and more predictable answer. The case for rebuilding gets strong when your conversations are varied, when customers phrase things unpredictably, or when you need the agent to actually resolve something rather than route it.
The Migrations That Are Real Rebuilds
Now the part that genuinely costs money and calendar time.
Einstein Bots to Agentforce
This is the one to take seriously. Einstein Bots and Agentforce share zero authoring objects. Your dialogs, your intent training set, your entity definitions and most of your conversation variables have nowhere to go in the new product. It isn’t an upgrade path. It’s a rebuild that happens to carry the same business requirement.
What makes it awkward for planning is the absence of a deadline. There is no published end-of-life date for Einstein Bots. Salesforce hasn’t filed a release update or sent the notifications it sends when something is genuinely going away.
Compare that to how Salesforce handles an actual retirement. Legacy Chat got a hard date published years in advance. Article Answers inside Einstein Bots got the same treatment at smaller scale, with support ending and a firm cutoff published well ahead.
Einstein Bots is getting neither a date nor meaningful investment. What it gets is maintenance, while engineering attention and release-note space move elsewhere. That’s harder to plan around than a deadline, because there’s nothing external to point at when a stakeholder asks why this quarter rather than next year.
Legacy Chat Is Already Gone
Legacy Chat, previously called Live Agent, retired on 14 February 2026. If you were still running embedded Live Chat windows, that decision was made for you. The replacement path runs through Messaging for In-App and Web, or Einstein Bots and Agentforce for Service for an AI-driven option.
What Got Easier in 2026
A genuinely useful improvement worth knowing about if a rebuild is on your roadmap.
Starting in API version 68.0, Salesforce streamlined Agentforce agent metadata types. Previously, moving an agent from sandbox to production required at least three metadata types, and you had to manually add every Apex class, flow and prompt template associated with an agent action while tracking the correct agent version. With the new AiAgentDefinition and AiAgentDefinitionVersion types, the Salesforce CLI now retrieves the agent and all its dependencies automatically.
If you evaluated an Agentforce rebuild earlier and stalled on deployment complexity, that objection is materially weaker now.
How to Sequence a Rebuild
If a rebuild is genuinely warranted, the order you do things in matters more than the tooling you use. A sequence that consistently works:
- Audit what your bot actually handles. Pull the real conversation logs, not the dialog tree. Most bots have a handful of intents carrying the overwhelming majority of volume, and a long tail that barely fires. You’re rebuilding the former, not all of it.
- Get Data 360 grounded before building agent logic. An agent reasoning over incomplete data produces confident wrong answers regardless of how well it’s scoped. This is the step teams skip and later blame the platform for.
- Design subagent boundaries so they don’t overlap. Misclassification is the most common production failure, and it traces directly back to fuzzy scoping at this stage.
- Write action descriptions for the model, not for colleagues. Atlas selects actions by reading descriptions. A vague label means a perfectly good action never gets used.
- Place deterministic rules around anything with financial, legal or compliance weight before building the flexible reasoning around it.
- Run both in parallel on a slice of traffic rather than cutting over. You get a real comparison on containment and cost before committing.
Running old and new side by side is worth the extra effort. It’s the only way to find out whether your consumption assumptions hold at real volume, and it gives you a genuine rollback rather than a theoretical one.
Measuring Whether the New One Is Better
A rebuild only makes sense if you can prove it worked, and the observability picture improved considerably in 2026.
Agent Analytics and Agent Optimization reached general availability in April 2026, covering the post-deployment half of the lifecycle that previously had far weaker tooling than the build side. Testing Center also moved into Agentforce Studio as a dedicated tab alongside the builder, with conversation-level testing that simulates full exchanges against user personas rather than checking single utterances in isolation.
One prerequisite catches teams out: Agentforce observability requires Data 360. If it isn’t provisioned, you’ll be running agents whose performance you can’t properly measure, which makes any before-and-after comparison against your old bot impossible to defend.
Worth knowing what the tooling doesn’t cover, too. Testing Center evaluates whether the agent picked the right subagent, the right action, and produced the right response. It doesn’t evaluate what happens inside your org after that action fires. Your existing automation still needs its own regression testing, because an agent can behave exactly as designed and still leave your org in a bad state if the Flow it triggered interacts badly with a trigger somebody wrote years ago.
So Do You Actually Need to Migrate?
Here’s the honest framing, which is less exciting than most vendor content on this topic.
You Can Stay Where You Are If
- You’re running the renamed agent and it does what you need. It works exactly as before, and nothing about the rename obligates you to change.
- You use Einstein predictive features like scoring, classification or Activity Capture. These aren’t going anywhere and are still being updated.
- Your Einstein Bots deployment has a containment rate you’re happy with and your use cases are genuinely simple and predictable.
- Your data foundation isn’t ready. An agent grounded in inconsistent data produces confident wrong answers no matter how well it reasons.
You Should Be Planning a Move If
- You need agents that execute end to end without a human approving each step
- Your bot regularly gets wrong-footed by phrasing nobody anticipated, which is the structural limit of a scripted decision tree
- You operate in a regulated environment where hybrid reasoning’s audit trail is now a genuine advantage over what was available before February 2026
- You need agents reaching systems beyond Salesforce, which is where Agentforce integration services come in
- You’re building something new, in which case starting on Agentforce rather than Einstein Bots is the sensible default
The rename signalled direction. It never meant existing Einstein users had to switch immediately, and most still shouldn’t rush.
What This Actually Costs
The pricing difference is where a lot of migration plans quietly fall apart, so it’s worth being direct about it.
Einstein features sit inside Sales Cloud and Service Cloud editions and add-ons. If you’re licensed for them, you’re already paying, and using them costs nothing extra.
Agentforce runs on entirely separate pricing with three models that can’t be mixed inside one org: pay per conversation, consumption-based Flex Credits, or per-user editions. Data 360 is billed separately again, and it’s the line most buyers don’t budget for until it appears mid-quote. We’ve broken the full picture down in our guide to Agentforce 360 and its editions.
One consequence specific to this comparison: an Einstein Bot conversation costs the same whether it takes two turns or twenty. An Agentforce conversation on consumption pricing does not. Reasoning loops consume actions, and a poorly scoped agent that loops more than it needs to costs real money on every single conversation, indefinitely. That’s an architecture decision that lands directly on an invoice, and it’s why agent design and consumption planning aren’t separate conversations.
A Warning About the Statistics You'll See
Search this topic and you’ll quickly hit a claim that something like 77% of Agentforce implementations fail because of data quality. It circulates widely and gets stated with real confidence.
It traces back to consultancies selling competing products, with no audited or named source behind it. Treat it as directional at best, and be suspicious of anyone quoting it at you without a citation.
The properly sourced numbers tell a more nuanced story. On the optimistic side, the Q2 FY27 figures at the top of this article are audited financial disclosures. On the cautious side, Gartner predicts that over 40% of agentic AI projects across the industry will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Gartner’s research also flags widespread “agent washing”, where existing chatbots and automation get rebranded as agentic without substantially changing.
Both of those are real, sourced and dated. Neither offers a magic failure percentage, and the honest read is that outcomes depend far more on data readiness and scoping than on which product you picked.
Sorting Out What You're Actually Licensed For
The rename created a practical problem that has nothing to do with technology: a lot of organisations genuinely aren’t sure what they’re paying for anymore.
Einstein features sit inside various Sales Cloud and Service Cloud editions and add-ons. Agentforce runs on separate pricing entirely. Data 360 is billed separately again. When labels change and bundles shift across two years of renames, it’s easy to end up paying for capability you already have, or budgeting for an upgrade you don’t need. The Winter ’27 default enablement makes this more pressing, not less.
VALiNTRY360 is a certified Salesforce partner, which means we can work through your existing entitlements with you and say plainly which side of the rename each one sits on. If your Einstein features already cover the use case, we’ll tell you that rather than sell you an upgrade. If moving genuinely makes sense, we’ll structure the licensing around your projected usage rather than around whichever model is easiest to sell, and flag the separately billed dependencies before they land late in a quote.
On delivery, we work across Agentforce consulting and implementation, including Agentforce for Sales and the Service side where most Einstein Bots rebuilds land. Examples of that work sit in our Salesforce case studies.
If you’re looking at a Setup menu wondering what changed and what didn’t, talk to our team. Half an hour usually settles it, and it’s a considerably cheaper way to find out than committing to a migration you didn’t need.
Key Takeaways
- The rename affected one thing: the Einstein Copilot for Salesforce agent type. Salesforce confirmed no functional change and no impact on existing implementations.
- Einstein predictive features are still live in 2026 and still receiving updates, including an Einstein Activity Capture change in August 2026.
- The Einstein Trust Layer kept its name and processes every Agentforce generative call, so the two products interlock rather than compete.
- Renames require nothing from you. Rebuilds do, and Einstein Bots to Agentforce is firmly a rebuild with no shared authoring objects.
- Legacy Chat retired on 14 February 2026. Einstein Bots still has no published end-of-life date at all.
- Hybrid reasoning, GA since February 2026, closed much of the predictability gap that made regulated teams hesitate.
- Claudeforce, announced August 2026, shows how far the agentic layer has moved from anything Einstein Copilot was.
- Winter ’27 enables Agentforce by default for licensed orgs, so governance review should happen before that lands.
The tidiest way to hold all of this: the rename was branding, and the rebuild list is architecture. Work out which category each of your Einstein products falls into and the path forward becomes considerably clearer than the marketing around it suggests.
FAQ’s
- Can I still buy Einstein features separately in 2026?
Einstein features are licensed inside Sales Cloud and Service Cloud editions and add-ons rather than sold as a standalone product. What you have access to depends on your edition and which Einstein add-ons are attached. - Does Agentforce need Einstein features to work?
Not the predictive ones. Agentforce depends on the Einstein Trust Layer and Data 360, but Einstein scoring and classification are optional. Many orgs run both because they complement each other rather than because one requires the other. - Will my Einstein Copilot custom actions work in Agentforce?
Yes. The rename preserved custom actions, permissions and integrations. Anything you built against the Einstein Copilot agent type continued working under the Agentforce label without modification. - Is Einstein GPT still a product name?
That branding has largely been absorbed. Generative capability now sits under Agentforce and Prompt Builder, while the Einstein name persists in the Trust Layer, Einstein Studio, and the predictive feature set. - Which is better for a small support team?
It depends on conversation variety, not team size. Predictable, repetitive questions suit a scripted bot economically. Varied requests needing genuine resolution justify Agentforce despite the consumption cost. - Do Einstein predictions feed into Agentforce agents?
They can. A common pattern uses Einstein scoring to prioritise records, then hands the ranked output to an agent that acts on it. The prediction and the action stay separate steps. - What happens to my Einstein Bots if I do nothing?
They keep running. There is no published end-of-life date and no forced migration. The risk is gradual stagnation as investment moves elsewhere, not sudden failure. - Is Claudeforce replacing the Atlas Reasoning Engine?
No. Claude becomes available as a reasoning model that works within Agentforce surfaces including Atlas. The execution architecture stays in place; the model choice underneath it expands. - Do I need Data 360 to use Einstein scoring?
No. Einstein predictive features train on CRM data directly. Data 360 is a requirement for Agentforce grounding and observability, which is a separate cost line from anything Einstein needs. - How do I tell which Einstein products my org actually has?
Check your Setup menu and your contract line items together. Edition-level features and paid add-ons look similar in the interface, so the entitlement document is the reliable source. - Can Agentforce and Einstein Bots run in the same org?
Yes, and running them in parallel on split traffic is a sensible way to compare containment and cost before committing to a full rebuild. - Does the Einstein Trust Layer cost extra with Agentforce?
It is part of the platform architecture rather than a separate purchase. Every generative call passes through it automatically, including masking, grounding and audit logging. - What should I review before Winter ’27 auto-enables Agentforce?
Your permission model and governance. Auto-enablement means the platform becomes available by default, so decide who can build and deploy agents before that setting disappears from Setup. - Is there a migration tool from Einstein Bots to Agentforce?
No. The products share no authoring objects, so dialogs, intents and entity definitions have no automated destination. Rebuilding is the only path. - Should I wait for the next release before deciding?
Waiting rarely helps unless a specific announced feature blocks you. The February 2026 hybrid reasoning release resolved most predictability concerns, so the current platform is a fair basis for a decision.