Salesforce Gave Its Agents a Runtime That Runs for Weeks

Salesforce announced a new portfolio of Agentforce agents in Dubai and Riyadh on October 5, and most of the coverage focused on the roster. Casey handles customer service across voice, SMS, WhatsApp and web chat. Paige resolves IT and HR requests. Carter helps shoppers compare products and check out in chat. Piper qualifies inbound leads. Marshall orchestrates back-office processes and keeps an audit record. Fin runs complex customer experience workflows. Hunter works outbound sales from research to outreach.

The roster is the least interesting part. What sits under it is a new long-horizon runtime that lets an agent pursue a goal across days and weeks rather than stopping at the end of a single interaction.

That is a different product category from the one enterprise AI has been selling.

The difference between answering and completing

A conversational assistant resolves a question and ends its turn. An agent on a long-horizon runtime takes an instruction, turns it into a measurable goal, builds a plan, and then works toward it while deciding which tasks to complete, which tools it needs, and where it has to pause for a human.

Salesforce's example is a seller telling Hunter to rescue at-risk deals before the end of the quarter. Hunter converts that into a plan and starts executing it, pausing for the seller's approval at defined points.

Three mechanisms make that possible. Memory preserves context and progress across sessions, so an agent picking up work on Monday knows what it did on Friday. Durable execution keeps a plan running and allows an agent to resume or adjust when circumstances change. Dynamic steering adapts behaviour based on feedback from an individual user.

That third one is where the design gets interesting. An agent running for weeks accumulates a lot of decisions, and most of them will be wrong in small ways. If the only feedback channel is a correction that resets the plan, the agent is not durable. Steering implies the agent adjusts its behaviour mid-flight rather than restarting.

The governance problem moves to the foreground

The longer an agent runs unattended, the more the accountability question matters.

Salesforce's answer is two-layered. Humans stay involved wherever approval or judgement is required, which is the conventional guardrail. Underneath it, Agent Script, an open source language for agent behaviour, lets a company combine AI reasoning with deterministic rules. The point is granular control over how an agent reaches a decision, so the parts that must follow policy can be written as policy rather than learned.

Everything runs inside the customer's existing permissions and business rules, and each agent carries the name the company gives it. The framing is that the agent becomes an extension of the brand, which is a marketing argument doing compliance work.

The audit record matters here too. Marshall is described as providing one for every action. For a process that spans weeks and touches several systems, an audit trail is the only way a human supervisor can review what happened without replaying the whole run.

The evidence Salesforce is pointing at

The company reports more than 7 billion agentic work units across Agentforce and Slack, including 3.2 billion in the most recent quarter. Specific customers get named: Perk, where 60 per cent of the sales pipeline is now built by its outbound agent; Autism Queensland, where 70 per cent of administrative requests are resolved by Paige; Hibbett AI, which went live in six weeks and now handles 90 per cent of core shopper journeys.

Hibbett is the number worth dwelling on. A retail deployment that reaches 90 per cent coverage of shopper journeys in six weeks is a claim about configuration speed, and configuration speed is where enterprise agent projects have historically died. Most of them stall in integration, not in capability.

The named customers are also chosen to make a point about the buyer. A pipeline-generation metric speaks to a sales leader. An administrative-request metric speaks to a public sector or healthcare buyer. The case studies are the segmentation.

Connected to the system of record, which is the real moat

The agents run against Customer 360, which means they operate with the customer context, data and business processes a company already has inside Salesforce.

That is a distribution advantage disguised as a technical detail. A competitor can build an agent that does outbound research. Building one that already knows the account history, the open opportunities and the support tickets is a different proposition, and it is not available to a vendor without the underlying records.

The trade-off is the familiar one. Whatever gains come from being close to the system of record come with a dependency on it, and a company that runs its sales agents on Agentforce has made its CRM choice more expensive to reverse.

How this differs from the other always-on agents

Salesforce is not the only company shipping agents that run without a prompt.

OpenAI's Dots operate continuously in the background against user-defined goals, connected to thousands of applications, with each agent running on its own private cloud computer. Meta's Muse agent takes a similar position. The shared idea is that the agent holds a goal rather than answering a question.

The difference in Salesforce's version is the starting surface. Dots begins with a goal and a set of connected applications. Agentforce begins with a customer record, a case, an opportunity or an order, because it is bound to Customer 360. That narrows what the agent can work on and deepens what it knows about it.

For enterprises, the narrow version is often the more useful one. A general agent that can touch anything is harder to authorise than a specific agent that works inside a system the company already governs. The permissions model is inherited rather than invented.

The pricing question underneath the persistence

An agent that holds a plan open for a month costs money in ways a request-response model does not.

Storage for the plan state, memory across sessions, monitoring for an agent that is supposed to alert when it needs approval, and the model calls themselves all accrue against a workflow that may or may not produce a result. A conversational assistant's cost is measured per exchange. An always-on agent's cost is measured per unit of time and per unit of work. Those two figures do not line up, which is why the named customers matter more than the feature list. Perk, Autism Queensland and Hibbett all describe outcomes that a finance team can already price: pipeline generated, administrative requests resolved, shopper journeys handled. An agent that replaces a known cost is easy to justify. An agent that creates a new category of cost is not.

What to watch

Three things will determine whether the long-horizon runtime is a product or a demo.

The first is failure behaviour at length. A plan that drifts over two months is harder to diagnose than one that fails in a session, and Salesforce has not described what happens when an agent pursues a goal it should have abandoned weeks earlier.

The second is whether Agent Script gets adopted outside Salesforce. An open source language for agent behaviour is only useful to a customer who stays on the platform. If it is portable, it becomes a standard. If not, it is a configuration format.

The third is the price of persistence. An agent holding a plan open for a month consumes storage, memory and monitoring, and none of that shows up in a per-token comparison. The unit economics of an always-on agent are not the unit economics of a request-response model, and Salesforce has not published which one it is charging for.

The framing the company is using, that these agents are judged by the work they complete rather than by the questions they answer, sets a higher bar than the industry has been held to. It also makes the measurement easy: either the at-risk deals closed or they did not.