Somebody upstairs read about Agentforce (possibly our executive guide), and now it's on your roadmap. This post is the technical altitude: how the pieces fit, what the trust story actually covers, and the setup work that determines whether this becomes production infrastructure or an abandoned pilot.
Four layers, bottom to top. Your CRM data — the objects, fields, and files your org already runs on. Data 360 (formerly Data Cloud) — the unification layer that resolves identities across systems into single profiles and, increasingly, feeds AI unstructured content too; it can reference data in your warehouse without copying it. The AI layer — predictive Einstein models, generative features, and Agentforce agents running on Salesforce's reasoning engine. The surfaces — the clouds themselves, plus Slack, which Salesforce is positioning hard as the everyday interface where people and agents interact.
The key architectural fact: the AI layer reads through the platform's existing data model and — critically — its existing permission model. Which is both the best and the most dangerous thing about it, as we'll get to.
Every generative request in the platform passes through the Trust Layer. In practice it gives you: grounding (prompts are built from your CRM data, reducing hallucination), prompt-injection defense (system-level guardrails wrapped around every prompt, aligned to the OWASP Top 10 risks for LLM applications), data masking for generative features (pattern-, field-, and compliance-category-based masking of sensitive values before prompts leave for the model), zero-retention agreements with the LLM providers (your prompts and outputs aren't retained or used for training — a control that's independently validated in Salesforce's SOC 2 reporting), toxicity scoring, and an audit trail that lands in your own Data 360 instance, where you control retention and can report on it.
Two admin-grade controls worth knowing exist: geo-aware LLM routing (requests route to model instances near your region), and a model provider access switch — you can disable specific LLM providers org-wide if your compliance posture requires it.
The caveat almost nobody reads: data masking is currently disabled for Agentforce agent use cases. Salesforce is explicit about the reason — an agent planning multi-step work needs actual field values to act correctly (masked account details can't be matched, looked up, or acted on). Masking still applies to Einstein generative features and Prompt Builder templates. The practical consequence: for agents, your protection rests on permissions, guardrails, action design, and monitoring — not on masking. Design agent access accordingly.
For most security reviews, the Trust Layer cleanly answers the "is our data training someone's model" question — and that matters more than it sounds, because the realistic alternative isn't "no AI," it's employees pasting CRM data into consumer chatbots. Salesforce's own workforce research found over half of AI-using workers have used tools their employer banned or never approved. A sanctioned, governed path is the fix for shadow AI, not a nice-to-have.
What the Trust Layer does not cover: your own access model. AI features read what the running user can read — and an agent or Einstein Search answer will cheerfully surface data a user technically had access to but never would have found by clicking. If your org's sharing rules have accumulated a decade of "View All" exceptions, AI turns that quiet debt into visible exposure. Salesforce's shared-responsibility model is explicit here: permissions, credit tracking, and the trustworthiness of custom agent actions are your side of the line. A permissions review belongs before the rollout, not in the incident retro.
Prompt Builder turns one-off prompting into governed, reusable templates grounded in record data — it's where generative behavior becomes something you version rather than something users improvise. Agentforce Builder is where agents are defined: their topics, their instructions, the actions they're allowed to take (Flows, Apex, APIs), and their escalation rules. Salesforce's tooling now includes conversational agent-building and hybrid reasoning — deterministic steps where you need determinism, model reasoning where you don't.
The discipline that matters is boring and familiar: build in a sandbox, test against realistic utterances (the platform's agent testing tooling lets you batch-test how an agent responds before users do), define escalation paths explicitly, version your changes, and monitor in production — session tracing and agent analytics land in Data 360, so full session-by-session visibility is available if you turn it on. Teams that ship agents like they ship code do fine. Teams that treat the agent as a settings page get surprises.
Two consumption meters need owners from day one. Agent usage — Agentforce pricing is usage-based (per conversation, or per action via Flex Credits), so an enthusiastically adopted agent is a spend event; put consumption on a dashboard, set alerts at budget thresholds, and know the unit cost of your top use cases. Data 360 credits — unification, segmentation, and queries consume credits; a misconfigured refresh schedule can quietly burn a quarter's allocation. Neither is a reason to avoid the products; both are reasons to treat them like cloud infrastructure rather than seat licenses — because that's what they are now.
Deduplicate and standardize. Models and agents amplify whatever the data is. Dedupe contacts and accounts, fix the fields your use case reads, and kill the picklist chaos in anything AI will reason over.
Curate the knowledge base. For any service use case, the knowledge articles are the product. Stale or contradictory articles become confident wrong answers at scale. Prune before you pilot.
Review permissions and integration users. Least privilege for agent actions; a dedicated identity for anything an agent executes, so audit logs mean something. Remember: for agent use cases, permissions are doing the work masking does elsewhere.
Scope one pilot with one metric. Same advice we give executives, from your side of the table: a bounded process, a measurable number, an explicit rollback plan.
Stand up observability first. Decide what "working" means — resolution quality, escalation rate, consumption per outcome — and get the dashboards live before launch day, not after the first weird transcript. Enable the audit and feedback collection so the data exists when you need it.
Publish an internal AI policy. Salesforce's research says only about a fifth of workers report clear company policies on AI use. A one-page policy — what's sanctioned, what's banned, where data may and may not go — costs an afternoon and pre-empts your worst incident category.
Most of what determines whether Salesforce AI succeeds at your company isn't AI at all. It's the unglamorous platform work you already knew mattered: clean data, sane permissions, curated knowledge, tested automation, monitored consumption. AI just raises the stakes on all of it at once — and, usefully, it finally gives that work an executive sponsor.
If you want another set of hands on the readiness work — the data cleanup, the permission review, the pilot scoping — that's what we do all day for B2B companies on Salesforce and Account Engagement. Your end users have a version of this post too; it's shorter, and it tells them to feed the CRM. You're welcome.
Founder of Thompson Technology. Salesforce and Account Engagement consultant for B2B companies.
Connect on LinkedIn →Want an outside read on where your revenue engine is leaking? That’s a 30-minute conversation — no deck, no obligation.
