💬 In plain words: A user needs two separate grants before an agent is useful to them. One lets them use the agent at all. The other lets the agent reach data. They fail in completely different ways. 📌 Example: A Meridian rep is granted every object the agent touches, but not Agent Access. The agent simply does not appear for them. Nothing is wrong with the data model. 🎬 Real-Life Example: The Agent Nobody Could Find The Old/Bad Way: An admin built an agent, activated it, tested it in preview, and told the team it was live. Nobody could see it — including the admin, outside preview. Why this fails: Agent Access is a separate grant inside a permission set. Building an agent does not grant you the right to use it. Preview bypasses this, which is exactly why the gap goes unnoticed. The New/Good Way: 1. In the permission set, find the Agent Access section. 2. Add the specific agent to the enabled list. 3. As...
⚡ 1-Minute Summary
• An agent understands language, decides what to do, and acts. A chatbot only answers.
• Every example in this notebook uses one company: Meridian Power. Same company, every module.
• Learn the 360 Card first (0.5). It is the shape of every good answer: rule, gain, price, limits.
Module map
MODULE 0 root: 'What is Agentforce, and how do the modules fit
together?'
├─ 0.1 The map: one agent, six layers
├─ 0.2 Meridian Power — the example company
├─ 0.3 Key terms in plain words
├─ 0.4 The rename map (2024-2026)
└─ 0.5 The 360 Card — how to answer any question
0.1 The Map: One
Agent, Six Layers
💬
In plain words: Agentforce looks like many products. It is
not. It is one agent with six layers stacked under it. Each layer answers one
question, and each module of this notebook lives on one layer.
📌
Example: A customer types "my power is out." Identity
decides whose data can be touched. Routing picks the outage specialist.
Reasoning builds the prompt. Actions create the case. Grounding supplies the
outage map. Operations records what happened.
Concept
• Read the layers bottom to top. Each one
stands on the layer below.
• 1. Identity — which user the agent runs as. Question: what may it touch?
• 2. Reasoning — how one turn is built and resolved.
• 3. Routing — which specialist handles this message.
• 4. Doing — actions, and the script that ties them together.
• 5. Knowing — grounding, prompt templates, retrieval.
• 6. Trusting — determinism, guardrails, security.
• On top sits operations — where the agent runs, how you test it, what it costs, how you ship it.
• If an answer feels lost in an interview, name the layer first, then go one step down.
AGENT
├─ Identity → which user, which permissions
├─ Reasoning → how one turn resolves
├─ Routing → which subagent handles it
├─ Doing → actions + Agent Script
├─ Knowing → grounding, templates, retrieval
└─ Trusting → determinism, guardrails, security
Operations on top: channels, testing, cost, ALM
🧠The stack: "I Reason, Route, Do, Know, Trust." Identity first, trust last. Name the layer, then go one step down.
🧠360 Card — The Map: One Agent, Six Layers
Rule: name the layer before you answer. Identity, reasoning, routing, doing, knowing, trusting.
Gain: you never freeze. Every Agentforce question belongs to exactly one layer.
Price: it is a mental model, not a Salesforce feature. Do not quote it as product architecture.
Limits: 20 active agents per org. 15 subagents per agent. 15 actions per subagent.
Mirror — feature-list thinking: you can name every button and still not explain why an agent misbehaved.
Later: this map is also your revision order. Weak on a layer means weak on its modules.
At volume: one agent cannot span a large enterprise. The 15-subagent ceiling forces an orchestrator plus specialists.
⚠
INTERVIEW TRAP: Do not open with a feature list. Interviewers
hear "Agentforce has topics, actions, and Data Cloud" from everybody.
Open with the layer the question lives on.
Core Q&A
Q:
Explain Agentforce to someone who knows Salesforce but has never built an
agent.
🎯 Say this first: It is one agent with six layers under it — identity, reasoning,
routing, doing, knowing, trusting.
A: Start with what makes it different from a
chatbot.
• A chatbot follows a decision tree somebody
drew in advance. Off the tree, it fails.
• An agent reads the request, picks one
specialist, and calls real actions that write to Salesforce.
• Underneath, six layers. Identity decides
which user it runs as, and that is the hard ceiling on what it can touch.
• Reasoning turns your instructions into a
finished prompt before the model is ever asked.
• Routing picks exactly one subagent. Doing is
the actions. Knowing is grounding.
• Trusting is where you decide which parts the
model is allowed to influence at all.
• The stronger answer names the layer the
question is really about, rather than listing features.
Follow-ups
(scenario-based)
Q1: Where does Data 360 sit in that picture, and
is it required?
A1: It sits on the knowing layer, and it is required only for some
grounding.
• Record data, related lists, Flow and Apex
grounding need no Data 360 at all.
• Retrieval from documents does — that is where
Data Library, search index and retriever live.
• Common mistake: saying Agentforce needs Data
Cloud. It does not, unless you are grounding on unstructured content.
• One more dependency worth knowing: the
Einstein Trust Layer settings page needs Data 360 before it will display.
Q2: A stakeholder asks why you would not just
build this in Flow. What do you say?
A2: Frame it as predictability of input, not capability.
• Flow is right when the steps are always the
same and the input is structured.
• An agent earns its cost when the input is
human language and the path varies.
• Flow is also free. Agent conversations
consume credits, so volume matters.
• The architect answer: most real solutions use
both. The agent handles the conversation, the Flow does the deterministic work
behind it.