Agentforce
Agentforce's long-horizon runtime: building an agent that works a goal for weeks
Salesforce's new long-horizon runtime lets an Agentforce agent pursue a goal over days and weeks instead of a single chat, and Hunter is the first to run on it. A long-horizon agent isn't a longer conversation. It's a durable plan with checkpoints and an approval boundary, and that changes what you design, test, and watch.
Ask a service agent to close a case and it does the whole job in one turn. Ask it to rescue every at-risk renewal before the quarter ends and, until this month, you couldn’t. The conversation ended, and the work ended with it. An Agentforce agent was a thing you talked to, not a thing that kept working after you closed the tab.
On September 11, 2026, Salesforce announced a long-horizon runtime that changes that, along with a portfolio of named agents. Hunter, its outbound sales agent, is the first to run on it. Salesforce describes the runtime as letting an agent pursue a goal over days and weeks rather than a single session.
Start from this mental model: a long-horizon agent isn’t a longer conversation. It’s a durable plan the platform keeps alive when nobody is watching, with checkpoints it can resume from and an approval boundary that decides where it stops and asks.
Get that framing right and the design work is clear. Treat it as a chat that happens to run longer and you’ll ship an agent that either does nothing between prompts or does far too much.
What Salesforce announced
Cut past the naming and the runtime rests on three capabilities, all named in the announcement.
Memory preserves context and progress across sessions, so the work doesn’t reset when an interaction ends. Durable execution keeps a plan running over time and lets the agent resume or course-correct as circumstances change. Dynamic steering lets the agent adjust its behaviour in response to a person’s feedback while the work is underway.
The example Salesforce gives is concrete. A seller asks Hunter to rescue their at-risk deals before end of quarter. Hunter turns that objective into a measurable goal, builds a plan, and works out the tasks, tools, and context it needs.
Around that plan sit guardrails that define when it can act on its own and when it needs the seller’s approval. As new information arrives, it revises the plan and keeps the seller in control.
One detail decides your timeline. Most of the named agents are generally available now, but Hunter, the one that showcases this runtime, is in pilot with a GA target of November 2026. The runtime is real and announced; the flagship agent on it is not something you deploy this week. Plan against the pilot, not the press release.
Why “just run it longer” was never the hard part
The instinct is to think the barrier was a time limit, as if an agent could always have worked a goal for a week and Salesforce just had to raise a timeout. That’s not it. Three real problems sit between a single-turn agent and one that works for a week, and the runtime answers all three.
The first is state. A model is stateless between calls, and everything it “knows” in a turn was handed to it that turn, competing for room inside a fixed token budget. You cannot keep a week of work in the prompt. It won’t fit, and even if it did the signal would drown. A long-horizon agent needs durable memory that lives outside the context window and gets read back in slices.
The second is failure. A week-long process will be interrupted: a callout times out, a record is locked, an approval sits unanswered overnight, the container recycles. A conversation that dies mid-turn just fails. A durable process has to survive the interruption and pick up where it left off, without redoing work it finished or, worse, repeating an action that already had a side effect. That property has a name in distributed systems, durable execution, and it’s the unglamorous core of the whole thing.
The third is control. An agent you talk to is governed turn by turn, because you’re right there. An agent that acts for a week while you’re in meetings needs its autonomy decided in advance: which actions it may take alone, and which ones stop and wait for a person. That boundary is the difference between an agent that saves a quarter and one that emails four hundred customers a mistake over a weekend.
Durable memory is a data layer, not a bigger prompt
Salesforce’s engineering team wrote up the agentic memory work behind this, and the design tells you how to build on it.
Memory here is structured data, not a transcript. Memories are written to a standard memory object with explicit fields for type, time, source, confidence, and lifecycle, and they come from more than conversations: an agent turn, a bot, a human exchange, or a document.
The part that matters for a builder is what governs writes. Salesforce describes write gates that let only high-quality candidates become memory, confidence scoring on each one, and validation before it’s trusted, so the store doesn’t fill with the agent’s own guesses.
So memory is a thing you design, not a thing you hope for. Decide what Hunter should remember across a two-week rescue: the objection a champion raised, the discount already floated, the fact that legal is the real blocker. Each of those is a candidate memory with a source and a confidence.
The quality of the rescue depends on the store holding the true ones and dropping the noise. This is the durable version of the problem in why your agent forgets. The old answer was to carry the two or three facts that must survive in variables. The runtime’s answer is a governed memory layer, which is a real upgrade and a real responsibility.
Durable execution is the part that will surprise your team
If you’ve built with triggered agents you already know an agent can act without a prompt. Durable execution is a different guarantee: the promise that a long plan keeps its place across failures and restarts.
The pattern, industry-wide, is checkpointing. The runtime records progress at steps along the plan so that after an interruption it resumes from the last good checkpoint instead of the beginning.
That forces a property on every action the agent calls: the action has to be safe to retry. Say the step “send the renewal quote” runs, the process crashes before it records success, and the runtime retries the step. You do not want two quotes going out. In distributed-systems terms the action needs to be idempotent, or guarded so a repeat is a no-op.
Salesforce hasn’t published the checkpoint internals, and I won’t invent them. What I can tell you is what to design for regardless. Every custom action a long-horizon agent can call should assume it may run more than once.
A custom Apex action that creates a record should check for an existing one first, or key the write on an idempotency token, rather than blindly inserting. This is ordinary defensive engineering, and it’s exactly the discipline that gets skipped when an action is written for a chat agent that calls it once. Retrofitting it after a resumed plan double-charges a customer is the expensive way to learn it.
The other half of durable execution is deterministic control. Salesforce paired this runtime with Agent Script, its open language that mixes model reasoning with deterministic rules, and that pairing isn’t a coincidence.
You do not want a week-long, high-stakes process improvised freshly on every step. You want reasoning where judgment helps and hard rules where it doesn’t, so the plan’s spine is predictable and only the leaves are probabilistic. For a rescue playbook with compliance implications, that’s the difference between a process you can test and one you can only hope about.
The autonomy boundary is your real design surface
Everything above is plumbing. The decision that shapes the agent is where you draw the line between what it does alone and what it brings to a person.
We’ve argued that full autonomy is the wrong default for any action that’s hard to reverse. A long-horizon agent sharpens that, because it acts while you’re not looking. The method is the same: classify each action by blast radius and reversibility.
Drafting an email, updating a private note, building a call list, these are cheap and reversible, so let the agent do them. Sending an external message, offering a discount, changing a close date the forecast rolls up, these are consequential, so they stop at an approval gate.
Dynamic steering is what makes the gate usable rather than a wall. When Hunter surfaces a proposed discount and the seller says “not that account, and cap it at ten percent,” that direction should shape the rest of the run, not that one step alone.
Designed well, the approval gate is where a person injects judgment cheaply and the agent absorbs it. Designed badly, it’s either a rubber stamp nobody reads or a bottleneck that makes the whole run pointless. Decide the gates before you turn the agent on, not after it surprises you.
What this costs, and how to watch it
Two cautions before anyone gets a week-long agent near production.
Cost compounds with time. A conversational agent’s consumption is bounded by the conversation. A goal-seeking agent that reasons, retries, and re-plans across a week can spend far more, and the spend is less visible because no human is sitting through it.
The credit math that punishes an over-eager trigger applies here with a longer fuse. Put a ceiling on it. Before you let an agent run unattended for days, you want the instinct behind a credit circuit breaker: a limit that stops the run, not a bill that reports it afterward.
Observability has to move from the turn to the run. Your existing tooling watches conversations. A long-horizon agent needs you to watch a plan: which step it’s on, what it’s checkpointed, what’s waiting on an approval, where it retried.
Salesforce’s framing of the Atlas reasoning engine as a plan-and-act loop is the right lens, extended over days. If you can’t see the plan, you can’t trust the autonomy, and you’ll gate everything out of caution, which throws away the reason you built it.
The honest state of things: this is the biggest shift in the Agentforce model since it went event-driven, and the flagship agent on it is still in pilot. That’s the right time to design for it. Wire your actions to be retry-safe, decide your autonomy boundaries, and pick one bounded, high-value goal to prove it on.
It’s the wrong time to promise the business an autonomous digital worker running your quarter unattended. Build the durable, governed version first. The runtime rewards the teams that treat it as an engineering problem, not a demo.
Understanding the basics
What is the Agentforce long-horizon runtime?
It’s the execution layer Salesforce announced on September 11, 2026 that lets an Agentforce agent pursue a goal across days and weeks instead of completing a single task or conversation. Salesforce describes it as resting on three capabilities: memory that preserves context and progress across sessions, durable execution that keeps a plan running and lets the agent resume or course-correct after interruptions, and dynamic steering that adapts the agent’s behaviour to a person’s feedback mid-run. Hunter, the outbound sales agent, is the first to run on it.
How is a long-horizon agent different from a normal Agentforce agent?
A normal agent acts within a conversation and its work ends when the conversation does. A long-horizon agent turns an objective into a plan, keeps that plan alive when no one is interacting with it, resumes from checkpoints after failures, and takes actions on its own within guardrails while escalating the consequential ones for approval. The design work shifts from writing a good turn to designing durable memory, retry-safe actions, and an explicit autonomy boundary.
Can I deploy a long-horizon Agentforce agent to production today?
Not the flagship one yet. Most of the named job-ready agents announced alongside the runtime are generally available, but Hunter, which showcases the long-horizon runtime, is in pilot with a general-availability target of November 2026. The move now is to design for it: make custom actions idempotent, decide which actions need an approval gate, and plan your memory and cost controls, so you’re ready when it reaches GA.
Why do custom actions for a long-horizon agent need to be idempotent?
Because durable execution resumes a plan from checkpoints after an interruption, an action can be retried. If the action has a side effect, such as sending a quote or creating a record, a retry can duplicate that effect unless the action is safe to run more than once. Designing actions to check for prior work, or to key writes on an idempotency token, prevents a resumed plan from double-charging a customer or sending a message twice.
Thinking about pointing an agent at a multi-day goal instead of a case queue? Talk to us before you turn on autonomy. Designing the memory, the retry-safe actions, and the approval boundary that make a long-horizon agent safe is part of every Agentforce build we do.
