Agentforce
Agent Optimizer: the Agentforce tool that reads your traces and proposes the fix
The most useful demo at Dreamforce 2026 was not a model. It was Agent Optimizer tracing a spike in escalated refunds to a gap in a router, proposing the change, and writing the regression tests. Salesforce dates it for October. This is what it does, what has to be switched on before it can do anything, and how to judge a fix a tool wrote for you.
The Dreamforce demo I keep coming back to had no keynote music. A service agent in production was escalating refund requests over $200 far more often than expected. Agent Optimizer read the session traces, found a gap in how the subagent and the Agent Router were configured, proposed a change, and generated the tests to prove it.
Salesforce Ben’s roundup of the Agentforce keynote has the sequence, and Rajesh Beri’s write-up called it the most decision-relevant demo of the week. I agree with him.
The reason it matters is not the AI in it. Every team running an agent in production already has the problem the demo solved. Something drifts, a metric moves, and someone spends two days reading transcripts to find out why. A tool that reads the traces for you and proposes a hypothesis compresses that.
The interesting questions are what it needs from you first, and how far to trust what it proposes.
What Agent Optimizer is, and what it is not
Salesforce’s September 11 announcement describes Agent Optimizer as a tool that helps build, refine and test agents by analysing session traces, with general availability in October 2026. The keynote showed it working. Between now and October, treat what you saw as a preview.
The name is close to an older one, and the difference matters. In November 2025 Salesforce made a feature called Agent Optimization generally available as part of Agentforce Observability: full session tracing plus an LLM-as-judge quality score on each session. That was measurement.
Agent Optimizer, the 2026 product, is the step after measurement. It reads the traces, forms a hypothesis about a configuration problem, proposes a change to topics, subagents or the router, and writes tests for the change.
So the stack now has three layers. Session tracing captures what happened. Scoring, including the Custom Scorers that went to beta in Winter ‘27, says whether it was good. Optimizer says why it was not, and what to change. The first two have to be on before the third can do anything.
What has to be switched on first
Agent Optimizer works from session traces, and session traces are not free or automatic.
The traces live in the Session Tracing Data Model in Data 360. The model is OpenTelemetry-compatible and captures the user’s utterances, the LLM calls, the tool invocations, the guardrail checks and the response timing for each turn. If your org does not have Data 360 provisioned, or has it provisioned without session tracing enabled, there is nothing for Optimizer to read.
I covered where conversation data lives and how long it survives earlier this month, and the same map applies here: the Session Trace OpenTelemetry API returns a single session per request and only reaches back 72 hours, so a durable copy in Data 360 is the thing Optimizer will analyse, not the API.
Trust Layer audit data is a separate switch. The audit and feedback collection in the Einstein Trust Layer has to be explicitly enabled to land in Data 360, and it cannot be backfilled. An Optimizer analysis of last month’s escalations needs last month’s traces to exist.
The third prerequisite is a definition of good. The demo’s problem was stated as “refunds over $200 escalate more than expected”. Expected by whom, at what rate?
Optimizer can find a configuration gap once it knows a metric moved, and the metric has to be one you defined. The built-in scores cover helpfulness and escalation. Anything specific to your use case is a Custom Scorer you write.
How the demo’s fix works
The refund example is worth walking through because the fix was structural, not a prompt tweak.
A router in Agentforce decides which subagent or topic handles a request. In the demo, refund requests above a threshold were falling through a gap between what the refund subagent’s classification covered and what the router expected, so they hit the escalation path instead of the refund path. The proposed change closed that gap in the subagent and topic design. Then Optimizer generated a smoke test, to confirm the changed route handles the case, and a regression test, to confirm the routes that already worked still do.
Southwest Airlines showed the same architecture in the keynote from the other direction: a structured Agent Router with dedicated subagents for intake, document validation, reimbursements and ticket refunds on a customer name change. When routing is that explicit, a router gap is something a tool can find by reading which subagent received which utterance. When an agent is one mega-topic called “help customers”, there is no route to inspect, and Optimizer has less to work with. The tool rewards teams that already built agents the way Agent Script encourages: explicit routes, deterministic handoffs, narrow topics.
How far to trust a fix a tool wrote
This is the part I would think hardest about before October.
Optimizer proposes a configuration change and the tests for it. Both are generated. The change might be right. The tests might be right. And a test generated by the same system that generated the change is not independent evidence that the change is correct. If the tool misreads the traces, it can propose a plausible change and a test that passes for the same wrong reason.
The discipline is the one you would apply to a junior engineer’s pull request. Read the proposed change against your own understanding of the routes. Run its tests, and then run your own. The Testing Center and your existing CI test set are the independent evidence. If Optimizer’s regression test passes and your baseline suite passes, you have two sources agreeing. If you have no baseline suite, you have one source, and it is the one under review.
That leads to the most useful thing to do before the tool arrives. Build the baseline. A set of utterances with expected routes and expected outcomes, run on a schedule, is what turns “Optimizer proposed X” into “Optimizer proposed X and nothing else broke”. Synthetic personas are one way to generate the utterances if you do not have enough real ones.
Where it fits in the operating loop
Salesforce’s Mark Wakelin framed the keynote around an operating loop: get the agent into production, monitor it, improve it continuously. Fulton Bank was the customer example, and the numbers Salesforce cited were the bank’s, not something I can verify: 80,000 hours saved, a four-day reduction in complaint resolution time, and the Hunter agent running background tasks from Gmail. Treat those as a vendor’s customer story.
The loop itself is right, and Optimizer is the piece that was missing from it. Observability told you the agent drifted. Scorers told you how far. Until now the “improve” step was a person with a transcript export. If Optimizer does what the demo showed, the person still decides, but they start from a hypothesis instead of a blank page.
Two things I would watch once it ships. Whether it consumes credits per analysis, which Salesforce has not said. And whether it can propose changes to Flow and Apex actions, or only to the agent’s own topics and routing. The demo stayed inside the agent’s configuration. Most production failures I see start in the action underneath.
What to do before October
Four things, in order.
Confirm session tracing is on and landing in Data 360, and that the Trust Layer audit collection is enabled. If either is off, turn it on now, so October’s analysis has September’s data.
Write two or three Custom Scorers for the outcomes your agent exists to produce. “Refund resolved without escalation under policy” is a scorer. “Helpful” is not specific enough to find a router gap.
Build or refresh the baseline test set in Testing Center, with expected routes as well as expected answers. That set is your independent check on anything Optimizer proposes.
Look at your topic and subagent structure. If there is one topic doing everything, split it before the tool arrives. Optimizer finds gaps between routes, and it needs routes to find gaps between.
Understanding the basics
What is Agentforce Agent Optimizer?
A tool Salesforce announced on September 11, 2026 that analyses an agent’s session traces, identifies configuration problems such as a gap between a subagent’s scope and the router’s expectations, proposes a change, and generates smoke and regression tests for it. Salesforce has dated general availability for October 2026 and demonstrated it at Dreamforce.
Does Agent Optimizer need Data 360?
Yes, in practice. It works from the Session Tracing Data Model, which is stored in Data 360, and the Session Trace API only reaches back 72 hours. Session tracing and the Trust Layer’s audit collection both have to be enabled before the traces exist for Optimizer to read.
Is Agent Optimizer the same as Agent Optimization?
No. Agent Optimization was the session-tracing and LLM-as-judge scoring feature that became generally available with Agentforce Observability in November 2025. Agent Optimizer, announced in September 2026, reads those traces to propose configuration fixes and tests.
Should I apply the changes Agent Optimizer proposes automatically?
I would not. The change and its tests are generated by the same system, so a passing generated test is not independent evidence. Review the change against your own route design and run your baseline test set before deploying.
The tool is only as good as the traces you kept
Every demo of an optimiser shows it finding the problem. What the demo cannot show is the org where session tracing was never enabled, the audit log was never switched on, and the only definition of “good” is a thumbs-up count. In that org, Optimizer arrives in October with nothing to read.
The work between now and then is unglamorous and entirely yours: tracing on, scorers written, a baseline suite that runs. Do that, and the tool gets to be as useful as the demo.
If you want session tracing, scorers and a baseline test set in place before Agent Optimizer ships, talk to us, or check where your agent stands with the Agentforce readiness assessment.
