Analysis10 min read

Agentforce’s long-horizon runtime changes what operators must test

Salesforce says Hunter can pursue goals for weeks, but remains in pilot. Buyers should test recovery, approvals, memory and stopping conditions before its planned November release.

Index Us / AnalysisIndependent AI intelligence

Salesforce has introduced seven named agents for sales, service, commerce, employee support and supply-chain work. Six are generally available now. The seventh, Hunter, is in pilot, with general availability planned for November 2026. Salesforce says Hunter is also the first agent to use its new long-horizon runtime.

The announcement was published at 12:00 UTC on 11 September 2026, according to the page’s article:published_time and structured metadata. Salesforce says the runtime gives Hunter memory across sessions, durable execution that can resume or change course, and dynamic steering from user feedback. Its example is a sales agent that works towards a goal over days and weeks, adjusting a plan as buyer information and priorities change.

The operational change is persistence across conversations. Such a system becomes part of an operating process: it must preserve state, decide when old approval still applies, avoid repeating external actions and stop when the goal or surrounding facts change. Salesforce has described those mechanisms, but the checked sources do not supply a product evaluation, reliability distribution or failure analysis for the new runtime. Index Us did not test Hunter or Agentforce.

A persistent goal crossing time checkpoints, approval gates and a durable resume loop A cobalt goal path travels through three off-white time checkpoints inside a charcoal frame. Vermilion approval gates interrupt the route, while a sage loop returns an interrupted task to an earlier checkpoint before it can continue. Fine grids, registration marks and a terminal stop block frame the conceptual control path.
Original illustrative graphic: a persistent goal crosses time checkpoints and approval gates, with a durable loop for resuming interrupted work. It is a control concept, not Salesforce’s runtime architecture, Hunter telemetry or evidence of product performance.

The launch contains two availability stories

Salesforce’s launch page lists Casey, Paige, Carter, Marshall, Piper and Fin as generally available. It lists Hunter as being in pilot, with general availability planned for November 2026. SiliconANGLE’s independent report confirms the shape of the launch and notes that the long-horizon runtime is limited to Hunter at launch, while attributing the capability details to Salesforce.

The job-agent portfolio and the new runtime are separate adoption decisions. A buyer can examine the six generally available agents against their bounded service, employee, shopping, supply-chain and customer-experience workflows now. Hunter is the appropriate place to test the claim that an agent can continue working towards an outcome over weeks and months. Salesforce says other agents will move to the runtime over time and that customers will eventually be able to build long-horizon agents themselves, but its announcement gives no dates for those extensions.

The Hunter product page sets out the intended boundary. Salesforce says Hunter ties goals, memory and actions to accounts, contacts and opportunities, rather than leaving state in a chat window. It says customer-facing actions such as outreach or proposals can require seller approval and that actions are logged. These design claims do not establish that state remains accurate, approvals remain appropriately scoped or every action can be reconstructed after a failure.

Persistence is not a reliability result

“Long horizon” has two different meanings in current agent discussions. Salesforce uses it to describe calendar persistence: an agent can retain a goal and resume work across sessions over days or weeks. Evaluation researchers use the term to measure task difficulty and reliability.

METR defines a task-completion time horizon as the human-expert task duration at which an agent is predicted to succeed at a stated reliability level. Its 50 per cent horizon is a difficulty measure, not the wall-clock time an agent stays active. METR also cautions that its suite is concentrated in self-contained, well-specified software, machine-learning and cybersecurity work. Real jobs often depend on tacit context, interactions with people and outcomes that cannot be scored automatically.

No checked source connects Hunter’s ability to persist for weeks with a measured probability of completing a sales objective correctly. The evidence supports a narrower conclusion: the runtime expands the period over which Agentforce can retain state and initiate or coordinate actions. Persistence alone does not establish that the underlying model makes better decisions, that each intermediate state is correct or that a business outcome was caused by the agent.

A pilot therefore needs to test more than the agent’s latest answer or proposed tool call. For a continuing agent, the state between turns matters: what was saved, what became stale, what external action actually occurred and which person or policy authorised the next step.

Persistence turns intermediate state into production data

Salesforce identifies memory, durable execution and dynamic steering as the three mechanisms under its new runtime. Those mechanisms create different failure boundaries.

Memory must preserve useful context without treating every earlier observation as permanently true. A buyer may change roles, an opportunity may close, a consent record may expire or a seller may correct a mistaken account note. OWASP’s Agentic Security Initiative describes retained context as an attack surface because poisoned or untrusted material can influence later reasoning and actions. For Hunter, a useful control would record the source, time and policy status of consequential facts, then force revalidation before customer-facing action.

Durable execution must resume from a known checkpoint. Network failures, delayed webhooks and worker restarts make “continue the plan” ambiguous unless each step has an identifier and an observed result. An outreach email sent before a crash must not be sent again merely because the agent’s local state missed the acknowledgement. The same applies to CRM updates, proposals and hand-offs. Idempotency, reconciliation and a human-readable event trail are more useful pilot evidence than a smooth end-to-end demonstration.

Dynamic steering must not quietly enlarge authority. A user’s feedback can improve the plan while still conflicting with organisation-wide policy, customer consent or a prior approval boundary. NIST’s concept work on software-agent identity and authority identifies identification, authorisation, auditing and non-repudiation as issues that enterprise agent deployments need to resolve. A long-running process should evaluate permissions again at the moment of action, not assume that the user and authority present at planning time remain valid weeks later.

Agent Script describes control, but the runtime enforces it

Salesforce presents Agent Script as the way to combine deterministic workflow rules with model reasoning. Its product documentation says builders can store variables, define logic, inspect traces and simulate behaviour before release. That can make control decisions reviewable and versioned, particularly when a team records which script governed each action.

The open-source material stops short of the execution runtime. The Agent Script repository contains the specification, parser, linter, compiler, language tooling and editor integrations under Apache 2.0. Its README says the execution runtime is not open source and that running agents requires Salesforce’s environment. The specification can show what an agent is intended to do; external inspection of the repository does not verify how the managed runtime schedules, recovers or enforces a weeks-long plan.

Salesforce’s language around guaranteed consistency and reduced failures remains a product claim. Deterministic branches can narrow choices, but they do not make input data current, external services reliable or a non-deterministic reasoning step correct. Stronger evidence would connect a script version, runtime trace and business-side effect in a reproducible test.

Use the pilot to test the joins

A Hunter pilot can produce useful evidence before the planned November release when it tests failure and recovery, as well as a successful journey.

  1. Define the terminal state. Give each goal a measurable outcome, deadline, stop condition and owner. Test whether the agent stops when the opportunity closes, consent changes or the expected value falls below a threshold.
  2. Interrupt every stage. Pause the runtime before and after research, plan changes, approval and external action. Confirm exactly which checkpoint resumes and whether completed steps remain completed.
  3. Age the context. Change account ownership, contact status, customer preference and policy while the plan is dormant. Measure whether Hunter detects the change before acting.
  4. Expire authority. Revoke a seller’s access, narrow a permission and withdraw an approval. Verify enforcement at action time, including through every connected channel.
  5. Force duplicate signals. Deliver the same webhook twice, delay an acknowledgement and make a downstream service time out after accepting a request. Confirm that the audit trail distinguishes retry, duplicate and completed action.
  6. Compare the alternative. Run the same cohort with existing workflow automation or seller-managed tasks. Measure qualified outcomes, manual review time, corrections, duplicate contacts, opt-outs and cost—not only agent activity.

Salesforce says it has delivered 7 billion Agentic Work Units across Agentforce and Slack, including 3.2 billion in its second quarter. It also says 60 per cent of Perk’s sales pipeline is built by Hunter. These are vendor-reported scale and customer-outcome claims. The launch page does not define Agentic Work Units or publish cohort details, baselines or a method that would let a buyer reproduce the reported figures, and the independent report does not validate them.

Buyers should request local, matched evidence: how many goals entered the pilot, how many reached a predefined terminal outcome, how often people intervened, what actions were reversed or duplicated, how long state remained dormant, which policy version applied and what the comparable non-agent workflow achieved. Averages should be accompanied by failure distributions, because a small number of stale or repeated customer actions can matter more than high routine completion.

For buyers, the launch creates two decisions. The six generally available agents can be assessed against their current workflows and controls. Hunter remains the evidence-gathering stage for the long-horizon runtime. Until Salesforce publishes fuller runtime and evaluation detail, operators should validate persistence as an expanded control surface before allowing it to become expanded authority.

This analysis is based on public announcements, product pages, documentation, source code and independent reporting. Index Us did not access Agentforce, Hunter, Salesforce customer environments or pilot telemetry, and did not independently verify Salesforce’s adoption, performance or customer-outcome claims.

Sources

  1. Salesforce — Agentforce job-ready agents announcement
  2. Salesforce — Hunter outbound sales agent
  3. Salesforce — Agent Script
  4. Salesforce — Agent Script repository
  5. SiliconANGLE — Salesforce introduces new AI agents
  6. METR — Task-completion time horizons
  7. OWASP — Memory is an attack surface
  8. NIST — Identity and authority of software agents

Last reviewed: . See our editorial policy for how we test, source and correct our work.