Agentforce Coworker: the AI teammate Salesforce is turning on in your search bar

Something new appeared next to the global search bar in a lot of Salesforce orgs this month, and most admins didn’t put it there. Starting August 4, 2026, on a rolling basis with the Winter ‘27 release, Salesforce began automatically enabling Agentforce Coworker for eligible customers: an AI teammate that answers work questions from your data and then hands the next step to an agent that does it. If you have the right entitlements, it’s likely already live for some of your users. That is a useful capability and a awkward way to receive one, and the combination is exactly why it’s worth understanding precisely rather than by the marketing line.

The marketing line is “AI in every search bar.” The real story is more specific and more interesting: Coworker is not another autonomous agent you build. It’s a conversational front door that sits over your grounded data and your existing agents, turns a search box into a question box, and orchestrates the handoff to whichever agent can take the action. Get that mental model right and everything else (where it runs, what it costs, how to govern it) falls into place. Get it wrong and you’ll either duplicate work you’ve already done or run up a credit bill you didn’t budget for.

What Coworker is

Ordinary Salesforce search takes a string and finds records: an account, an opportunity, a case, a contact. Coworker takes a question and returns an answer, grounded in the data the asking user is already permitted to see. Instead of searching for “Acme Corp” and clicking through three related lists, a rep asks “what’s the status of the Acme renewal and what’s blocking it?” and gets a synthesized answer drawn from the opportunity, its open cases, recent activities, and connected knowledge.

Three things make it different from the search box it replaces:

It reasons over structured and unstructured data. Not just CRM records: knowledge articles, files, and connected enterprise sources. Salesforce positions it as connected to your business “from day one,” meaning it grounds on what’s already in the org and its connected sources without a bespoke retrieval build.
It spans surfaces. The entry point in Salesforce is an Ask control next to global search, but Coworker is also surfaced in Slack and other supported tools, with a dedicated mobile experience. The idea is one conversational teammate that follows the user across where they work, not a widget bolted to one page.
It routes to action. This is the part that matters most. When the answer implies a next step (update the record, draft the follow-up, run a Flow, escalate a risk) Coworker doesn’t do it inline as a chatbot would. It routes the request to the right Agentforce agent, which executes through governed actions. Coworker is the interpreter and dispatcher; the agent is the hands.

That last point is the whole architecture in one sentence. Coworker is an orchestration and grounding layer on top of the agents you already build. If you’ve read our piece on multi-agent orchestration, think of Coworker as a supervisor-shaped entry point aimed at the employee using Salesforce, deciding which specialist should handle the request and passing structured context along.

Coworker vs. Assistant vs. Employee Agent: stop conflating them

Salesforce’s employee-facing AI now has several names that people use interchangeably and shouldn’t. They solve overlapping problems at different layers, and the distinction changes what you configure.

Agentforce Assistant is the in-context helper. What Einstein Copilot became. It lives inside a record or app view and helps you with the thing you’re currently looking at: summarize this case, draft this email, answer a question about this record. It’s assistive and scoped to the surface you’re on.

An Employee Agent is an autonomous agent you build and point at an internal audience: the kind that runs in Slack for your workforce, handling IT questions, HR requests, or a specific internal workflow end to end. You define its topics, actions, and guardrails. It’s a thing you construct for a defined job.

Agentforce Coworker is the layer above both. It’s not scoped to one record like the Assistant, and it’s not a single purpose-built agent like an Employee Agent. It’s the general conversational teammate that grounds broadly across your data and dispatches to the agents, including Employee Agents, that do the specialized work. You largely turn it on and grant it access rather than building it topic by topic.

The practical consequence: Coworker doesn’t replace the agents you’ve built. It fronts them. Every investment you’ve made in well-scoped topics, governed Apex and Flow actions, and grounding on Data 360 is what makes Coworker useful. A Coworker over a thin, ungoverned org is a nicer-looking search box. A Coworker over a well-grounded org with real agents behind it is a genuine productivity layer. The data foundation still decides everything.

The permission-set gotcha that decides whether it costs you money

Here is the single fact that will save someone a nasty invoice conversation: holding a qualifying license is not the same as having unmetered access. You can have the right license, use Coworker, and still consume credits, because unmetered access requires a permission-set assignment on top of the license, and the two are configured separately.

The billing model has two paths:

Unmetered (seat-based). Users on an Agentforce 1 edition, or on Agentforce for Sales, Service, or Industries licenses, get unmetered access to Coworker, their questions don’t draw down Flex Credits or Data Services Credits, provided the org is set up for unmetered user-based AI usage and the user carries the right permission-set license.
Metered (consumption). Absent that setup, Coworker usage is billed against Flex Credits or Data Services Credits like any other consumption.

The trap lives in the gap between those two. To be treated as unmetered for internal, user-context AI, both conditions must hold: the qualifying license and the unmetered user-based AI permission-set assignment. Miss the second and users with a perfectly valid Agentforce license still meter, every question spends credits. In a large org where Coworker just switched itself on for thousands of users, that gap is not a rounding error.

So the first governance task is not “should we allow Coworker”. It’s audit the entitlement wiring before usage ramps. Confirm which users are on qualifying licenses, confirm the unmetered permission-set license is assigned to exactly those users, and confirm nobody outside that set is generating metered traffic you didn’t plan for. This is the Coworker-era version of the discipline we laid out in the Flex Credit optimization playbook: the cheapest credit is the one you never spend because the seat was licensed unmetered in the first place.

Turning it on, and the enablement you control

Even where it auto-enables, an admin still owns the switch. The setup path is short:

Assign the admin permission set. Grant yourself the Agentforce Coworker Admin permission set; assigning it adds the permission-set license Coworker needs. Do this to a named admin, not broadly.
Open the setup surface. From Setup, in Quick Find enter Agentforce Coworker, choose Get Started with Agentforce Coworker, and use the side panel to Turn On (or off).
Assign end-user access deliberately. Grant Coworker access to the users you want on it, and, per the section above, make sure those are the same users who carry the unmetered permission-set license, so access and billing posture line up.

If you’d rather it not be on for a population (during a compliance review, for a regulated business unit, or simply until you’ve validated grounding quality) turning it off is the same surface. Because the rollout is automatic for eligible orgs, “do nothing” is a decision, not a default. Treat the auto-enable date as a deadline to have made an intentional call, not as Salesforce making the call for you.

For the permission and license assignment itself, drive it from source control like any other metadata rather than clicking it per user. A permission-set assignment through the CLI is the auditable path:

# Assign the Coworker admin permission set to a named admin user
sf org assign permset \
  --name AgentforceCoworkerAdmin \
  --target-org prod \
  --on-behalf-of [email protected]

And the assignment records themselves are queryable, which is how you prove, to yourself and to an auditor, exactly who has access and whether it maps to your unmetered population:

SELECT Assignee.Name, Assignee.Username, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.Name IN ('AgentforceCoworkerAdmin', 'YourUnmeteredAiPsl')
ORDER BY Assignee.Name

The reassuring part of Coworker’s design is that it answers from data the asking user is already permitted to see. It’s not a bypass; it rides on your sharing model, field-level security, and, for grounded records, the same access controls the rest of the platform enforces. That’s the right default, and it means Coworker’s answers are only as well-governed as the org underneath it.

Which is precisely the risk. Coworker makes it frictionless to ask broad questions across a lot of data at once, and that surfaces every latent access problem you’ve been getting away with. Over-shared records, a permission set that grants more than anyone intended, sensitive text sitting in a description field nobody thought an agent would read. None of that is created by Coworker, but all of it becomes visible and synthesizable the moment a natural-language layer sits on top. The failure mode isn’t Coworker leaking data it shouldn’t; it’s Coworker faithfully surfacing data your sharing model was already exposing, just less conveniently.

Two things follow. First, the agent-access governance work, making sure the agent (and now the conversational layer) sees only what the user is allowed to see, is not optional cleanup you’ll get to later; it’s the prerequisite for turning this on safely. Second, know what sensitive data lives in your free-text fields before a grounding layer starts reading them. Finding it is its own discipline; if you haven’t, that’s the reason to run a sensitive-data scan first, and Coworker is a good forcing function for finally doing it.

There’s also the agent-user question to keep straight. Coworker answers in the context of the human asking, but the actions it routes to run through your agents, which execute as a configured agent user with its own permissions. A rep can ask Coworker to update a record and have it refused not because the rep lacks access but because the downstream agent’s user does. When “why can’t Coworker do X” tickets arrive, that split, reader context vs. actor context, is the first place to look.

Be honest with your stakeholders about the shape of the value. Coworker is strong at retrieval and synthesis, pulling a coherent answer out of scattered records and documents, and at dispatch, getting a request to the agent that can act on it. It is not magic on top of a weak foundation.

It pays off when:

Your data is unified and grounded well, so synthesized answers are correct, the same Data 360 grounding that makes any agent good.
You already have real agents with governed actions behind it, so “route to an agent” leads somewhere.
Your sharing model is clean enough that broad questions return appropriate results.

It underwhelms when it’s fronting an org with thin data, no agents to dispatch to, and a messy sharing model, where it becomes a chattier search that occasionally says it can’t help. None of those are Coworker problems; they’re the pre-existing conditions Coworker makes legible. The upside is that the fix for an underwhelming Coworker is the same work that improves everything else: unify the data, govern the access, build the agents.

Takeaways

Coworker is a front door, not an agent. It grounds on your data, answers questions, and routes the next step to the Agentforce agents you already build. It fronts your agents; it doesn’t replace them.
Know your three layers. The Assistant helps in-context on one record; an Employee Agent is a purpose-built autonomous agent; Coworker is the general conversational teammate that dispatches to both.
Check the permission set, not just the license. Unmetered access needs the qualifying license and the unmetered user-based AI permission-set assignment. Miss the second and licensed users still burn credits.
Auto-enable makes “do nothing” a decision. Rolling enablement began August 4, 2026 for eligible orgs. Audit entitlements and access before usage ramps, and turn it off deliberately where you’re not ready.
It inherits your access model. Coworker answers from what the user can already see, which means it surfaces every latent sharing and sensitive-data problem. Clean up agent access first.

Coworker is the clearest signal yet of where Salesforce is taking the everyday experience: not a place you go to run reports, but a teammate you ask, sitting over agents that do the work. The teams who get value from it on day one aren’t the ones who turned it on fastest. They’re the ones whose data was already grounded, whose agents were already built, and whose access model was already honest. Coworker doesn’t create that foundation. It just makes very visible whether you have one.

Understanding the basics

What is Agentforce Coworker?

Agentforce Coworker is a conversational AI layer that replaces ordinary Salesforce search with a question-and-answer experience grounded in your data. Instead of searching for a record, users ask a work question and get a synthesized answer drawn from structured CRM data, unstructured content, and connected sources. Limited to what the asking user is already permitted to see. When the answer implies an action, Coworker routes the request to the appropriate Agentforce agent, which executes it through governed actions. It’s surfaced next to the global search bar in Salesforce and across other supported tools including Slack, with a dedicated mobile experience.

How is Agentforce Coworker different from an Agentforce agent?

An Agentforce agent is a purpose-built autonomous system you configure with specific topics, actions, and guardrails to do a defined job. Coworker is the layer above: a general conversational teammate that grounds broadly across your data, answers questions, and dispatches to your agents to take action. Coworker interprets and routes; the agent acts. You largely turn Coworker on and grant it access, whereas you build an agent topic by topic. Coworker fronts the agents you’ve built rather than replacing them.

Does Agentforce Coworker cost extra credits?

It depends on your entitlements. Users on an Agentforce 1 edition or on Agentforce for Sales, Service, or Industries licenses get unmetered access, but only if the org is configured for unmetered user-based AI usage and the user carries the correct unmetered permission-set license. Both conditions must be true. If the permission-set assignment is missing, even users with a qualifying license consume Flex Credits or Data Services Credits on every question. Audit the license-and-permission-set pairing before usage ramps.

Was Agentforce Coworker turned on automatically?

Yes, for eligible orgs. Beginning August 4, 2026, on a rolling basis with the Winter ‘27 release, Salesforce began automatically enabling Agentforce Coworker for customers with unmetered user-based AI entitlements. An admin still controls the switch, you can turn it off from the Agentforce Coworker setup surface, but because the rollout is automatic, choosing to leave it on (or off) is a decision to make deliberately rather than a default to ignore.

Coworker just made it obvious whether your org is ready for a conversational AI layer: grounded data, governed access, real agents behind it. If turning it on surfaced more questions than answers, that’s the foundation work. Talk to us. Getting the grounding and access model right is exactly what turns Coworker from a nicer search box into a teammate that ships work.