Every Agentforce conversation I’ve seen so far, in demos and in real builds, ends in minutes. A customer asks something, the agent reasons over a topic and some actions, and it answers. Long-running agents break that assumption. The goal isn’t answered in one turn. It might take three days, span a dozen system checks, and need to pick back up after a human went to lunch, a batch job finished overnight, or an approval sat in someone’s queue until Thursday.
That’s a different engineering problem, not just a longer conversation. And it changes what a Salesforce technical lead actually has to design for.
What “long-running” actually means here
A short-running agent interaction has a request, some reasoning, maybe a tool call or two, and a response. State lives in the session and dies with it. A long-running agent holds a goal across multiple sessions, multiple triggers, and gaps of real time where nothing is happening at all. Think: “resolve this customer’s billing dispute,” not “answer this customer’s question about their bill.”
Resolving the dispute might mean raising a case, waiting for a credit approval that takes two business days, checking back when the approval lands, applying the credit, and then confirming with the customer a week later that it’s done. No human is sitting there watching the whole thing. The agent has to know where it left off every time it wakes up.
The state problem nobody puts in the demo
Most Agentforce demos show a topic, a few actions, a clean answer. What they don’t show is what happens to the agent’s understanding of the goal between step two and step seven, three days apart. You need a durable record of: what was the original goal, what’s been tried, what’s pending, what’s the next trigger that should wake this thing up. That’s a data model problem, not a prompt engineering one, and it belongs on your org’s objects, not buried in a context window that resets.
I’d model it as a first-class record, something like an Agent Task or Agent Goal object, with a status picklist, a reference to the triggering case or opportunity, and a related list of the steps the agent has taken so far. Give it the same rigor you’d give a case lifecycle. Because that’s effectively what it is.
Where the real risk sits
Short-running agents fail loudly and immediately. You see the wrong answer in the chat window and you fix it. Long-running agents can fail quietly for days before anyone notices, because nobody’s watching a conversation that isn’t happening in real time.
The failure modes I’d actually worry about:
- An agent that’s waiting on an external event (an approval, a callout response, a batch completion) and never gets woken up because the trigger that should resume it didn’t fire.
- An agent that retries a step it already completed, because its record of “what’s been done” drifted from what actually happened in the org.
- An agent that’s technically still “in progress” according to its own status field, three weeks after the customer gave up and called support directly.
- Two separate long-running processes both acting on the same case because neither checked whether the other had already claimed it.
None of these show up in a quick test. They show up in production, slowly, and they’re the kind of thing a support team discovers when a customer calls in furious about something Salesforce thought it had already handled.
Timeouts and dead-letter handling, not optional
Every long-running goal needs an expiry. If an agent is waiting on an approval that was supposed to take two days and it’s been nine, that’s not a quiet background process anymore, that’s an escalation. Build the “this has gone stale” check as deliberately as you’d build the happy path. A contact-centre team I worked with learned this the hard way with a long-running case escalation flow, not an agent, but the same principle: anything that waits across sessions needs a heartbeat and a timeout, or it becomes invisible debt that resurfaces as an angry phone call.
What this changes about how you build the action layer
Short-running agent actions can assume a clean, present-tense context: here’s the customer, here’s the case, go. Actions built for long-running goals need to assume the opposite. They need to be safe to call more than once (idempotent), they need to record enough of what they did that a resumed agent can tell “already done” from “not yet attempted,” and they need a way to signal “I’m waiting on something external” rather than just returning and losing the thread.
That pushes real design work back onto your Apex actions and Flow orchestrations. If you’re exposing an action to an agent that might call it, wait days, then call a follow-up action, you can’t design it the way you’d design a single-request integration. You need a correlation ID that survives the gap, and you need the receiving system (yours or a third party’s) to be able to answer “what’s the status of the thing you asked me to do” rather than just “here’s what happened when you asked.”
Observability has to span the whole goal, not one session
Debugging a short-running agent means reading one transcript. Debugging a long-running one means reconstructing a timeline: what was the goal on day one, what changed on day two, why did it sit idle for 36 hours, what finally triggered the resumption. If your logging only captures individual agent sessions, you’ve got gaps in the story exactly where the interesting failures live. Build the audit trail at the goal level, update it at every state transition, and make it queryable by the goal record, not just by transcript ID.
Practical starting point
If you’re building toward this rather than already in it, start smaller than “fully autonomous multi-day agent.” Pick one process in a typical enterprise org that already has a natural multi-step, multi-day shape, something like a credit approval or an onboarding checklist, and model the state explicitly before you hand any of it to an agent. Get the status object, the timeout logic, and the resumption trigger working as a deterministic Flow first. Once that skeleton is solid, the agent is just a smarter decision-maker sitting on top of state you already trust. Build the agent before the state model is solid, and you’ll spend your first few months firefighting things that were never really about the AI at all.