Agentforce on mobile: the built-in agent, the Mobile SDK, and the offline wall nobody warns you about

Ask two teams “can we get Agentforce on mobile?” and you’ll get two answers that sound the same and mean nothing alike. One team means: can our reps ask the agent things from the Salesforce app on their phone? The other means: can we embed our service agent inside the consumer app we ship to customers? Those are different products, different builds, different auth models, and, the part everyone skips, a shared constraint that decides whether a mobile agent is worth building at all.

We’ve written about nearly every channel an Agentforce agent can reach: the web snippet, WhatsApp and SMS, voice. Mobile is the one that splits cleanly into two paths, and picking the wrong one wastes a quarter. This post draws the line between them, walks the auth and offline realities of each, and names the wall you’ll hit regardless.

Path one: the built-in agent in the Salesforce mobile app

If your users are internal (reps, service agents, managers who already carry the Salesforce mobile app) the good news is almost anticlimactic. Agentforce is available in the Salesforce mobile app by default. There is no separate mobile agent to configure. The agent you built and grounded for the desktop experience is the agent your users get on their phone, through an Ask Agentforce entry point at the bottom of the app.

A user types a request into the Ask Agentforce box, or, after granting the app speech-recognition and microphone permission, taps the mic and speaks it. On iOS, Salesforce has wired the experience into native surfaces: Siri, Shortcuts, and widgets, so “ask the agent” doesn’t always require opening the app first. The summarize-this-account, draft-this-email, what-changed-on-this-opportunity motions all work from the same agent definition you already governed.

Because it’s the same agent, the governance is the same too. The agent runs as the agent user you configured, respects the same sharing and field-level security, and passes through the Einstein Trust Layer on mobile exactly as on the web. This is the whole appeal of path one: the security review you already did carries over. You are not standing up a new trust surface; you’re exposing an existing, governed agent through a client the user already has.

Two Summer ‘26 mobile updates are worth knowing because they change what “the agent on my phone” can do without you writing an app:

Actionable push notifications are generally available. A notification can now carry an action, not just a link, which is what lets an agent-driven alert become a one-tap approval or update instead of “open the app and go find the record.”
Agentforce Voice, now generally available, can be integrated into custom mobile apps through the Agentforce Mobile SDK, which is the bridge to path two.

If your audience is internal, stop here. Turning on the right notification types and confirming permissions is a configuration task, not a development project, and you’re done.

Path two: the Agentforce Mobile SDK, for the app you ship

Path one assumes your user has the Salesforce app. Your customers don’t. To put an agent inside your branded iOS, Android, or React Native app, the one on the App Store with your logo, you use the Agentforce Mobile SDK. This is a real engineering effort, and it’s a different animal from the built-in experience.

Salesforce publishes the SDK as open-source libraries (the AgentforceMobileSDK-iOS, -Android, and -ReactNative repositories on GitHub), and as of Summer ‘26, React Native is supported directly alongside native iOS and Android, which matters if your app is one codebase across platforms.

The SDK gives you two integration shapes, and the choice is architectural:

Full UI. You drop in the SDK’s prebuilt, customizable chat interface and get a working agent conversation quickly. Good when the agent is a feature bolted onto an existing app and you want it to look native without building a chat UI from scratch.
Headless (custom UI). You manage the conversation state and render your own interface, or drive the agent with no visible chat at all, as an agent-led background process. The SDK handles the AI logic; you own everything the user sees. This is the same headless philosophy as the Agentforce Agent API, and in fact the Mobile SDK is the mobile-native way to consume that platform rather than hand-rolling REST calls and token refresh yourself.

Under either shape, the agent can do what any Agentforce agent does: understand a request through natural-language understanding (text or voice), read grounded data, and execute Salesforce actions (create a record, update a field, run an Apex class) all through the same action layer you’d define for any channel. You still build and ground the agent in your org first; the SDK is a client onto it, not an agent authoring tool.

The auth model is where mobile SDK builds go wrong

The single most common mistake in an SDK integration is treating authentication as an afterthought. It’s the thing you have to design first, and it forks on who the user is.

The SDK doesn’t manage credentials itself. It delegates that to your app through a credential provider (on iOS, the AgentforceAuthCredentialProviding protocol), whose job is to hand the SDK a valid token for every call back to your org. Which token depends on the agent type:

Service Agent mode, for anonymous, customer-facing support. No user login required; the agent runs as a guest, the way a public web messaging agent does. This is what you use when a not-yet-authenticated app user needs help.
Employee Agent mode, for authenticated, internal use. The user must be signed in with a valid Salesforce OAuth 2.0 token, and the agent acts in that authenticated context.

The connection itself is brokered by a Salesforce external client app (the successor to the classic connected app), which is where you, and your admin, control the OAuth scopes, the allowed flows, and who can connect at all. Get the external client app and the credential provider right and the rest of the SDK is mechanical; get them wrong and you’ll burn days on 401s that look like SDK bugs and aren’t.

The SDK is a thin, well-behaved client. Ninety percent of a failed integration is the auth handshake: the external client app scopes, the token your credential provider returns, and whether the agent should run as a guest or an authenticated user. Design that before you write a line of UI.

Here’s the thing nobody puts on the slide. An autonomous agent needs the model, the model lives in the cloud, and the cloud needs a network. Every Agentforce agent, built-in or embedded, makes API calls back to your org to reason and act. No connectivity, no reasoning. There is no on-device model that lets the agent think on a plane or in a basement.

This is not a bug; it’s the shape of the technology, and it collides directly with the most compelling mobile use case: the field worker with no signal. Salesforce’s own answer for that world is offline-first data, not offline agents: the Field Service mobile app caches thousands of records for work without a connection, and the platform’s offline machinery (SmartStore for local storage, Mobile Sync for bidirectional sync, Briefcase Builder to define what gets cached) keeps data available offline. But those keep records readable and editable offline; they do not run inference. The agent’s conversational intelligence goes dark the moment the bars do.

The practical design rule that falls out of this:

Connected mobile work (a rep in an office, a customer on wifi) → an agent is a great fit on either path.
Genuinely disconnected field work → design offline data with the tools above, and let the agent light up when connectivity returns. Don’t promise a technician an agent that answers in a dead zone; you’ll be promising something the architecture can’t deliver.

Naming this early is the difference between a mobile agent project that ships and one that dies in a field pilot when the first “why doesn’t it work in the truck?” comes in.

What to do

Start by answering one question honestly: is your user internal or external? That single fork routes the whole project.

If internal, you almost certainly want path one: the built-in Ask Agentforce experience is already governed, already on your users’ phones, and needs configuration, not code. Confirm the agent is grounded and tested, turn on the notification types you want (actionable notifications are GA now. Use them), verify microphone and speech permissions for voice, and ship. Don’t build an app to do what the Salesforce app already does.

If external, you’re on path two with the Agentforce Mobile SDK, and the order of operations is: build and ground the agent in your org, stand up the external client app with tight OAuth scopes, decide Service Agent vs Employee Agent mode, implement the credential provider before the UI, then pick Full UI or headless based on how native the experience needs to feel. And whichever path you’re on, put the offline reality in front of stakeholders on day one so nobody sells a disconnected miracle.

If you’re deciding between the two paths, or you want the SDK auth handshake and the agent grounding designed so the mobile build doesn’t stall on 401s and empty answers, that’s the work we do, putting a governed agent where your users are, with an honest line around what it can do without a network.

Understanding the basics

Do I need to do anything to get Agentforce on the Salesforce mobile app?

No. Agentforce is available in the Salesforce mobile app by default: the agent you built for desktop appears through an Ask Agentforce entry point, and users can type or (with microphone and speech permission) speak to it. On iOS it also integrates with Siri, Shortcuts, and widgets. There’s no separate mobile agent to configure; the governance, agent user, and Trust Layer carry over from the agent you already built.

What’s the difference between the built-in mobile agent and the Agentforce Mobile SDK?

The built-in agent lives inside the Salesforce mobile app and is for internal users who already have that app, zero build. The Agentforce Mobile SDK is for embedding an agent inside your own branded iOS, Android, or React Native app, typically for customers who don’t have the Salesforce app. The SDK is a real engineering effort with its own auth model; the built-in agent is a configuration task.

How does authentication work in the Agentforce Mobile SDK?

The SDK delegates authentication to your app through a credential provider that supplies a valid token on each call. For anonymous customer support you use Service Agent mode (no login). For authenticated internal use you use Employee Agent mode, which requires a Salesforce OAuth 2.0 token. The connection is brokered by a Salesforce external client app, where scopes and access are controlled. Designing this correctly is the bulk of a successful integration.

Can an Agentforce agent work offline on mobile?

No. An agent needs to reach the model in the cloud to reason and act, so it requires network connectivity on any channel. Salesforce’s offline tools (SmartStore, Mobile Sync, Briefcase Builder, and the offline-first Field Service app) keep data available and editable without a connection, but they don’t run inference. For disconnected field work, design offline data access and let the agent resume when connectivity returns.

Putting a governed Agentforce agent in your users’ hands (the built-in mobile experience for your team, or an embedded SDK build for the app you ship) with the auth and the offline story designed deliberately? Talk to us. Drawing the line between the two paths and making the one you pick work is exactly what we do.