Salesforce Agentforce is the right agent inside Salesforce. Nimbus is for work that also involves Drive, legal, and finance — with a lasting record of who signed off.

Nimbus will call Salesforce. It does not try to be Salesforce. That is the point. CRM platforms that pretend to be the only operating layer become unmaintainable outside the org. Operating layers that pretend to be CRM become untrustworthy on pipeline. Customer and pipeline truth live in Salesforce. Cross-department jobs that also live in Drive and legal email need a place that is not only field history on the opportunity.

Agentforce (including Agentforce 360) is Salesforce’s agent product family sitting on Sales, Service, Marketing, Commerce, and related clouds. The 2026 shape that matters to operators: a reasoning engine that can follow scripted, reliable steps and call a model only where judgment is required; a builder where admins put conditionals and hand-offs in a readable script, not only in a prompt; Data 360 (formerly Data Cloud) as the profile fabric; and actions that update records, launch flows, call APIs, and behave the way your industry cloud already behaves. Model choice inside Salesforce is expanding (OpenAI, Anthropic on Amazon’s cloud, Google’s Gemini among options). Service-grade voice and channels come with Salesforce-shaped auditability. The buyer is usually the Salesforce platform owner, RevOps, or customer service.

Words you’ll hear

Agentforce / Agentforce 360. Salesforce’s agent product family sitting on Sales, Service, Marketing, Commerce, and related clouds.
Data 360. Formerly Data Cloud. The layer that unifies customer profiles and unstructured context inside Salesforce.
Einstein Trust Layer. Grounding in CRM data, masking of sensitive fields, toxicity detection, an audit trail, and zero data retention with LLM partners. CRM-native trust. Not a company-wide work ledger.
Workstream. In Nimbus, a shared workspace for one job that can include Drive, legal, and finance on the same canvas as CRM.
Wiki. Official playbooks — including when a discount is an exception.
Write-back. Changing a live system. Writes to Salesforce are first-class in Agentforce. In Nimbus they are not default-on. They are gated, quoted, and recorded.
Lifecycle Graph. A lasting record of the programme, not only the field history on the opportunity.
Agent graph (Agentforce). A reasoning map for a turn. Not the same as Nimbus’s operational ledger.

Why the difference matters

Success looks like: a service agent resolves a case, a sales agent updates opportunity fields, a flow still fires, the admin can preview what the agent did on the record. Grounding is strongest where Data 360 and the org are clean. It is weakest where the work is not a Salesforce object. Trust inside that org is the Einstein Trust Layer. Salesforce’s Trusted AI pages and the Trailhead Trust Layer module describe the same stack: grounding in CRM data, masking of sensitive fields, toxicity detection, an audit trail, and zero data retention with LLM partners. That is CRM-native trust. It is not a company-wide work ledger.

Two jobs get conflated in every Agentforce demo.

Update the next step on the opportunity. Agentforce is the native answer. A sales agent with actions on Opportunity, maybe a flow, maybe a Slack ping via Salesforce. Ideal if the work already lives in Salesforce. Writes to Salesforce are first-class. Sharing rules are the permission model. That is the product working as designed.

Write the pricing-exception memo, involve legal, update CRM, and file what happened. You can script pieces in Agentforce. Legal, Drive, and the memo are someone else’s system unless you pipe everything into Data 360. In Nimbus, this is a workstream: connector scopes, a person on the write, Salesforce still the official home of the opportunity, Nimbus the place the cross-department job ran. The Trust Layer is how Salesforce keeps CRM data from leaking into LLM partners and how it logs prompts, toxicity scores, and user feedback on the record. A pricing exception that also lives in Drive and legal email is a cross-function workflow. Do not ask the Trust Layer to be the memo, the legal comment, and the named signer outside the org.

A healthy split:

Customer and pipeline truth live in Salesforce (plus Data 360 if you have paid for unification).
Agentforce handles in-CRM actions where Salesforce sharing rules are the product.
Nimbus agents read Salesforce under connector scope, operate across the rest of the stack, and write back only through governance.

Skipping (1) and asking any operating layer to “just know ARR” is how you ship two pipelines. Dual write without a field-level policy is how you get sync fights. Default: Agentforce for interactive, in-CRM actions; Nimbus for batched, cross-system, approval-heavy programmes. Read-only Nimbus plus Agentforce writes is a valid starting posture. Agree the fields.

Role by role: a Salesforce platform owner, RevOps, or customer-service lead wants an agent on a Salesforce object — Agentforce is the fit, including service voice and in-app sales agents. Legal and finance sitting on a pricing exception need a canvas that is not only the org. Security will like the Trust Layer for CRM data and LLM partners, and still want a ledger of releases that is not only field history. A CIO who already paid for Einstein or Agentforce credits should use Agentforce where it is strong, not stretch it into an operating layer because the credits are sunk. Credits on CRM turns do not buy you model choice across the rest of the business, or a graph of non-CRM decisions. See models.

Both mention graphs. They are not the same. Agentforce’s agent graph is a reasoning map for a turn. Nimbus’s Lifecycle Graph is an operational ledger of work, agents, and releases. Collapsing the terms is how you buy a CRM agent and think you bought institutional memory.

When Agentforce is a better fit

Choose Agentforce when the job is an agent on a Salesforce object, sharing rules are the permission model you need, and Data 360 is (or will be) the profile fabric. Choose it for service voice, in-app sales agents, and any workflow that should never leave the org.

Do not choose Agentforce as a stealth company operating layer. You will spend a year on Data 360 and agent scripts and still lack workstreams for everything that is not a Salesforce record.

Some organisations will run both. That is coherent if you do not pretend Agentforce’s turn-by-turn reasoning graph is a Lifecycle Graph. Attach Salesforce as a connector, keep Nimbus read-only at first, open writes through governance where the programme is batched and cross-system. Agentforce plus Data 360 is the Salesforce-platform path. They can coexist.

How this shows up in Nimbus

Nimbus’s knowledge is wiki plus connectors plus Lifecycle Graph. Wiki is how we run the business. Connectors are live systems — Salesforce is one of them, not the universe. The graph is what we decided after we saw the account.

You can set Nimbus up yourselves and attach Salesforce as a connector. Agentforce at scale is a Salesforce implementation: Data 360, sharing, agent scripts, often a partner. That is rational inside CRM. It is not how you stand up cross-company AI work. You do not need a Salesforce consulting partner to use Nimbus with Salesforce. Attach it, keep it read-only, open writes through governance.

See workstreams and the Lifecycle Graph.

Questions people actually ask

Does Nimbus replace Agentforce?

Not inside Salesforce-native service and sales motions. Nimbus can read and update Salesforce through governed connectors. It should not be the official home of opportunities and cases.

Does Agentforce replace Nimbus?

Not as a place departments finish cross-system work. You can script impressive agents in the builder. You still need a company wiki, specialist teams for non-CRM work, and a ledger of releases that is not only field history.

Do we need a Salesforce consulting partner to use Nimbus with Salesforce?

No. Attach Salesforce as a connector, keep it read-only, open writes through governance. That is the self-service path. Agentforce plus Data 360 is the Salesforce-platform path. They can coexist.

Both mention graphs. Are they the same?

No. Agentforce’s agent graph is a reasoning map for a turn. Nimbus’s Lifecycle Graph is an operational ledger of work, agents, and releases. Collapsing the terms is how you buy a CRM agent and think you bought institutional memory.

Should Nimbus write to Salesforce, or should Agentforce?

Default: Agentforce for interactive, in-CRM actions; Nimbus for batched, cross-system, approval-heavy programmes. Agree the fields. Start read-only on the Nimbus side if you need a clean split.

We already paid for Einstein / Agentforce credits. Why add Nimbus?

Because credits on CRM turns do not buy you model choice across the rest of the business, or a graph of non-CRM decisions. Sunk cost on Agentforce is a reason to use Agentforce where it is strong, not a reason to stretch it into an operating layer. See models.

Who owns Agentforce vs Nimbus?

The Salesforce platform owner, RevOps, or customer service typically own Agentforce: sharing rules, Data 360, agent scripts. Line operators outside the org — legal, finance, teams living in Drive — own Nimbus workstreams for those jobs. Security reviews the Trust Layer and Nimbus write gates. Do not give one “CRM AI” owner both products and expect them to notice the job split.

Can we start with read-only Nimbus and Agentforce writes?

Yes. That is a valid starting posture. Salesforce remains the system of record for the opportunity. Nimbus reads under connector scope. Writes that are interactive and in-CRM stay in Agentforce. Promote Nimbus writes later only where the programme is batched, cross-system, and approval-heavy — and only after you agree the fields.

What is write-back governance, What is a lifecycle graph, and What is human-in-the-loop AI.

Nimbus vs Salesforce Agentforce: The Right Agent Inside Salesforce, or Work Across the Company?