Salesforce's named agents: when to turn on Casey and Fin, and when to build

Salesforce stopped calling them “the service agent” and started calling them Casey. At Dreamforce it named seven agents, gave each a job title, and put six of them on general availability. The branding is new. The question underneath it is the one you have always had to answer: turn on what ships, configure it, or build your own.

My answer, up front: a named agent is a configured template on the same Agentforce runtime you would build on yourself. Turning one on saves you the assembly, not the grounding, the guardrails, or the testing. So the name tells you what job Salesforce pre-scoped. It tells you nothing about whether it will work in your org. That still depends on your data and your process.

The seven, and what each one does

The roster maps to the functions Salesforce sells into. Six are generally available now. Hunter is in pilot.

• Casey handles customer service across voice, SMS, WhatsApp, and web chat.
• Fin takes the more complex support workflows across channels, the agent that arrived through the Intercom acquisition.
• Piper works websites and inboxes to qualify inbound sales leads.
• Hunter runs outbound sales, in pilot, and is the first to use the new long-horizon runtime.
• Carter helps online shoppers compare products and check out inside a chat.
• Paige takes employee IT and HR requests through Slack and internal portals.
• Marshall runs back-office supply chain work.

If those jobs sound familiar, they should. Each one is a use case this site already has a build guide for: inbound lead qualification is Piper’s job, the commerce shopping agent is Carter’s, the HR and IT service agent is Paige’s. The named agents are those patterns, pre-scoped and packaged so you configure instead of assemble.

What a named agent is

A named agent is not a different kind of software from the agent you build in Builder. It is one template: a predefined set of topics, actions, and instructions, running on the same Atlas reasoning loop, grounded through the same Data 360, governed by the same Trust Layer.

That has three consequences worth internalising before you turn one on.

It runs inside your rules. Salesforce is explicit that these agents operate within your existing business rules, permissions, and security. A named agent inherits the running user’s permissions the same way any agent does, so what it can see and do is bounded by the profile and permission sets you give it, not by its job title.

It still needs grounding. Casey does not know your return policy because it is called Casey. It knows your return policy if you ground it on your knowledge and connect the actions that read and write your records. The template supplies the shape of a service agent. You supply the substance.

It carries memory now. Salesforce is pairing these agents with longer memory across sessions, so the agent can pick up context weeks later rather than starting cold each conversation. Useful, and a thing to scope deliberately, because memory that persists is also data that persists.

Hunter and the long-horizon runtime

Hunter is the one to look at closely, and not because outbound sales is glamorous. Hunter is the first named agent on the long-horizon runtime, which pursues a goal across weeks instead of resolving a single chat and stopping.

The runtime is a different execution model, and it is why Hunter is still in pilot while the other six are GA. An agent that runs for a single conversation fails cheaply: the session ends, you inspect the transcript, you tune. An agent that runs a multi-week campaign can drift, repeat itself, or burn credits for days before anyone reads the outcome.

If you are tempted by Hunter, treat it as a different risk class from Casey. The observability you need for a long-running agent is not the same as for a chat agent, and the failure modes are slower and more expensive to catch.

The decision: turn on, configure, or build

The branding pushes you toward “turn it on.” Resist the reflex and run the actual decision. It has three outcomes.

Turn on the named agent when your process is close to standard. If your service desk resolves ordinary cases in ordinary ways, Casey configured against your knowledge and actions will get you to a working agent faster than building from an empty canvas. The template’s scoping is useful when your reality matches it.

Configure heavily, still starting from the named agent, when your process is standard in shape but specific in detail. Most orgs land here. You take Casey, then rewrite the topics that do not fit, add the actions the template lacks, and tighten the guardrails around the parts that touch money or PII. You are not building from scratch, but you are doing real engineering on top of the template, and you should budget for it.

Build your own when the job is not one of the seven, or when the seven’s scoping fights your process more than it helps. The build-versus-buy math does not change because the buy option now has a name. If your workflow is yours, a template shaped for the median org is a starting point you spend more time fighting than using.

A prebuilt agent removes the assembly, not the judgment. The work that makes an agent trustworthy is the work the template cannot do for you.

What the name does not change

Three things stay exactly as they were, and they are the three that decide whether any agent, named or not, is worth running.

Grounding quality still decides answer quality. A named agent grounded on thin or stale data hallucinates as confidently as a custom one. The Data 360 foundation is the work, and no roster of names shortcuts it.

Cost still runs on the same meter. A named agent consumes Flex Credits per action like any other agent, and a voice channel costs more per action than text. The name on the agent does not change the invoice. Usage does.

Testing is still yours to do. Turning on Casey does not mean Salesforce tested Casey against your org. Regression-test a named agent before launch and after every release the same way you would a custom one, with the Testing Center and your own adversarial cases.

What I would tell a team choosing today

The named agents are a good thing, on a fair reading. They lower the starting effort for the common cases, and a named catalogue makes it easier for a business stakeholder to point at what they want. That counts for something.

What they do not do is change the physics. An agent is only as good as its grounding, only as safe as its guardrails, and only as trusted as its testing record. A name and a job title do not supply any of those. They supply a head start on the one part, assembly, that was never the hard part.

So start from the named agent when your process fits it, because a head start is a head start. Then spend the time you saved on the parts the template left for you, because those are the parts that decide whether the agent ships or embarrasses you.

Understanding the basics

What are the Salesforce named agents?

They are seven prebuilt Agentforce agents Salesforce announced at Dreamforce 2026, each scoped to a business function: Casey (service), Fin (complex support), Piper (inbound leads), Hunter (outbound sales), Carter (commerce), Paige (IT and HR), and Marshall (supply chain). Six are generally available and Hunter is in pilot.

Are named agents different from building your own agent?

Not technically. A named agent is a template of topics, actions, and instructions on the same Agentforce runtime you build on. It runs inside your permissions, needs grounding on your data, and has to be tested like any agent. The template saves assembly time, not the grounding, guardrail, and testing work.

Which named agents are generally available?

Six are GA: Casey, Fin, Piper, Carter, Paige, and Marshall. Hunter, the outbound sales agent, is in pilot because it is the first to run on the long-horizon runtime that pursues goals over weeks rather than within a single session.

Do named agents cost extra?

They run on Agentforce and consume Flex Credits per action like any agent, with voice actions costing more than text. Salesforce did not announce a separate per-named-agent licence at launch, so budget them the way you budget any agent: by expected action volume and channel.

Before you turn one on

Decide how standard your process really is, because that single answer drives the whole choice. If it is close to standard, start from the named agent and spend your saved time on grounding and guardrails. If it is yours, a template will fight you. If you want a second read on which of your use cases fits a named agent and which should be built, talk to us, or run the Agentforce readiness assessment first.