Atlas does not have setup steps in the traditional sense; it runs automatically inside every Agentforce agent. The skill that matters is reading the Plan Trace and acting on its findings. Every Agentforce admin should be able to look at a trace and explain why the agent did what it did, then make the targeted change.
- Open the Plan Trace from a Conversation Preview run
Send a test message in the Conversation Preview. Click the Plan Trace icon on the response. The trace opens in a panel showing topic match scores, action plan, parameter values, and outputs.
- Read the topic match scores first
Atlas shows the confidence score for every topic. The picked topic should be a clear leader. If two topics are within 0.05 of each other, the classification descriptions are overlapping and need to be tightened.
- Walk through the action plan in execution order
The plan lists actions in the order Atlas ran them. Each row shows the action name, the parameter values extracted, the output returned, and the time taken. A long execution time on one action explains slow agent responses.
- Check parameter extraction against the original message
Compare the parameter values against the message. A missing or wrong parameter is almost always a weak parameter description; rewrite the description with a format hint and an example.
- Read the synthesis prompt for the final response
Atlas exposes the prompt it sent to the model for the final response. Inspect it to confirm the action outputs are included as quoted context and the topic instruction is being applied.
- Pull random traces from production weekly
Set a recurring time to pull 10 random production conversation traces. Look for topic misfires, parameter extraction errors, and slow actions. File the findings as topic or action edits in Agent Builder.
- Capture surprising traces as test cases in Testing Center
Every trace that surprises you is a test case worth capturing. Add it to the agent's Testing Center set with expected topic and actions. The next regression will catch the recurrence.
Which underlying model the engine uses for classification, planning, and synthesis. Salesforce-managed is default; third-party options exist in some regions.
Minimum confidence required to pick a topic vs taking the rejection path. Tunable per agent; most teams keep default.
How many prior turns Atlas reads when extracting parameters or composing responses. Longer windows improve continuity but cost more tokens.
Whether the trace includes the synthesis prompt and raw model responses. Verbose traces are essential during development, optional in production.
Which masking and residency rules apply to prompts processed by the engine. Configured org-wide, applied to every Atlas run.
- Two topics with overlapping classification descriptions produce inconsistent topic picks. Atlas chooses the higher score, but small wording changes flip the winner. Tighten descriptions until each message has one clear home.
- Weak parameter descriptions cause wrong values to be extracted. The trace shows the extracted value; compare against the user message to spot the mismatch.
- Atlas does not retry failed actions automatically. A failed action produces a response that mentions the failure rather than silently retrying. Build retry logic into the action itself if needed.
- Long action execution times dominate perceived agent latency. A 4-second action makes a 2-second reasoning step feel slow. Profile action latency before blaming the engine.
- Atlas does not respect Apex without sharing decorators in the way you might expect. Actions run with the calling user permissions; without sharing in the underlying class does not grant the agent broader access than the user has.