Salesforce Well-Architected for Agentforce | SF Dictionary

You open the agent builder, wire up five topics, flip it to active, and ship it on a Friday. The agent works. Sales loves it. Three weeks later, a service rep notices the agent will gladly summarize compensation data from an opportunity record for any caller who asks nicely. The data was technically grounded for sales coaching, the agent was technically performing the task it was given, and the user was technically authenticated. No one wrote a bug. The agent just did what its permissions allowed it to do.

That is what an under-architected Agentforce deployment looks like in production. It is also the exact problem Salesforce evolved the Well-Architected Framework to address. At TDX 2026, the architect team unveiled "The Next Chapter of the Well-Architected Framework," a refresh of the three-pillar guidance built specifically for the agentic enterprise. The pillars are the same. The questions you have to ask under each one have changed completely.

This guide walks through what the framework is, what the TDX 2026 update changed, and how to apply each pillar when you are designing, reviewing, or fixing an agent. By the end you will have a three-question self-audit you can run against any Agentforce deployment you own.

What the Well-Architected Framework Actually Is

The Well-Architected Framework is Salesforce's official, opinionated guidance for designing solutions on the platform. It is not a certification, not a product, and not a checklist. It is a set of architectural principles grouped under three pillars: Trusted, Easy, and Adaptable. Each pillar has three sub-qualities, and each sub-quality has prescriptive recommendations and antipatterns.

The pillars, expanded:

• Trusted: secure, compliant, reliable
• Easy: intentional, automated, engaging
• Adaptable: composable, resilient, evolving

The framework lives at architect.salesforce.com/well-architected, and it has been there in some form since 2022. What is new is the lens. Until TDX 2026, the canonical examples were about Sales Cloud, Service Cloud, and integrations. The 2026 chapter rewrites those examples for a world in which the dominant unit of architecture is an AI agent.

Why It Changed at TDX 2026

Agents break the assumptions the framework was originally built on. A flow has deterministic branches. An Apex trigger fires on a known event. A Lightning page renders a fixed set of components. You can reason about all of them by reading the metadata.

An agent does none of that. It interprets natural language, selects from a library of topics at runtime, calls actions you defined but in an order you did not, and grounds its output on data retrieved on the fly. The same agent can be helpful in one conversation and dangerous in the next, depending only on what the user types.

The TDX 2026 session framed it bluntly: when the work product is non-deterministic, the architectural controls have to move up the stack. You stop asking "did this code run correctly?" and start asking "did this system make a defensible decision?" That shift touches every pillar.

The Architect Vista at TDX 2026 made this concrete with hands-on stations where attendees ran the same agent design through each pillar's lens and watched it fail differently under each one. The takeaway: no single pillar saves a poorly designed agent. You need all three.

Pillar 1: Trusted, For Agents Specifically

The Trusted pillar has always been about security, compliance, and reliability. For an agent, those words mean something more specific. An agent is a privileged user that never gets tired, never logs off, and will execute thousands of decisions per day. If its permissions are sloppy, you are one prompt away from a data leak, not one careless click.

Salesforce's official guidance for the agentic Trusted pillar centers on defense in depth, with three concrete layers.

Layer 1: Data Classification

You cannot protect what you have not labeled. Before an agent ever touches an object, every field that could matter for privacy, compliance, or commercial sensitivity needs a Data Classification value on it. PII, PCI, PHI, internal-only, public. This is the input that downstream controls rely on. Skip it and every later layer is guessing.

Layer 2: Secure Processing Boundary

The Agentforce architecture runs LLM calls through a Salesforce-controlled boundary, not directly to a model vendor. Prompts, grounding data, and responses pass through the Einstein Trust Layer, which masks PII before the prompt leaves the platform and unmasks it on the way back. No customer data is retained by the model provider, and zero data retention is enforced contractually. If you have ever had a security review veto a third-party AI vendor, this is the layer that makes Agentforce defensible in the same review.

Layer 3: Fit-For-Purpose Permissions

This is where most production agents quietly fail. The default temptation is to clone the running user's profile and let the agent inherit everything that user can do. That works on day one. It does not survive contact with a creative end user. The TDX 2026 Architect Securely session was explicit: the agent's running user should be a dedicated, minimally permissioned integration user with only the object, field, and action access the agent's published topics actually require. If a topic does not need access to compensation fields, the running user should not see them. Ever.

What an insecure agent looks like in practice: a service agent grounded on a Contact record returns a phone number that the calling user could not have seen in the UI because the field was hidden by field-level security on their profile, but the agent's running user is a System Administrator. That is the scenario every architecture review now has to assume will happen unless you have proven it cannot.

Pillar 2: Easy, For Agents Specifically

Easy is the pillar people skim. They should not. The three sub-qualities under Easy are intentional, automated, and engaging, and the TDX 2026 update reframed each one for agentic design.

Intentional means: every agent you build has a documented purpose, a defined audience, and a written success metric. If you cannot answer "what does success look like for this agent in 90 days" in one sentence, you are not building, you are vibing. The framework asks you to write that sentence down before you wire up the first topic.

Automated is where Salesforce has poured the most investment in 2026. The Summer 2026 Release brings the Agentforce Self-Service Help Agent to GA with a setup path that takes ten clicks or less. Ten clicks. The same release brings Einstein for Flow improvements that let you describe a flow in natural language and have it scaffolded for you. The point of these features is not that they save time, although they do. The point is that Salesforce is making the well-architected path the default path. If the easiest way to build an agent is also the one that respects the Trust Layer and uses fit-for-purpose permissions, fewer architects will get paged at 2 a.m.

Engaging is the sub-quality that gets reduced to "users like it" and dismissed. Do not dismiss it. An engaging agent is one that admits when it does not know, hands off cleanly to a human, and gives observability hooks for the people who own it. The Agentforce monitoring tools shipped in the 2026 cycle make engagement measurable: you can see which topics fire most, which fail silently, and which the user re-prompted three times because the answer was useless. If you are not reading those logs weekly, your agent is not engaging. It is haunting your org.

A practical test for the Easy pillar: hand the agent to a new admin in your team. If they can figure out what it does, where to change it, and how to tell whether it is healthy, in under thirty minutes, the architecture is intentional. If they have to ask three questions before they can even find the topic library, it is not.

Pillar 3: Adaptable, For Agents Specifically

Adaptable is the pillar that protects you from yourself in twelve months. Its sub-qualities are composable, resilient, and evolving.

Composable means the agent is assembled from independent, interchangeable parts. Data sources, topics, actions, channels, and grounding all live as separate components that can be swapped without rewriting the whole thing. The opposite, an agent where the prompt template hard-codes a specific field API name from a specific managed package, is the agent that breaks when finance migrates billing platforms next quarter.

Resilient means the agent degrades gracefully. If Data Cloud grounding is unavailable, does the agent answer wrong, or does it answer honestly with "I do not have access to that data right now"? If the Atlas Reasoning Engine fails over, does the conversation continue? The resilient design is the boring one: timeouts on every action, fallback responses for every topic, no single point of failure in the grounding chain. Boring saves jobs.

Evolving is the sub-quality that gets serious in 2026. Multi-Agent Orchestration goes GA in Summer 2026, and with it the expectation that an agent you build today will not be a single agent next year. It will be a specialist plugged into a primary agent, or a primary plugged into Agent Fabric, or a node in an Agent2Agent (A2A) topology with agents from Microsoft, Google, or ServiceNow. The Salesforce Multi-Agent Orchestration guide goes deeper on this. The Adaptable pillar's job is to make sure the agent you ship today does not have to be rebuilt to participate in that future.

Context persistence is the under-discussed enabler here. In Summer 2026, conversation context can be passed across agents during a handoff, which means a customer who starts in a service agent and is escalated to a sales agent does not have to restate anything. Composable, resilient, evolving. The pillar earns its name only if your design treats every part of the agent as replaceable.

A Three-Question Self-Audit For Any Agent

Theory is the easy part. Here is what I run through whenever I review an Agentforce design, mine or someone else's. Three questions, one per pillar.

Question 1 (Trusted): "What is the worst thing this agent can do if a curious user spends two hours probing it?"

If the answer is "leak a record they should not see," your running user has too much access. If the answer is "execute an irreversible action without a confirmation step," your action library is too generous. If the answer is "I do not know," you have not done the threat model yet. Write the worst-case down. Then design the controls that make it impossible, not unlikely.

Question 2 (Easy): "Can the person who will own this agent in six months explain it, monitor it, and change it without paging me?"

If they cannot, you have built a bespoke artifact, not a system. Document the purpose, the audience, the success metric, and the operational runbook. Use the standard monitoring tools instead of inventing your own. Set up alerts on the topics that matter. Make the boring observable.

Question 3 (Adaptable): "When the data model, the org structure, or the cloud landscape changes next year, what breaks?"

Run that thought experiment honestly. If the answer is "everything, because the prompt template hard-codes field names from a managed package we might replace," refactor now. If the answer is "the action library, because half of it calls a flow that is owned by a team that ships breaking changes weekly," put a contract layer between the agent and that flow. The point is not to predict the future. The point is to make sure no single future event can take the agent down.

Three questions. If you cannot answer all three with confidence about an agent you have already shipped, the design is not yet well-architected. That is fine. The framework exists so you have a path to fix it.

What To Do This Week

Go to architect.salesforce.com/well-architected and run the Well-Architected Assessment against the agent you are most worried about. The assessment is a structured questionnaire that scores your design against each pillar and surfaces the gaps. Pick the single highest-priority gap and fix it before you build anything new. If the gap is on the Trusted pillar, that fix is non-negotiable, do it this week. If it is on Easy, schedule it for the next sprint. If it is on Adaptable, get it onto the roadmap before the next quarterly planning cycle closes.

Then put a recurring calendar event on every quarter for the same review. The agentic platform is moving faster than any release cycle Salesforce has shipped in a decade. The framework is the lens that keeps your design current. Use it, or be surprised by it.

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.