Agentforce Architecture: The Technical Foundation of Autonomous Agents

The Shift from Reactive to Autonomous Execution

Every prior Salesforce AI feature — Einstein Lead Scoring, Next Best Action, Einstein Bots — follows the same pattern: the platform computes a recommendation, a human or a workflow acts on it. The intelligence and the execution are separated. Agentforce collapses that separation. An agent receives a goal, reasons about how to achieve it, selects tools to call, calls them, evaluates the result, and continues — all within a single conversation turn or across multiple turns — without requiring a human to approve each step.

This is what the industry means by "agentic": the AI is not advising; it is acting. For architects, the implication is significant. Every decision you make about what an agent can access, what actions it can invoke, and under what circumstances it should escalate to a human has direct operational consequences. A misconfigured flow invoked by a human is caught before it does damage. A misconfigured action invoked by an agent at scale is not.

Topics, Actions, and the Instruction Layer

An Agentforce agent is defined by three things: its system prompt (the role and behavioural instructions), its Topics, and its Actions. Topics are logical groupings of intent — they tell the agent which domains it is responsible for and how it should approach requests that fall within those domains. Actions are the discrete operations the agent can invoke: Apex methods, flows, external API calls, or prompt templates.

When a user (or system) sends a message, Atlas — Agentforce's reasoning engine — classifies the request against the agent's Topics. If the message matches a Topic, Atlas identifies the relevant Actions available within that Topic, determines which action to invoke based on the instructions and the current conversation context, calls it, and then evaluates whether the result satisfies the goal or whether additional steps are needed.

Topics are not routing rules: A common design mistake is treating Topics as static intent classifiers — the same role that utterances played in Einstein Bots. Topics in Agentforce are more open-ended. They describe the scope of what the agent handles and the approach it should take, rather than mapping specific phrases to specific outcomes. This flexibility is powerful but also the source of most non-determinism: the agent's behaviour within a Topic is shaped by the LLM's interpretation of the instructions, not by a deterministic decision tree.

The Atlas Reasoning Engine

Atlas is the Salesforce-hosted reasoning layer that sits between the LLM and the platform. It is responsible for the reasoning loop: receiving the user's input, determining what action to take, executing it, evaluating the result, and deciding whether the goal is achieved or further steps are needed. Atlas is not a single LLM call — each turn in an agentic conversation may involve multiple LLM invocations: one to classify intent, one to plan the next action, one to formulate a response.

The reasoning loop in Agentforce follows what Salesforce calls a "plan-act-observe" cycle. Atlas plans what to do based on the current goal and available Actions. It acts by invoking the chosen Action. It observes the result and updates its understanding of the current state. It then repeats the cycle until it determines the goal is complete, it cannot proceed (escalation), or it hits a configured limit.

Grounding is applied at the Atlas layer: Before Atlas passes context to the LLM, it retrieves relevant data from the org — CRM records, Einstein Search results, Data Cloud unified profiles — and injects them into the prompt. This is the grounding mechanism. The LLM never has direct access to Salesforce data; it only sees what Atlas retrieves and includes in the prompt. This is also how the Trust Layer enforces data access: Atlas applies the running user's sharing rules and field-level security when retrieving records to include in the grounding context.

How Agentforce Connects to Data and Systems

Agentforce Actions can invoke three types of operations: Flows (Screen Flows or Autolaunched Flows), Apex (invocable methods), and external API calls via named credentials. Each type has different implications for what the agent can do, how it is governed, and what can go wrong.

Flows are the primary recommended mechanism for Actions because they are declarative, auditable, and can be changed without a deployment. An agent that updates a case status, creates a task, or sends a notification via a Flow benefits from all of Salesforce's built-in record-level security and field-level security enforcement. The Flow runs in the context of the named credential or the running user, depending on how the Action is configured.

Apex invocable methods are appropriate when the logic is too complex for a Flow or requires performance optimisations that declarative tools cannot achieve. The tradeoff is that Apex bypasses some of the guardrails that Flows enforce by default. Any Apex method exposed as an agent Action needs explicit security review — it is running at the agent's instruction, not a human's explicit trigger.

External API calls expand the agent's reach beyond Salesforce but introduce a different risk surface: the agent can send data externally. Named credential governance, outbound firewall rules, and explicit data classification of what the agent is permitted to transmit are not optional if agents can invoke external APIs.

Security Model and Guardrails

Agentforce's security architecture operates at multiple layers. The Trust Layer is the brand name for Salesforce's suite of guardrails: it includes the data masking that prevents sensitive data from being sent to the LLM, the toxicity filters that block harmful outputs, and the audit logging that records what the agent did and why.

At the platform level, the Einstein Trust Layer intercepts every prompt before it is sent to the LLM and applies two operations: data de-identification (masking field values that are classified as PII based on org-level classification settings) and content policy enforcement. The LLM receives a version of the prompt where sensitive values have been replaced with tokens. The response is re-hydrated with the original values before being returned to the agent. This means the LLM never processes the actual sensitive data — only a token representation of it.

At the agent level, guardrails are configured in the agent's system prompt and via Topic-level instructions. You can specify that an agent should never take actions above a certain risk threshold without human confirmation, that it should decline requests outside its defined Topics, and that it should escalate to a human agent in specific scenarios. These are instructions to the LLM — they are effective for most cases but are not cryptographically enforced. A sufficiently clever adversarial prompt can sometimes bypass LLM-level instructions. For high-risk operations, the guardrail needs to exist at the Action level, not just in the instructions.

Capacity, Limits, and Design Constraints

Agentforce is metered. Every agent conversation consumes Einstein Conversation credits, and each Action invocation within a turn consumes additional capacity. For architects designing agents intended to run at volume — high-traffic customer service channels, fully automated back-office processes — understanding the credit consumption model is not optional; it directly affects the business case and the architecture.

Conversation turns are limited within a single session, and the reasoning loop has a maximum number of iterations per turn. These limits are intended to prevent runaway agents that loop indefinitely, but they also constrain the complexity of tasks an agent can complete in a single turn. Complex multi-step processes may need to be broken across multiple sessions, which introduces state persistence requirements. Agentforce does not natively persist intermediate state between sessions — if a multi-turn workflow is interrupted, you need an external state store (a custom object or a Platform Event queue) to resume correctly.

The LLM context window is another hard constraint. As the conversation history grows, Atlas must decide what context to retain and what to truncate. Very long agent sessions where the agent has invoked many Actions and accumulated substantial conversation history will begin to lose earlier context, which can cause the agent to repeat steps it has already taken or forget earlier decisions. Design long-running agent workflows to externalise state rather than relying on the LLM's in-context memory.