Agentforce Assistant: what Einstein Copilot became, and when to use it instead of an autonomous agent

Every few weeks someone in a Salesforce org asks a version of the same question: “What happened to Einstein Copilot?” They enabled it a year ago, it summarized records and drafted emails from a panel in the corner of the screen, and now the Setup menu, the release notes, and the account team all say “Agentforce” instead. Did it get discontinued? Replaced? Is it the same thing as the autonomous agents in every keynote that deflect customer cases at 2 a.m.?

It wasn’t discontinued. It was renamed — twice — and quietly reclassified. The reactive, in-the-flow-of-work copilot that helps employees inside Salesforce is alive and well; Salesforce now markets it as the Agentforce Assistant, with the parenthetical “(Formerly Einstein Copilot)” doing a lot of quiet work. And it is a genuinely different animal from the autonomous Service Agent that handles your customers — different trigger, different identity, different risk profile — even though both are “Agentforce” and both run on the same reasoning engine.

That distinction is not pedantry. It decides which permission model you inherit, whose data the thing can see, what it costs, and whether a human is in the loop by design or by accident. This post untangles the naming, explains what the in-app Assistant actually is, and gives you the one architectural difference that tells you which to build. It’s the other half of the what-is-Agentforce explainer — the part that table quietly labels “the Copilot era” and moves past.

The naming, untangled

The confusion is earned, because Salesforce changed the label three times in about eighteen months. Here’s the lineage in plain terms:

• Einstein Copilot was the original in-app assistant, GA in 2024.
• In the Spring ‘25 release (API version 252), Salesforce renamed “Einstein Copilot for Salesforce” to “Agentforce” / “Agentforce (Default)” — explicitly no functional change, just the name and type in Setup.
• At Dreamforce in October 2025, the whole stack became Agentforce 360, with Data Cloud simultaneously renamed Data 360.

So far, so cosmetic. The part that trips people up is that the object got reclassified underneath the marketing. “Agentforce (Default)” — the renamed Copilot — is now legacy: as of June 17, 2025 it stopped receiving new features and can’t be created in new orgs. Salesforce’s guidance is to migrate to the Agentforce Employee Agent, which is the current, supported agent type for employee-facing, in-the-flow-of-work assistance — and the only type you can build for Slack.

Put the three current terms in a row, because this is the mental model to keep:

Term	What it actually refers to
Agentforce Assistant	Salesforce’s umbrella marketing term for the reactive, in-app copilot experience (formerly Einstein Copilot)
Agentforce (Default)	The legacy Setup object — the renamed Copilot. Being retired; don’t build new on it
Agentforce Employee Agent	The current, supported agent type you build today to deliver that assistant experience

When this post says “the Assistant,” it means the experience; when you go to build one now, the thing you configure is an Employee Agent. Anyone still saying “Einstein Copilot” is pointing at the same lineage.

What the in-app Assistant actually does

Strip the names and the Assistant is a copilot that lives inside the Salesforce UI and helps the human already sitting there. Out of the box it can summarize a record — an account, an opportunity, a case — draft and revise emails, find and update records, and answer questions from Knowledge. Beyond the standard actions, it can string together real work: it invokes a library of Actions built from Flows, Apex, prompt templates, and MuleSoft APIs, so “help me do X” becomes the agent actually doing X on the user’s behalf.

The defining property — the one that matters more than any feature — is this: the Assistant runs as the logged-in user. It sees exactly what that employee’s profile, permission sets, and sharing rules allow, no more and no less. Ask it to summarize an account the user can’t see and it can’t see it either. That’s not a limitation bolted on; it’s the whole security posture. The Assistant borrows the identity of the person using it.

Where it shows up follows from that. Because it’s tied to a logged-in employee, it surfaces where employees work: the Lightning Experience header and panel, the Salesforce mobile app, Field Service mobile, Sales Cloud Everywhere, and Slack. It is reactive by construction — it waits for a human to open it and ask.

The one architectural difference that decides everything

Here is the distinction that the shared “Agentforce” brand hides, and it’s the thing to get right before you build anything.

An autonomous Service Agent is event-triggered. An inbound message arrives, a case is created, a form is submitted — and the agent starts working with no human prompt and nobody logged in. To do that, it can’t borrow a person’s identity, because there’s no person there. So it runs as a dedicated agent user with its own permission set, its own record access, and its own entry in the audit trail — what practitioners describe as a digital employee with its own badge. That separate identity is exactly why an autonomous fleet needs the governance a human workforce needs: every agent user is a standing set of permissions that can act while you’re asleep.

The reactive Assistant is the mirror image. It’s user-invoked, so it does have a person to borrow from, and it inherits that person’s least privilege for free. The risk isn’t an over-provisioned autonomous identity acting unsupervised; it’s the subtler one below.

	Agentforce Assistant (reactive)	Autonomous Service Agent
Trigger	A human opens it and prompts it	An event or channel — no human prompt
Runs as	The logged-in employee’s identity and permissions	A dedicated agent user with its own permission set and audit trail
Primary user	Employees and reps inside Salesforce and Slack	Customers on external channels
Where it lives	Lightning header/panel, mobile, Field Service, Slack	Web/messaging chat, service channels
Human in the loop	Always — the human is driving	By design only where you build a gate
Under the hood	Topics + Actions + Atlas	Topics + Actions + Atlas

The buyer’s heuristic falls straight out of the table: if a human is present and asking, and you want the work bounded by that human’s permissions, build the Assistant (an Employee Agent). If the work should start on its own and run to completion as its own system identity, build an autonomous agent — and gate the consequential actions deliberately, because nothing else will.

Same brain, different driver

It’s worth being precise about what the two share, because it’s more than the brand. Both the reactive Assistant and the autonomous agent are built from the same primitives — Topics (which scope the instructions, guardrails, and available actions for a class of request) and Actions (the Flows, Apex, prompt templates, and APIs that do things) — and both are orchestrated by the same Atlas reasoning engine. Atlas classifies the request into a topic, plans, grounds against your data through retrieval, and invokes actions in a loop.

The practical consequence: everything you know about making Agentforce behave applies to both. Topic sprawl and overlapping instructions cause the same misclassification in an internal assistant that they cause in a customer agent — the Assistant routing a “summarize this” request to the wrong topic is the same failure as a service agent misrouting a refund. The difference between the two products isn’t a different AI. It’s who pulls the trigger and whose identity the work runs under. That’s the sentence to put on the whiteboard.

Setup, and the migration you can’t ignore

Enabling the Assistant is a short path with a long tail. The sequence: turn on Einstein, enable Agentforce, then either enable the legacy Agentforce (Default) agent or — the right move for any new work — create an Employee Agent. You build and tune it in Agentforce Studio / Agent Builder, adding standard actions and your own custom ones.

Access is permission-set-driven. For the legacy Default agent, Salesforce documents assigning Access Agentforce Default Agent plus Prompt Template User. The broader admin prerequisite that catches teams off guard is that Agentforce assumes a permission-set access model, not profiles — if your org still leans on profiles for everything, that cleanup is part of the project, not a footnote.

The migration is the part not to sleep on. If you’re on Agentforce (Default), Salesforce migrates you to an Employee Agent by copying configuration, permissions, and connected apps into the new agent with no downtime — and reverting is not recommended. Treat it like any other one-way platform migration: do it in a sandbox first, verify your topics and actions carried over, and confirm the surfaces (mobile, Slack) still behave before you flip production. “It renamed itself, surely the migration is automatic and safe” is how you find out in production that a custom action didn’t come across.

What it costs

Pricing is where the reactive-versus-autonomous split shows up on the invoice, and it’s genuinely favorable for internal use — but verify the current SKU wording, because Salesforce has iterated this fast.

Agentforce meters two ways that can’t be mixed in one org: Flex Credits or Conversations. Flex Credits price per action — roughly 20 credits (~$0.10) per standard action and 30 credits (~$0.15) per voice action, sold around $500 per 100,000 credits — while the Conversations model historically priced external customer chats at about $2 per conversation. The full pricing math is its own subject, and these numbers move; date-stamp any figure you put in a business case (these are mid-2026).

Two facts matter specifically for the internal Assistant. First, Salesforce’s higher Agentforce editions and add-ons can make employee-agent usage unmetered for licensed users — meaning the in-app Assistant your reps use all day need not burn per-action credits the way a customer-facing agent does. That flips the economics: the Assistant’s cost is often a per-user license question, not a per-action consumption question. (Confirm the exact SKU language for your contract — this is the part most worth reading twice.) Second, Salesforce Foundations hands Enterprise-and-above orgs 200,000 Flex Credits at no cost, which is the honest on-ramp to try the Assistant — and Agentforce generally — without a purchase order.

The gotchas that generate tickets

The Assistant’s great virtue — running as the user — is also its most common source of confusion, and it’s worth naming the failure modes:

• “Why can’t the Assistant see this?” Because the user can’t. Answers legitimately vary employee to employee, and a mis-scoped permission set shows up as the Assistant “not working” for one person and fine for another. When you triage an Assistant complaint, check the user’s access first, not the agent config.
• Grounding needs real data. The Assistant is only as good as what it can retrieve. Rich grounding on records, Knowledge, and unstructured content leans on Data 360; external systems (a non-Salesforce CRM, a ticketing tool) aren’t natively grounded and need an API or MuleSoft action to reach.
• Actions change the risk class. A copilot that only reads is low-stakes. The moment it can update records or fire a Flow, you’ve given it write authority under the user’s name — so which actions it can invoke without confirmation deserves the same scrutiny you’d give any automation, plus an awareness of prompt-injection if it ever reads untrusted text.
• Limits are documented — read them, don’t guess. Salesforce maintains a considerations page for agents; pull specific caps from it rather than trusting a round number from a blog. And ignore the scary “most implementations fail” statistics floating around vendor content — they’re unsourced.

When to reach for which

The clean way to decide, restated: the Assistant is for making a present human faster and keeping them bounded by their own permissions — summaries, drafting, record edits, “help me finish this.” The autonomous agent is for work that should happen without a human present, running as its own identity, at scale — customer deflection, 24/7 intake, end-to-end resolution. Many mature orgs run both: an Employee Agent helping the rep in the console, and a Service Agent handling the tier-one queue the rep no longer has to.

What you should not do is pick by which one had the flashier demo. The autonomous agent is the one on the keynote slide, but a huge share of real, defensible near-term value is the unglamorous internal Assistant that saves every rep ten minutes a case under permissions you already trust. Start where the risk is lowest and the identity model is already solved — and graduate to autonomy where the volume justifies standing up an agent with its own badge.

Understanding the basics

Is Einstein Copilot discontinued?

No. Einstein Copilot was renamed to “Agentforce” / “Agentforce (Default)” in the Spring ‘25 release with no functional change, and is marketed today as the Agentforce Assistant. The underlying Setup object, “Agentforce (Default),” is now legacy — it stopped getting new features on June 17, 2025 and can’t be created in new orgs — and Salesforce migrates it to the current supported type, the Agentforce Employee Agent. So the capability lives on; only the names and the object classification changed.

What’s the difference between the Agentforce Assistant and an autonomous agent?

Trigger and identity. The Assistant is reactive — a human opens it and prompts it — and it runs as that logged-in user, inheriting their exact permissions. An autonomous agent is event-triggered, starts work with no human present, and runs as a dedicated agent user with its own permission set and audit trail. Both are built from the same Topics, Actions, and Atlas reasoning engine; the difference is who pulls the trigger and whose identity the work runs under.

Does the internal Agentforce Assistant consume Flex Credits?

It can, but often it doesn’t have to. Agentforce meters either by Flex Credits (per action) or by Conversations (per external chat), and the two can’t be mixed in one org. Salesforce’s higher editions and add-ons can make employee-agent usage unmetered for licensed users, turning the internal Assistant into a per-user license cost rather than a per-action consumption cost. Salesforce Foundations also includes 200,000 free Flex Credits to start. Confirm the exact SKU terms for your contract, since Agentforce pricing has changed repeatedly.

---

Trying to work out whether you need the in-app Assistant, an autonomous agent, or both — and how to migrate off Agentforce (Default) without breaking a custom action? Talk to us — sorting the reactive-versus-autonomous decision before you build is the Agentforce work we do.