Agentforce dynamic plans: when the resolution rewrites itself mid-case

Every Agentforce agent you’ve built until now waits its turn. The customer says something, the agent reasons, acts, and answers, then it stops and waits for the next message. That request-and-response rhythm is the whole shape of a turn-based agent, and it has a blind spot: between turns, the agent isn’t thinking. A case can mutate under it (a customer mentions a second product, a billing error turns out to be a technical one, an entitlement lapses mid-conversation) and a turn-based agent only notices when someone types the next prompt.

Winter ‘27 breaks that rhythm. The release’s Adaptive Experiences & Dynamic Plans, a capability of the Service Rep Assistant, points what Salesforce calls an ambient AI agent at a live case or messaging conversation. It listens in real time, reasons over the evolving context, and regenerates its resolution plan as the issue changes. Without waiting for an explicit new prompt. Salesforce reports four customers already live on it, including PowerSchool with more than 550 users, as the broader Service Rep Assistant program passes 100 customers. That’s a small production footprint, but the architectural idea is the one worth understanding, because it changes how you design, cost, and test an agent.

This post is what a “dynamic plan” is underneath the marketing, why it matters that this ships as a rep-assist rather than an autonomous agent, how it differs from the turn-based and event-triggered agents you already run, and the three trade-offs (latency, credits, and plan thrash) you take on the moment the plan stops holding still.

What a “dynamic plan” is

Strip the branding and a dynamic plan is an artifact the Atlas reasoning engine already produces. Atlas runs a Reason–Act–Observe loop: a Planner component translates the user’s goal into a step-wise plan, an action selector and execution engine carry out each step, and a reflection step observes the result and decides what to do next. The “plan” is the Planner’s output, an ordered set of steps the agent intends to take to resolve the goal. In a normal turn-based agent, that plan is generated when the user sends a message and consumed within the same turn.

Adaptive Experiences changes when the plan is regenerated. Instead of only re-planning on a new prompt, the ambient agent feeds new conversation context back into the Planner as the case evolves, and the Planner rewrites the plan to match the situation it now understands. The plan becomes a living document rather than a one-shot output:

Live case: "I was double-charged for my subscription."

  Plan v1 (generated on open)
    1. Verify identity
    2. Pull billing history for the account
    3. Confirm the duplicate charge
    4. Issue refund within policy
    5. Summarize resolution

  … customer adds: "and now I can't log in at all"

  Plan v2 (regenerated, context changed, no new prompt needed)
    1. Verify identity                         ✓ done
    2. Pull billing history                     ✓ done
    3. Confirm duplicate charge                 ✓ done
    4. Issue refund within policy               → in progress
    5. NEW: check auth/entitlement status       ← added
    6. NEW: if lockout tied to failed billing,
            restore access before refund posts
    7. Summarize resolution

That regeneration is the entire feature. Everything else (the ambient listening, the “runs the workflow” framing) is in service of getting fresher context to the Planner more often so the plan tracks reality instead of tracking the last thing the customer typed.

A turn-based agent re-plans when the user speaks. An ambient agent re-plans when the situation changes. Most of the value, and all of the new cost, lives in that difference.

The word that changes everything: assist

Here is the detail most coverage skips, and it decides how you should build on this: Adaptive Experiences ships as a capability of the Service Rep Assistant. It assists a human service representative. The updated plan surfaces to the rep, who stays in the loop and drives the resolution. This is not an autonomous agent closing cases unattended, and describing it as one will lead you to design the wrong thing.

That framing is deliberate, and it’s the right one. An agent that continuously rewrites its own plan is exactly the kind of system you do not want acting autonomously on a customer while it’s still figuring out what the case even is. Salesforce has effectively split the agentic-service surface into two poles, and Winter ‘27 makes both explicit:

• The autonomous customer-facing agent: resolves the case on its own, within tightly scoped topics and actions, and escalates when it shouldn’t act. This is the service agent you already know, and its whole discipline is narrowness.
• The ambient rep-assist: sits inside a live human-handled case, watches it evolve, and keeps a recommended plan current so the rep never loses the thread. Breadth and adaptivity are the point here, precisely because a human is the guardrail.

If you’ve read our take on Einstein for Service as the assistive layer most teams should ship first, this is that argument extended one level up. Service Replies and Work Summaries assist the rep with drafting and summarizing a turn. Dynamic Plans assist the rep with the shape of the whole case. Same posture (human in control, AI doing the cognitive legwork) applied to the resolution strategy instead of the individual reply. It’s also the cleaner reading of what the Agentforce Assistant is versus an autonomous agent: reactive, in-app, running as the user, not as itself.

How this differs from the agents you already run

Three existing patterns look adjacent and behave nothing alike. Getting the distinction right is how you avoid building the wrong one.

Versus a turn-based chatbot or agent. A turn-based agent’s reasoning is bounded by the message. It plans on your prompt, acts, answers, and goes idle. If the case changes character between your messages, it doesn’t know until you tell it. The ambient agent’s reasoning is bounded by the conversation, not the turn. It re-evaluates as new information arrives in the stream. The practical payoff is on messy, multi-issue cases where a turn-based agent keeps solving the problem you stated while the ambient one tracks the problem you have.

Versus an event-triggered agent. Triggered agents fire once on a record change or a Data 360 signal, run a single reasoning pass with no human in the loop, and stop. They’re a fire-and-forget pattern for automation. The ambient agent is the opposite: permanently present in a session, re-planning continuously, with a human consuming the output. One reacts to a discrete event and exits; the other stays resident and adapts. Don’t reach for Adaptive Experiences when what you want is a triggered automation. You’ll pay for continuous reasoning you don’t need.

Versus a scripted plan in Flow or Agent Script. This is the most important contrast, and Winter ‘27 sharpens it deliberately by shipping both poles at once. A deterministic path (a Flow, or the deterministic instructions in Agent Script) executes fixed if/else logic with no LLM in the decision. It does the same thing every time, which is exactly what you want for a refund threshold or a compliance gate. A dynamic plan is the other pole: generated by the Atlas Planner and rewritten as context shifts, so it doesn’t do the same thing every time, which is exactly what you want when the case is ambiguous and evolving. The real Winter ‘27 story isn’t “adaptive beats deterministic.” It’s hybrid reasoning: you get a deterministic anchor and an adaptive planner, and the engineering skill is knowing which decisions belong to which.

That decision maps cleanly onto the altitude question we keep coming back to in the Flow, Apex, or Agentforce decision guide. Anything that must be identical every time (a policy limit, an eligibility rule, an action that moves money) is deterministic, and it should be pinned in Agent Script or a Flow so the LLM can’t reinterpret it. Anything open-ended, what should we even do about this tangled case, is where a dynamic plan earns its cost.

The three trade-offs you inherit

A plan that rewrites itself is not free, and the costs are structural, not incidental. Budget for them before you turn it on.

1. Latency: reasoning on a live stream is slower than reasoning on a turn

A turn-based agent reasons once per message and you feel it as normal response time. An ambient agent that re-plans as context evolves is running the Planner more often, and every regeneration is an LLM call with its own round-trip. Salesforce hasn’t published a re-planning cadence or a latency figure for Adaptive Experiences, so don’t design around a specific number, but the direction is certain, and it compounds the latency budget you’re already managing. The mitigation is the same as everywhere else in agent design: keep the grounding retrieval tight, keep the context you feed the Planner lean, and don’t ask it to re-plan on noise. Which leads directly to the second cost.

2. Credits: the meter runs on actions, and re-planning fires more of them

Agentforce bills on the Flex Credit meter, where a standard action costs 20 credits, about $0.10, and the bill is essentially actions executed × $0.10. An ambient agent that re-plans repeatedly across one live case will, if each regenerated plan fires fresh retrievals and actions, execute more actions than a turn-based agent handling the same case. The exact metering boundary between “reasoning/re-planning” and “billable action” isn’t precisely documented for this feature, so treat the per-replan cost as directional, not modeled, but the shape is familiar from every other consumption surface on the platform: continuous reasoning that triggers grounded actions is where credit burn concentrates. The Flex Credit optimization levers apply here with extra force, especially bulkifying retrieval so a re-plan reads context in one action instead of four, and making sure a plan regeneration that changed nothing material doesn’t re-fire the same lookups.

3. Plan thrash: an adaptive plan can be adaptive to a fault

The failure mode unique to this pattern is thrash, the plan flipping erratically because the agent over-reacts to every noisy signal in the conversation. A customer’s offhand aside shouldn’t tear up a resolution that was two steps from done. The defense is the hybrid-reasoning point made concrete: pin the parts of the workflow that must not move. Use Agent Script’s deterministic instructions and guardrails to hold the non-negotiables (the escalation triggers, the approval gates, the actions that require a human sign-off) steady regardless of what the Planner does, so adaptivity happens inside a fixed frame instead of replacing it. The human rep is the ultimate backstop by design, but you don’t want the rep babysitting a plan that reshuffles every fifteen seconds. Give the adaptivity walls to bounce off.

Testing and watching a plan that won’t hold still

The obvious objection to a self-rewriting plan is: how do you test something that’s different every run? Winter ‘27’s answer is observability built for exactly this. The Session Tracing Data Model logs the pieces you need to audit a non-deterministic resolution (user inputs, agent responses, reasoning steps, LLM calls, and guardrail checks) and stores them in Data 360, which is what lets you reconstruct why the plan changed on a given case rather than just that it did. A conceptual trace for one regeneration:

{
  "session": "case-4471-live",
  "event": "plan_regenerated",
  "trigger_context": "new customer message: login failure",
  "prior_plan_steps": 5,
  "new_plan_steps": 7,
  "steps_added": ["check_auth_status", "restore_access_if_billing_lockout"],
  "steps_completed_preserved": ["verify_identity", "pull_billing", "confirm_charge"],
  "guardrail_checks": ["refund_within_policy_limit: pass"],
  "llm_calls": 1
}

Pair that trace with the testing surface. Custom Scorers, in beta this release, let you define your own pass/fail evaluation logic for a session, so you can score the outcome of an adaptive plan (“did it resolve the actual issue, within policy”) rather than trying to assert on a fixed sequence of steps that will never repeat. That’s the correct way to test a non-deterministic system: assert on invariants and outcomes, not on the exact path. It’s the same discipline the broader observability command center is built around, now aimed at a plan that legitimately changes shape between runs.

Two more things Winter ‘27 changes underneath this

Two release-level facts shape how you’ll adopt Adaptive Experiences, and both are easy to miss.

First, Winter ‘27 auto-enables Agentforce by removing the Setup toggle. It rolls out to existing orgs from early September 2026, at no added cost and no billing change. That doesn’t turn on Adaptive Experiences for you, but it does mean the agentic surface is present in orgs that never deliberately switched it on. If you own governance, treat “Agentforce is now on by default” as a reason to review who can build and deploy agents, exactly the way you’d govern any agent fleet. Default-on is not the same as default-safe.

Second, the release’s other headline features are the plumbing that makes “agents run the workflow” more than a slogan: Hosted MCP Servers let external MCP clients reach org data through governed connections, Agent Script provides the deterministic-plus-prompt authoring model this post leans on, and Custom Scorers and session tracing provide the evals. Notably, Salesforce has said only agents built with the new Agent Script Builder can be exposed as MCP tools, legacy agents need upgrading, so the authoring model and the interoperability story are coupled. If MCP is on your roadmap, the Agent Script migration is the gate.

The honest read

Be clear-eyed about the maturity. Four production customers is a real deployment, not a mass rollout, and the community’s Agentforce mood in 2026 runs to hype fatigue, cost sensitivity, and the well-worn complaint that grounding data quality is where deployments fail, a Citi analyst flagged “limited data points on production usage” of Agentforce as recently as this year. Adaptive Experiences doesn’t escape any of that. If anything it raises the stakes, because a plan is only as good as the context it re-plans on, and continuous re-planning on stale or thin grounding just produces confidently wrong plans faster. The data foundation is, as ever, the thing that decides whether this helps.

But the direction is right, and it’s worth internalizing even before you deploy it. Turn-based agents were always a compromise with how conversations go: messy, branching, and prone to changing what they’re about halfway through. An ambient agent that keeps a resolution plan honest against a moving case, with a human holding the wheel and deterministic guardrails holding the non-negotiables, is a better fit for real service work than a bot that only thinks when spoken to. Ship it where the cases are complex enough to justify the latency and the credits, pin the parts that must not move, and score the outcome instead of the path. That’s the build that makes a self-rewriting plan an asset instead of a liability.

Understanding the basics

What are Adaptive Experiences and Dynamic Plans in Agentforce?

Adaptive Experiences & Dynamic Plans is a Winter ‘27 capability of the Salesforce Service Rep Assistant. An ambient AI agent listens to a live case or messaging conversation in real time, reasons over the evolving context, and regenerates its resolution plan as the issue changes. Without waiting for a new prompt. The regenerated plan surfaces to a human service representative, who stays in control of the resolution. It is a rep-assist, not an autonomous customer-facing agent. Salesforce reports four customers live on it at launch, including PowerSchool with more than 550 users.

How is an ambient agent different from a turn-based agent?

A turn-based agent reasons once per message: it plans when the user speaks, acts, answers, and then goes idle until the next prompt. An ambient agent’s reasoning is bounded by the conversation rather than the turn. It continuously re-evaluates as new information arrives and rewrites its plan when the situation changes, even if the user hasn’t sent a new message. The benefit shows up on complex, multi-issue cases where the problem the customer has drifts away from the problem they first stated. The cost is more frequent reasoning, which means more latency and more billable actions.

Is a dynamic plan the same as a Flow?

No, they’re opposite poles, and Winter ‘27 ships both on purpose. A Flow (or the deterministic instructions in Agent Script) executes fixed if/else logic with no LLM in the decision, so it does the same thing every time: correct for policy limits, approval gates, and actions that move money. A dynamic plan is generated by the Atlas reasoning engine’s Planner and rewritten as context evolves, so it deliberately does not do the same thing every time. Correct for ambiguous, evolving cases. The engineering skill is hybrid reasoning: pin the non-negotiables deterministically and let the planner adapt only the open-ended parts.

Does Adaptive Experiences replace human service reps?

No. It ships as a capability of the Service Rep Assistant, which means it assists a human representative rather than replacing one. The agent keeps a recommended resolution plan current as the case evolves; the rep reviews it, drives the interaction, and remains the decision-maker and the guardrail. That human-in-the-loop framing is intentional, a system that continuously rewrites its own plan is precisely the kind you want a person supervising, not one you set loose on a customer unattended.

---

Deciding where an adaptive plan earns its latency and credits versus where a deterministic Flow or Agent Script should hold the line, and how to ground it so it re-plans on truth, not noise? Talk to us. Getting the hybrid-reasoning split right, and instrumenting the outcomes before go-live, is exactly the work we do.