Atlas Reasoning Engine
Atlas Reasoning Engine is the planner inside Agentforce that decides what an agent does on every user turn.
Definition
Atlas Reasoning Engine is the planner inside Agentforce that decides what an agent does on every user turn. It classifies the incoming message into one of the agent's active topics, picks which Agent Actions to invoke (and in what order), extracts the parameters those actions need from the conversation context, runs the actions, and synthesizes the final response. Atlas is the layer that turns a generic LLM into a behaviorally consistent Salesforce agent.
Atlas is what differentiates Agentforce from a plain chatbot wrapper around a model. The engine reads the topic classification descriptions, action instructions, and parameter descriptions that admins write in Agent Builder and uses them to make grounded decisions rather than letting the LLM free-ride on training data. The Plan Trace surfaced in the Conversation Preview is Atlas's decision log, exposed in human-readable form so admins can debug agent behavior without reading model logs.
Why the reasoning engine is named after the Greek titan, not the model
What Atlas does on every user turn
On every inbound message, Atlas runs a sequence: read the message and recent conversation context, match the message against every active topic's classification description, pick the best-matching topic (or reject as out of scope), match the topic's actions against the message, pick one or more actions, extract parameter values, execute the actions in order, collect the results, then either ask the LLM to compose a response grounded in the results or invoke a Prompt Template action for the final answer. Every step is logged. The whole sequence usually completes in 2 to 5 seconds depending on action latency.
Topic classification and the rejection path
Topic classification is the first hard decision. Atlas reads the user message and compares it against every active topic's classification description. The match runs against the description embedding plus the literal phrases the description names. If no topic clears the confidence threshold, Atlas takes the rejection path and either escalates to a human or sends a configured "I cannot help with that" response. The threshold is tunable per agent. Too low and Atlas picks topics for messages it should reject; too high and it rejects messages it could have handled. Most teams settle on the default and tune the topic descriptions instead.
Action selection and the multi-action plan
Once a topic is chosen, Atlas picks one or more actions from that topic. Many turns require a single action ("Get Order Status"). Others require a chain: an Identify Record action to find the right account, then a Get Activity Summary action that uses the account ID. Atlas plans the chain by reading action instructions and matching input requirements to available outputs. A plan with three actions runs in a sequence the engine determines, not in the order they appear in Agent Builder. The Plan Trace shows the actual execution order, which is occasionally surprising.
Parameter extraction from conversation context
Every action input has a parameter description. Atlas reads the description to extract the value from the conversation. "The customer's order number in the format ORD-XXXX" extracts cleanly from messages that contain ORD-1234. A weak description like "order number" can match shipment numbers, invoice numbers, or random digits. Extraction also reads conversation history, so if the order number was established three turns ago, Atlas can carry it into the current turn without re-asking. Persistence across turns is one of the largest UX gains over the previous-generation Einstein Bots.
Response synthesis and grounding
After actions execute, Atlas synthesizes the final response. The synthesis prompt is constructed from the action results, the conversation history, and the topic instruction. The model generates text that is constrained to the action outputs (it should not invent fields not present in the results) and styled by the topic instruction (formal vs casual, short vs long, with citations vs without). Grounding is enforced by including the action outputs as quoted context in the synthesis prompt; the model is instructed to base its answer on the context rather than its training data. Hallucinations still happen but at much lower rates than ungrounded generation.
The Plan Trace and what it shows
Every Atlas run produces a Plan Trace. The trace lists the topic considered, the topic picked, the actions considered, the actions invoked, the parameter values extracted, the action outputs, and the final response. The trace is the single most useful debugging tool in Agentforce. A surprising response is almost always explained by the trace: wrong topic, wrong parameter extraction, missing action output. Reading traces is a skill that takes a week to develop and pays back for the life of the agent. Most experienced Agentforce admins keep a habit of pulling random conversation traces weekly to look for drift.
Latency, model choice, and the trust layer
Atlas runs its reasoning steps through the configured Agentforce model (Salesforce-managed by default, with options for selected third-party models in some regions). The model choice affects latency and cost more than capability for most production agents. Every step passes through the Einstein Trust Layer, which masks PII, applies data residency rules, and prevents prompts from being used for model training. Latency is dominated by action execution rather than reasoning. A turn that calls a slow external system feels slow regardless of how fast the engine itself is.
How to read a Plan Trace and act on what it tells you
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.
Trust & references
Straight from the source - Salesforce's reference material on Atlas Reasoning Engine.
- Atlas Reasoning EngineSalesforce Help
- Read the Plan TraceSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Atlas Reasoning Engine?
Q2. What is CRM data grounding?
Q3. Why does Atlas use chain-of-thought reasoning?
Discussion
Loading discussion…