Every box in the Salesforce AI stack, and why it is there

A walk through the whole architecture in plain English, so you can follow a single question from the moment someone types it to the moment an answer comes back — and explain it to somebody else afterwards.

There is a particular kind of diagram going round at the moment. Boxes, arrows, a governance strip across the top, a row of operational concerns along the bottom. They are useful, and they all have the same flaw: they show you the components without telling you what any of them is for, which one you need first, or what happens if you skip it.

So this is the walk-through. Salesforce is the example because its architecture is unusually well documented and because a great many organisations already own it. But almost none of this is Salesforce-specific. The same boxes appear on every platform under different names, which is what makes the walk worth taking.

I have written it so you can follow one question end to end: somebody in a contact centre types a sentence, and something sensible comes back. Every box exists because of something that goes wrong without it.

The shape of the thing

Before any of the names, there are only four layers, and everything else is detail.

Data. What the system is allowed to know, and where that knowledge lives.

Reasoning. The model, and the retrieval that puts your facts in front of it at the moment it answers.

Action. What it is permitted to do once it has decided something — and whether it can act at all, or only advise.

Oversight. Everything that watches: the controls that stop it, the measurement that tells you whether it is any good, and the human who remains accountable.

Every box in every one of those diagrams belongs to one of those four. If you can place a component in the right layer, you can usually work out what it does without being told.

The teaching: "Data, reasoning, action, oversight. Four layers. If a component does not obviously belong to one of them, be suspicious of it."

Data and knowledge: the layer that decides quality

A team runs a pilot. The answers are wrong in ways nobody can quite explain, and the instinct is to try a better model. It rarely helps.

Salesforce calls its data layer Data Cloud, and its job is to assemble a unified profile of a customer from records that live in different places — service, sales, marketing, external systems — so that when an agent answers a question, it is answering about the actual customer rather than one system's partial view of them.

That matters more than the model does. A capable model reasoning over fragmentary data produces confident, wrong answers. A modest model reasoning over accurate, current, well-organised data produces useful ones.

This is the layer where most disappointment originates, and it is the least glamorous. Duplicate records, a superseded policy sitting alongside the live one, a field that three departments fill in differently. None of that is an AI problem, and all of it becomes an AI problem the moment you point a model at it.

The teaching: "The quality ceiling is set by the data, not by the model. Changing the model when the data is wrong is the most expensive way to stay where you are."

Retrieval: how your facts reach the model

The complaint arrives in a predictable form. "It doesn't know our products."

That sentence is almost never about the model's training. It is about retrieval.

A language model does not know your business. What makes it appear to know is that, at the moment a question is asked, the relevant pieces of your own material are found and placed in front of it. Salesforce does this through search over Data Cloud — matching on meaning rather than only on keywords, so a question phrased in a customer's words can still find a document written in yours.

Two consequences worth carrying.

The first is that adding more content does not reliably improve answers. Past a point it makes them worse, because the right passage becomes harder to find among near-duplicates. A smaller, curated, current corpus beats a comprehensive one.

The second is that anything requiring exactness — a balance, a total, a count — should come from a query against real data, never from the model's own arithmetic. The model is there to reason and to phrase, not to calculate.

The teaching: "'It doesn't know our products' is a retrieval problem. Fine-tuning teaches a model form, not facts."

Agents: the difference between advising and acting

This is the distinction that decides most architecture arguments, and it is worth being precise about.

Salesforce's agent platform is Agentforce. An agent there is built from topics — the areas it is allowed to handle — and actions, the specific things it is permitted to do within them.

That structure matters. A topic is a boundary, drawn deliberately, and an action is a capability granted deliberately. The agent is not free to improvise its way into any part of your business; it works inside a space someone defined.

Which brings the important line. Some assistants only advise: they read, summarise, suggest, and a person decides. Others act: they update records, trigger processes, send things. The gap between those two is not a feature difference, it is a risk difference. An advisor that is wrong produces a bad suggestion. An actor that is wrong produces a change to a real system, and changes do not undo themselves.

The teaching: "Ask of any agent: can it act, or only advise? Everything about how carefully you govern it follows from that answer."

Orchestration: how it decides what to do next

Somebody asks a question that touches three different parts of the business. Something has to decide where it goes.

Orchestration is the part that routes: reading the request, choosing the topic, selecting which action to invoke, deciding whether it has enough to answer or needs to retrieve more first.

There are two broad styles, and the difference is worth knowing because it recurs on every platform. In the deterministic style, someone drew the paths in advance and the system follows them. In the generative style, the system reasons over the available topics, actions and knowledge to work out its own route.

Deterministic is predictable and testable. Generative is flexible and handles the messiness of real questions. Most production systems end up combining them: reasoning at the edges where the conversation is unpredictable, and fixed, tested paths at the core where the outcome must be reliable.

The teaching: "Reason at the edges, be deterministic at the core. The parts that must always work the same way should not be left to a decision made fresh each time."

Integration: how it reaches everything else

An agent that can only see Salesforce is of limited use in a business that does not only run on Salesforce.

This is the connector layer: APIs, flows, and increasingly the Model Context Protocol — an emerging standard for exposing tools and data to a model in a consistent way, so that a capability can be built once and reused by many agents rather than wired up bespoke each time.

There is a governance point here that people miss, and it is the most important sentence in this section. Every tool you connect widens what the agent can do — and therefore what it could do wrong, or be manipulated into doing. Capability and blast radius are the same measurement viewed from two directions. A read-only connector and one that can move money are not the same kind of decision, however similar they look in a configuration screen.

The teaching: "Each new integration is a capability and an exposure at the same time. There is no version of this where you get one without the other."

Models and routing: what is actually underneath

Here is the fact that surprises people, and it is worth knowing before you walk into a conversation about it.

The model underneath Agentforce is Claude, from Anthropic. Salesforce did not build the reasoning engine; it built the platform around one, and it can work with others.

That arrangement is now normal, and understanding it changes how you think about the stack. The model is a component with a supplier, not the product. Which means it can be swapped, routed between, and priced — and that the interesting engineering is mostly not in the model at all.

Routing is the practice of sending each request to the model best suited to it: something small and cheap for the easy majority, something larger for the hard minority. Done well it saves a great deal of money. Done without a confidence signal and a fallback, it quietly degrades exactly the hardest cases, which are the ones that mattered.

The teaching: "The model is a supplied component, not the system. Once you see that, the questions change from 'which AI' to 'what have we built around it'."

The Trust Layer: the part that is genuinely different

Most platforms leave the safety controls to you. This is the one place where Salesforce's design is worth studying whether or not you use it.

The Einstein Trust Layer is not a product you add. It is embedded in the platform, and every interaction passes through it without anyone implementing separate controls.

What it does, before a prompt ever leaves the Salesforce environment: masks personal information, enforces zero data retention with the model provider, and records what happened for audit.

That combination is the interesting bit. Data retention with a model provider is the question every security team asks and few can answer confidently. Having it handled in the platform, by default, for everything, is a materially stronger position than a policy that depends on each team configuring it correctly.

And here is the detail almost nobody explains, which is worth carrying into any conversation about cost or latency. The Trust Layer does not run once per conversation. It runs several times in a single turn — once to classify and route the topic, once for each action that invokes a prompt, once for the retrieval that grounds the answer, and once for the final synthesis that produces the reply.

So a single question from a user is not one call. It is several, each with its own checks, its own tokens and its own moment of latency. If you have ever wondered why an apparently simple agent costs more and takes longer than expected, that is usually where it went.

The teaching: "One question from a user is not one call to a model. Understanding how many it really is explains both the bill and the wait."

The floor: the things that decide whether it survives

Everything above this line is what gets demonstrated. Everything below it is what determines whether the demonstration becomes something you can run.

Security and identity. Who the agent is acting as, and what that identity is permitted to reach. An agent surfaces what a user could already access — instantly, and by asking. It does not create oversharing; it makes existing oversharing discoverable, which is a different and more urgent problem.

Guardrails. Content filtering, toxicity checks, policy enforcement. Worth being clear-eyed here: a rule written into a prompt is guidance, not enforcement. Anything that must never happen belongs somewhere the model cannot be talked out of it.

Evaluation. A fixed set of realistic cases with known-good answers, run repeatedly. Without one, you cannot tell whether a change improved anything, because live traffic changes at the same time as your system does.

Observability. Traces of what the agent actually did, step by step. Not what it said it did. The most useful thing to build first, and the thing most teams add only after an incident.

FinOps. Cost per outcome rather than per token, which is the only version of the number that means anything to a business.

Human in the loop. Approval before consequential actions, escalation paths, and a named person who remains accountable. This is not a limitation to be engineered away. It is the thing that makes the rest defensible.

The teaching: "The top half of the architecture gets you a demonstration. The bottom half gets you something you can still be running in a year."

What to take from this if you are not on Salesforce

And most people reading this are not.

The names are Salesforce's. The structure is universal. Every serious platform has a data layer, a retrieval mechanism, an agent model with some notion of permitted actions, an orchestration approach, an integration surface, a set of models it routes between, and a governance layer wrapped around all of it. Microsoft has these. Google has these. So does anything you assemble yourself from open components.

Which means the useful thing to take away is not a product list. It is the set of questions.

What is this system allowed to know, and is that knowledge current and accurate? How do our facts reach the model at the moment it answers? Can it act, or only advise? Who decided what it may reach, and when was that last reviewed? What happens when it is wrong, and who finds out? And how would we know if the answers were getting worse?

A vendor diagram answers none of those. It shows you what exists, which is a different question from what you need, and a very different question from what you need first.

That is the honest limitation of every architecture picture, including the good ones. The boxes are real. The order you should build them in is not in the diagram, because it is different for every organisation — and because nobody selling a platform is well placed to tell you that most of it can wait.