Agentforce

Agentforce allows for you to run AI as agents natively and securely on the Salesforce platform without having to rely on potentially unsafe external sources for agentic actions.

Agent Force can be used on the Salesforce platform in an infinite number of ways. So to give a comprehensive list of potential ways that you could use agent force would be impossible. Instead I have linked to Salesforce's own set of example use cases:

Learn more about Agentforce use cases

Agents are essentially LLMs that can perform specific actions. This can be anything from responding to emails, alerting people of specific tasks that need to be done, creating transcriptions and sets of tasks from a call, getting specific information out of a large document and much, much more.

Beyond just the power of agent force, a big reason to use it is security. Instead of sending your data to some external system via API and being unsure whether or not AIs are training on your data, all of your data stays in Salesforce protected by the most secure platform.

Agent Force is compliant with every major business standard from SOC two to HIPAA and many other cybersecurity compliances.

Learn more about compliance

This makes things much easier from a compliance standpoint to utilize agent force for powerful agentic actions without having to get every step of the process audited and approved.

Your customer data, your business processes, your sharing rules, your audit history, and your team's daily work already live in Salesforce. Adding agents on the same platform extends that trust boundary by one step. Adding agents through a separate AI tool duplicates the trust decision, the compliance posture, and the security audit, then stitches the two systems together with API calls that pass sensitive data through a vendor whose certifications do not match Salesforce's.

Technical capability is rarely the constraint. The constraint is whether you want to take on a second set of trust decisions in exchange for what a separate tool offers.

Agentforce agents run as Salesforce users. They obey the same profile, the same permission sets, the same field-level security, the same record-level sharing, and the same validation rules that govern your humans. Scoping an agent to read-only access on a single object is one permission set change. Removing an agent's access to a field is the same workflow as removing a user's access to a field.

The answer to "what is this agent allowed to do?" has the same shape as "what is this user allowed to do?" Your administrators already know how to answer that question, your auditors already accept that answer, and your security team already trusts the tooling that enforces it.

External AI tools come and go. A vendor that looked promising six months ago may have changed pricing, deprecated the API you built on, or pivoted to a different market. Some of those vendors train their models on the data you send them, which means your customer information is potentially feeding a model that anyone else can query later.

Agentforce runs on the contract terms you have already negotiated, governed by the data handling promises Salesforce has already made, with the same change control discipline as the rest of your Salesforce org. You are not betting your customer data on a startup that may not exist in 2027.

Every prompt sent to an LLM by an Agentforce agent passes through the Einstein Trust Layer. The Trust Layer scans the outbound prompt for sensitive patterns before it ever leaves the platform. Social security numbers, credit card numbers, named PII, and similar regulated data are detected and masked at the platform level. The model never sees the raw value. When the response comes back, it passes through the same filter before reaching the user.

That means a curious agent, or a cleverly worded prompt, cannot accidentally leak a customer's SSN to an external model. The protection is enforced by Salesforce, not by whatever agent you happened to build, so the safety property holds regardless of which team configures which agent.

HIPAA, PCI-DSS, GDPR, and SOC 2 posture stays intact as you add agentic capability. Adding an agent does not require a new audit cycle. The platform itself is the audit boundary.

The reason to use agents at all is the speed and reach they add to your team. The reason to build them inside Salesforce is to get that speed and reach without giving up the control posture that made Salesforce the right system of record to begin with. Agentic systems are powerful. Security is what makes that power safe to actually use in production.

That is the blend Agentforce is designed to deliver: agentic capability that an enterprise can actually run, on a platform that an enterprise has already approved, with security guarding every outbound call.

We enjoy the challenge of finding the right place for Agentforce to fit inside a business. The fastest way to know what these agents can do for you is to put them next to your real workflows, your real data, and the problems your team has been working around for years. We are excited to run that discovery with you.

Discovery is where the interesting work starts. We want to hear about the problems that have felt too difficult to solve, the manual processes nobody on your team has time to clean up, and the places where your people spend hours on work an agent could handle in seconds. From there we map which of those problems Agentforce can take on, which are better solved by a different tool, and which become straightforward once a few of the other pieces are in place. Plenty of the mountains that looked extremely difficult to climb last year are routine summits with the right agentic tooling in front of them.

If you would like to see what we have already built on Agentforce, the related use cases and success stories below cover the ground we have already climbed with other clients.