Salesforce just shipped an agent that doesn’t live in Salesforce. Agentforce Coworker reasons in Slack, Microsoft Teams, ChatGPT, and Claude, with the Salesforce org acting as a data and action layer rather than the primary interface. That’s a real inversion of how Agentforce has been pitched since launch, and it forces a genuine agentforce coworker architecture assessment before anyone stands up a pilot.
The framing matters because most Agentforce deployments to date have been canvas-first: an embedded agent inside Experience Cloud, or a service console widget answering case questions. Coworker flips that. The Atlas Reasoning Engine now gets invoked from wherever the employee already works, and the org becomes one of several systems it can act against, not the home base it reasons from. That’s a bigger architectural shift than the release notes suggest.
Why Headless-First Changes the Deployment Calculus
In a canvas-first model, session state, topic scoping, and permission checks all resolve inside one governed boundary. The user is inside Salesforce, so Salesforce’s sharing model, field-level security, and session settings apply by default. Headless-first breaks that assumption immediately.
When a Coworker session originates in Slack, the identity resolving that user isn’t necessarily the Salesforce user record. It’s whatever identity provider federates Slack access, then maps to a Salesforce connected app, then resolves permissions inside the org. Every hop is a place where scope can leak or narrow incorrectly. Add Teams, ChatGPT, and Claude as additional entry points, and you now have four identity federation paths converging on one permission model that was designed with a single entry point in mind.
The architectural response has to be a strict separation between the reasoning layer and the execution layer. Atlas can reason across channels freely, that’s the product’s value proposition, but every Action it invokes against Salesforce data still has to pass through the same permission set, the same sharing rules, the same field-level security checks that would apply if a human user clicked the same button in the UI. If your org’s current Agentforce Actions were built assuming a single trusted entry point, they will not hold up under multi-channel invocation without a permission audit first.
How Cross-Channel Context Actually Gets Maintained
The harder problem is context continuity. A user starts a conversation in Teams, gets partial resolution on a case, then picks up the same thread in Slack an hour later. Does Coworker remember? The honest answer is that it depends entirely on how session state is persisted, and Salesforce’s current architecture leans on Data Cloud for that persistence rather than any channel-native session store.
This is where Data Streams and the Unified Individual model stop being a Data Cloud implementation detail and become the backbone of the entire cross-channel experience. If identity resolution isn’t cleanly matching the Slack user, the Teams user, and the Salesforce contact record to a single Unified Individual, Coworker has no reliable way to stitch that Teams conversation to the Slack follow-up. It will either lose context (frustrating the user) or worse, merge context across two people who happen to share an email domain (a governance failure, not just a UX one).
Data Graphs help here by pre-computing the joins Coworker needs at conversation time rather than forcing a live query across four channel logs and a CRM object graph on every turn. But Data Graphs only help if the underlying Identity Resolution ruleset was built with cross-channel matching in mind from day one. Orgs that configured Identity Resolution around email-and-phone matching for marketing segmentation are going to find that ruleset undershoots what a real-time coworker agent needs. Matching rules built for batch segment refresh and matching rules built for sub-second session continuity are not the same design problem, even though they use the same underlying feature.
Slack session --> Identity Provider --> Connected App --> Salesforce Permission Set
Teams session --> Identity Provider --> Connected App --> Salesforce Permission Set
ChatGPT/Claude --> External Services --> Salesforce Permission Set
\
--> Data Cloud (Unified Individual, Data Graph)
--> Atlas Reasoning Engine (context assembly)That diagram is the honest shape of a headless deployment. Reasoning happens centrally, but trust has to be re-established at every entry point, and context has to be assembled from a unified profile rather than assumed from a single-channel session.
Where Governance Breaks If You Skip the Permission Audit
Most orgs will treat Coworker as a configuration exercise: point it at Slack, point it at Teams, ship it. That’s the mistake. The governance model that worked for a single-canvas agent does not automatically extend to four entry points, and Salesforce’s own admin tooling won’t stop you from deploying it that way.
The specific failure pattern looks like this. A Topic scoped tightly for the Salesforce Experience Cloud use case (say, order status lookups for authenticated customers) gets exposed through Coworker’s Slack integration to an internal support channel where employees have broader implicit trust. Nobody re-scoped the Topic for the new channel because the Topic itself didn’t change, only the entry point did. Now an internal employee in Slack can trigger an Action that was never meant to be invoked outside an authenticated customer session, and the audit trail shows it as a legitimate Coworker action because, technically, it was.
The fix is to treat every new channel as a new deployment target requiring its own governance review, not an incremental extension of an existing one. That means:
- Permission set audit per channel: what does the Slack-federated identity actually resolve to in Salesforce, and is that mapping intentional or an artifact of whatever connected app configuration was fastest to set up
- Topic re-scoping per entry point: a Topic built for authenticated customer self-service should not be reachable from an internal collaboration tool without explicit re-authorization
- Data Graph review for cross-channel joins: confirm the Unified Individual model isn’t merging records across channels in ways that violate data minimization commitments, particularly relevant for GDPR-scoped EU deployments
- Testing Center coverage for multi-channel paths: Agentforce Testing Center scenarios written for a single-channel agent need channel-specific variants, because the same Topic can behave differently depending on which identity resolution path fed it
This is governance work, not configuration work, and it’s the same discipline gap that shows up in most Agentforce rollouts that stall after pilot. The Agentforce RGPD guidance for ETI-scale orgs covers the compliance dimension of exactly this kind of cross-system data flow, and it’s directly relevant here because Coworker multiplies the number of systems touching personal data by the number of channels you enable.
What This Means for Multi-Agent Orchestration Going Forward
Coworker isn’t a standalone feature, it’s a preview of where Agentforce orchestration is heading: multiple specialized agents, invoked from multiple channels, coordinated by a shared reasoning layer that has to reconcile context and permissions across all of them. The multi-agent orchestration patterns from TDX 2026 map the coordination layer this eventually requires, and Coworker is the first shipped instance of that pattern rather than a separate product line.
The organizations that will get this right are the ones treating the identity and Data Cloud layer as the foundation to build first, before enabling additional channels. The organizations that will struggle are the ones that see “Coworker works in Slack” as a checkbox feature to turn on, without asking whether their Identity Resolution ruleset, their Topic scoping, and their permission sets were ever designed to survive four simultaneous entry points. Org health assessments that focus purely on Salesforce configuration debt will miss this risk entirely, because the failure mode lives in the seams between systems, not inside any single one. A proper review here overlaps heavily with the kind of cross-system audit covered under org health recovery, because a permission model that quietly breaks under multi-channel load is a health issue long before it’s a feature request.
If you’re evaluating Coworker for Q3 or Q4 deployment, start with the permission audit and the Identity Resolution ruleset review before touching channel configuration. Everything downstream depends on getting that foundation right first.
Key Takeaways
- Agentforce Coworker separates the reasoning layer (Atlas, invoked from Slack, Teams, ChatGPT, Claude) from the execution layer (Salesforce Actions bound by existing permission sets), and that separation has to be enforced deliberately, not assumed.
- Cross-channel context continuity depends on Data Cloud’s Unified Individual model and Data Graphs, not channel-native session state, so Identity Resolution rulesets built for marketing segmentation likely won’t hold up for real-time coworker sessions.
- Treat every new channel as a distinct deployment target requiring its own Topic re-scoping and permission audit, rather than an incremental extension of an existing agent.
- If a Topic was scoped for authenticated customer self-service, exposing it through an internal collaboration channel without re-authorization creates a governance gap that standard audit logs won’t flag as anomalous.
- Coworker previews where multi-agent orchestration is heading industry-wide: the coordination discipline that works for one channel has to be redesigned, not copy-pasted, for four.
