Agentforce's Seven Role-Specific Agents: Defining Permissions

On September 11, 2026, Salesforce introduced seven AI agents built for specific business functions — sales, customer service, internal support, and others. The agents are Casey, Paige, Carter, Marshall, Piper, Fin, and Hunter.

What caught our attention in this announcement was not the number of capabilities on offer, but the question it puts to the company adopting them: when you bring in agents organized by business function, what do you actually have to decide?

This article looks at how the seven agents are organized, and at the permission-design questions companies need to address when deploying these agents. Platform-wide capabilities such as AI Skills and multi-agent coordination are outside its scope.

What was announced: seven agents built for specific business functions

As Salesforce presents them, each agent is designed for a particular business function and supports specific channels.

• Casey (customer service): handles common questions, returns, and account management across voice, SMS, WhatsApp, and web chat
• Paige (IT and HR): handles employee service requests coming through Slack and internal portals
• Carter (shopping): supports product discovery and comparison through to checkout within the chat
• Marshall (supply chain): connects a sequence of back-office steps, automating manual work while leaving an audit trail
• Piper (inbound leads): engages prospects through websites and email, qualifies leads, and guides them to the next step in the sales process
• Fin (customer experience): handles complex customer workflows across channels
• Hunter (outbound sales): works alongside sales reps over time, from researching and prioritizing prospects through outreach, moving opportunities forward, and preparing proposals

Casey, Paige, Carter, Marshall, Piper, and Fin are generally available; Hunter is in pilot, with general availability planned for November 2026. (All of this is per Salesforce’s announcement as of September 11, 2026.)

Salesforce also says each agent can be tailored to a customer’s business — including giving it a name of the company’s own choosing.

What the announcement lays out, then, is a starting point: begin with an agent that matches a business function, then adapt it to how your company actually operates.

The runtime behind long-running tasks and customer examples

According to Salesforce, work that continues over a period of weeks is supported by three mechanisms: memory, which carries context and progress across sessions; persistent execution, which keeps working through a plan over time; and dynamic steering, which adjusts behavior in response to feedback from individual users.

Salesforce describes Hunter as the first agent to run on this long-horizon runtime. This should not be taken to mean that all seven use the same runtime.

Fin, for its part, is described by Salesforce as combining Operator — an agent for customer operations — with Fin Apex, a set of custom models trained for customer experience.

Among the customer examples Salesforce cites: at Anthropic, 79% of the conversations Fin sees are resolved autonomously; at the retailer Hibbett, 90% of core shopper journeys are handled by Hibbett AI.

These are figures Salesforce presents from its own customers, not measurements we have independently verified. They also speak to the results of adoption; they are not evidence that any particular permission design is sound. And the same capability can produce different outcomes depending on the work involved and how a company runs it.

The controls Salesforce describes

Before turning to permission design, it is worth being clear about what controls the product itself provides.

In this announcement, Salesforce states that every agent operates within the customer’s business rules, permission settings, and security controls.

It also points to Agent Script, an open-source language for describing agent behavior, which it says lets customers combine AI reasoning with deterministic rules for granular control over how agents make decisions and take action.

Salesforce’s official documentation goes further, framing Agentforce security as a shared responsibility model. Salesforce is responsible for securing the underlying platform and providing the trust layer. Customers are responsible for applying the principle of least privilege, configuring profiles, permission sets, and field-level security correctly, building guardrails that restrict the topics an agent handles and the actions it can take, and monitoring and auditing activity on an ongoing basis.

So the task facing a deploying company is not to build every control from scratch. It is to check whether the mechanisms provided, and the permission settings already in place, fit the work the company wants to hand over — and to make the necessary conditions concrete.

Match the work to the permissions you actually grant

From here on, this is our own reading.

What we take from this announcement is less about how many agents there are, and more about the need to align the tasks you delegate with the information an agent can access and the actions it can take.

Give a single agent several kinds of work, and you still need to think through permissions and approval conditions operation by operation. Conversely, separating agents by business function can serve as a way to keep each one’s permissions narrow.

In other words, dividing work up among agents is neither a burden in itself nor a guarantee of safety. The question is how you divide it, and how the pieces connect.

Worth noting here: the name of an agent’s business function does not determine the range of information it can actually reach.

Take employee HR questions. Whether the agent explains shared material such as an employee handbook, or is also trusted to look up an individual’s own records, changes what access it needs. In customer service, checking order status retrieves information, while issuing a refund or processing an exchange changes the transaction and may be harder to reverse.

In the way Salesforce’s documentation describes it, actual access follows from the permissions of the user an agent runs as and from the actions it has been allowed to take — not from the label on its domain.

Reuse the rules you already have where they apply; identify the conditions specific to a given workflow, and the handoffs involved when several agents or systems share one process. What needs designing is not the number of names, but the actual flow of work.

This is an extension of a theme we have written about before: not letting AI adoption end at the selection of software features, but carrying it through to the design of work and permissions.

At MIF, we believe AI adoption requires more than evaluating model performance. It also means defining the system’s business role, its permissions, its approval requirements, and how it will be operated.

Four things to settle before deployment

When bringing agents organized by business function into a company, we suggest working through the following four items for each workflow you plan to delegate.

The table is a starting point, not a prescribed set of settings. Adapt it to your operations in line with applicable laws, contracts, and internal policies, taking into account the impact and risk of the tasks involved.

What to consider	What to decide
Scope of data access	Under whose permissions does the agent operate, and what information can it read or update? Should access limits vary by user or by the data involved?
Permitted actions and approval requirements	Which actions may the agent take autonomously, and when is prior approval required? What mechanism enforces those requirements?
Human handoff, stopping rules, and responsibilities	When should the agent hand work over to a person? Who takes over, and who can stop or resume execution when needed?
Records and review	How will requests, referenced information, approvals, actions, and outcomes be recorded and traced? Who reviews the records, how long are they retained, and who can access them?

This table is not a transcription of any particular product’s configuration screen; it is a framework for thinking through the work itself.

Start by narrowing to one workflow, and separate the rules you can standardize from the conditions specific to it. Then map what you have decided onto actual permission settings, integration constraints, and approval flows — and confirm that operations you have not allowed are in fact refused.

Salesforce also describes configurable approval controls. Its product page for the outbound sales agent states that customer-facing actions, such as sending outreach messages or proposals, can be configured to require a sales representative’s approval before execution. A useful starting point is to check whether these settings can implement the approval requirements of your own workflows.

A practical caution: names do not define permissions

An agent’s name and stated role do not, by themselves, define what information it can access or which actions it is permitted to take.

As noted above, Salesforce says customers can give each agent a name of their own. Even when an agent’s name becomes familiar within the company, teams still need to check what information it can access and which actions it can take without human approval.

Our concern is that once phrases like “Casey handles that” or “Marshall processed it” become routine, it gets easy to feel the boundaries have been settled when they have not.

It also matters that, when something goes wrong, you can trace which agent acted, under which settings and using which information, and what it actually did. Where several agents or systems share a single process, the goal is to be able to follow the whole of it, handoffs included — not only the individual records.

Conclusion

Agents designed for specific business functions provide a useful starting point for deciding which tasks to delegate to AI. Their names and stated roles, however, do not by themselves define the access permissions and approval requirements a company needs.

At MIF, we focus on aligning delegated tasks with the information an agent can access, the actions it can take, the conditions for human handoff, and the records needed for review. Existing rules can be reused where appropriate, with task-specific requirements and cross-system handoffs made explicit.

A practical first step is to apply the four-item framework to one workflow, then check whether the resulting requirements are reflected in actual permission settings and approval processes.

For us, the announcement is a reminder that AI adoption should go beyond selecting software features to defining business roles, permissions, and operating procedures.

Sources and Verification

This article was prepared as of September 2026, drawing primarily on the Salesforce newsroom article published on September 11, 2026, with supplementary reference to Salesforce’s official documentation on Agentforce security (the shared responsibility model) and to the official product page for its outbound sales agent.

Availability (generally available or in pilot), planned release timing, and product capabilities and configuration options are all subject to change. For any adoption decision, please consult Salesforce’s current official information.

This article reviews published product information. MIF has not independently tested the agents’ behavior or security. The analysis of permission design and the four-item framework are MIF’s own.