Agent Optimizer is an Agentforce agent whose job is improving your other agents. It reads session traces in Data 360, groups the failures that keep repeating, proposes a configuration change in Agentforce Builder, and writes tests for that change before anything ships. To get good fixes on day one, you need tracing turned on now, a baseline test set you own, and success metrics a scorer can actually measure.
In This Article
Your service agent went live six weeks ago. The deflection number on the dashboard looks healthy. Then someone from finance asks why refund requests above a certain amount keep landing in the human queue, and nobody can answer yet. Finding out means opening transcripts one at a time.
That’s how most agent tuning still works. Somebody samples twenty conversations, spots a pattern, rewrites an instruction, and hopes the change didn’t break three things that used to work. It’s fine at fifty conversations a day. At a few thousand a week, it’s guesswork with extra steps.
Salesforce announced Agent Optimizer on September 11, 2026, with general availability set for October. The Dreamforce recap describes it as an agent that builds other agents and finds recurring failure patterns in production sessions. I’d put it more plainly: it’s the teammate who reads every transcript, then shows up with a fix and the tests to back it.
Optimization and Optimizer are two different things
The names are one letter apart, so expect confusion in your next steering meeting. Agent Optimization shipped in November 2025 as part of Agentforce Observability. It gives you step by step visibility into sessions, clusters similar requests, and rates response quality with an LLM judge. It shows you where the agent is struggling.
Agent Optimizer is the next step. It takes that same trace data and works the problem: what went wrong, what to change, and how to prove the change works. One is a diagnostic screen. The other is a colleague holding a pull request.
Salesforce’s own description is short. Agent Optimizer works alongside teams across the agent lifecycle, helping them build and refine agents, subagents, and actions, evaluate performance, and review session traces to find what to improve. Underneath that sentence is a loop. Look at each step on its own, because each one depends on something you configure.
The raw material is the Session Tracing Data Model in Data 360. It’s OpenTelemetry compatible and records each turn: the utterance, the LLM calls, tool invocations, guardrail checks, and response timing. Because it follows an open format, the same traces can also feed tools like Datadog or Arize if your SRE team already lives there.
From there, Optimizer groups failures that look alike. Tool call errors in one bucket, knowledge gaps in another, off topic requests in a third. Then it ranks them against the outcomes you care about, drafts a change to instructions, subagent descriptions, actions, or routing, and generates tests that cover both the broken case and the paths that already work.
Walking through the refund example
Back to the finance question. Here’s how a loop like this plays out on a typical routing gap (my illustration, not a Salesforce demo script):
Optimizer groups 140 sessions where refund requests over $200 ended in escalation. All of them hit the general FAQ subagent first.
The refund subagent’s description says “standard refunds,” so the router treats larger amounts as something else. The traces show the misroute on turn one.
It proposes a clearer subagent description and an amount threshold input on the refund action, then drafts one test for the failing case and a set of regression tests for existing refund paths.
Your admin runs the tests in a sandbox alongside your own baseline set, approves the change, and ships it through the normal pipeline.
Without the loop, finding that misroute means somebody reading a few dozen transcripts and getting lucky. With it, the gap shows up as a ranked cluster with the evidence attached, and the fix arrives already tested.
Agent Optimizer doesn’t run on its own. It sits on top of the testing and observability features Salesforce has been shipping for the past year, several of which got Dreamforce 2026 updates. Think of it as layers. Each one answers a different question, and Optimizer reads from all of them.
Every turn, every tool call, every guardrail check, stored in Data 360. If it isn’t traced, nothing above this layer can see it.
Generate tests from your subagents, actions, and knowledge, or upload your own scenarios. Run them in batch, in a sandbox, since tests can modify CRM data.
Grade production sessions with your own evaluation logic and output types. The API is GA and the UI is in beta.
A/B Experimentation splits traffic between agent variants with a scorecard in Builder. Agent Health Monitoring tracks reliability with 16+ metrics and custom alerts.
| Capability | Question it answers | Status (Oct 2026) |
|---|---|---|
| Session Tracing Data Model | What exactly happened on each turn? | GA |
| Testing Center | Does the agent pass my known scenarios? | GA |
| Custom Scorers | Did this session meet my business definition of success? | API GA, UI beta |
| Voice and Conversation Testing | Does it hold up across multiple turns and voice? | Beta |
| A/B Experimentation | Is variant B actually better than A with real traffic? | Beta (October) |
| Agent Health Monitoring | Is the agent up, fast, and erroring less than yesterday? | GA |
| Agent Optimizer | What should I change next, and does the change work? | GA (October) |
The turn by turn record of a conversation: inputs, LLM calls, tool calls, guardrail results, and timing.
Your own grading logic applied to sessions, for outcomes the built-in quality scores can’t judge.
A metric in Voice and Conversation Testing that checks whether the simulated customer got what they came for.
A test that confirms behavior that already worked still works after a change.
Built-in scores cover general quality, like helpfulness and escalation. “Refund issued within policy, no escalation, under four turns” is specific to your business, and only a Custom Scorer can measure it. Optimizer ranks fixes by the outcomes you define, so a vague definition gets you vague priorities.
Here’s the design lesson I’d tape to every Agentforce team’s monitor. An optimizer can only reason about structure that exists. If your agent is one giant subagent called “General Help” with forty actions and a page of instructions, every failure looks the same from the outside. There’s no route to blame and no boundary to adjust.
- Failures blur together in the traces
- Fixes land as longer and longer instructions
- Regression tests are hard to scope
- Fine for: a two week prototype
- Misroutes show up as a specific boundary
- Fixes are small and reviewable
- Tests map cleanly to routes and actions
- Best for: anything in production
Write descriptions a router can’t misread. “Refunds of any amount for orders placed in the last 90 days” beats “standard refunds.”
Name actions and inputs for what they do. Traces get far easier to read when an action is called Create_Refund_Case instead of Process_Request_v2.
Where a rule never changes, make it deterministic. Optimizer then tunes the parts that need reasoning.
Own a baseline before the optimizer writes tests
Optimizer drafts tests for every fix it proposes, which is great. You still want your own baseline: twenty to fifty real conversations, each with the expected subagent, actions, and outcome. That set belongs to you, not to the tool proposing the change. With Agentforce DX, it’s a YAML spec and two CLI commands.
YAML# specs/Service_Agent_Baseline-testSpec.yaml
# Baseline you own; Optimizer's generated tests run alongside it
name: Service_Agent_Baseline
description: Routing and outcome baseline for the service agent
subjectType: AGENT
subjectName: Customer_Service_Agent
testCases:
- utterance: "I need a refund for order 10482, it was $240"
expectedTopic: Refund_Requests
expectedActions:
- Get_Order_Details
- Create_Refund_Case
expectedOutcome: "Agent creates a refund case and shares the case number"
- utterance: "Where is my order 10519?"
expectedTopic: Order_Status
expectedActions:
- Get_Order_Details
expectedOutcome: "Agent shares current shipping status and tracking link"
BASH# Create the test in a sandbox, then run it and wait for results
sf agent test create --spec specs/Service_Agent_Baseline-testSpec.yaml \
--api-name Service_Agent_Baseline --target-org svc-sandbox
sf agent test run --api-name Service_Agent_Baseline \
--wait 10 --result-format human --target-org svc-sandbox
Put that run in your CI pipeline and every change, whether it came from a person or from Optimizer, faces the same bar before it reaches production.
If I were rolling this out for a service org this month, this is the order I’d follow. Start the prep before the GA flag reaches your org, because the trace history it needs builds up one day at a time.
Before you click Analyze
Agent Optimizer is the piece I’ve wanted since the first Agentforce pilots. It also changes where the work sits. The tool does the reading and drafting. You supply the history, the definition of success, and the final call. Here’s where teams will feel that most.
History starts the day you switch it on
Optimizer analyzes the traces you collected. Sessions from before tracing and audit collection were enabled simply aren’t there to read, and they can’t be backfilled. Teams that turn tracing on today will have a month of evidence when they run their first analysis. Teams that wait until GA lands in their org will start from zero.
Illustrative. Actual depth depends on your session volume and how varied your traffic is.
Generated tests are a start, your baseline is the referee
The tests Optimizer drafts are built around the change it proposed. That’s useful, and it’s also the reason they shouldn’t be the only check. Your own baseline set, written before any fix existed, is the independent evidence. Run both, every time.
Budget for the data too
Full tracing writes to Data 360, and both tracing and storage consume credits. Salesforce hasn’t published a per-analysis rate for Optimizer yet. Plan for it the same way you planned for agent actions: start with your highest volume agent, watch consumption in Digital Wallet for a few weeks, then widen the scope.
Keep a person on the approve button
You choose how much of the loop runs unsupervised. My advice for the first quarter is to let Optimizer investigate, draft, and test, and keep deployment as a human decision. The keynote demos focused on agent configuration: instructions, subagents, routing. When a trace points at a bug inside a Flow or Apex action, that fix still belongs to your developers.
Treat Optimizer like your sharpest new hire. It reads everything and drafts fast. You still review the pull request, and you still own what goes to production.
For two years, most of the effort in Agentforce projects went into building agents. The next year looks different. Improving agents is turning into a discipline of its own, with traces as the evidence, scorers as the spec, and an agent doing the first pass. The question to ask your team this week isn’t whether to use Agent Optimizer. It’s whether you could tell it, in one sentence per agent, what success looks like.
Agent Optimizer, Custom Scorers, A/B Experimentation, and 18 more announcements with release timing.