Agentforce interview questions and answers

Not quite. Einstein Copilot was the one assistant in the Lightning header for logged-in users. Agentforce is the platform it got folded into and renamed — Copilot Builder is now Agent Builder, and the same Topics and Actions carry over. The part that matters is scope: Agentforce also covers customer-facing Service Agents, which run as their own agent user on a channel you wire up, and which inherit nothing from a logged-in user.

Same lineage, wider scope. Copilot was one in-org assistant; Agentforce is the platform that replaced it, and underneath it is still the same metadata — GenAiPlugin for a Topic, GenAiFunction for an Action. What I would actually say is what changed behind the rename. Copilot ran inside the logged-in user's session, so its access was theirs. An Agentforce Service Agent talking to a customer has no logged-in user at all: it runs as a dedicated agent user, and that user's profile is the whole ceiling on what it can read. That is the migration trap — an Action that worked in Copilot because the human had access does nothing on a Service Agent until the agent user's permission set says it can.

First, where the sentence came from: the trace for one of those conversations shows the Topic, the Action and what the retriever returned. If "shipped" came out of the index I have a freshness problem; if it came out of an Apex Action I have a query bug — different days of work. Assuming the index: three lags are stacked up — the data stream run, the job that lands it in the DMO, and the search index refresh — and a day out usually means that stream runs nightly. The real fix is not grounding status on an index at all. Status has one owner, so that Topic gets a deterministic Action against the live Order record, and the retriever keeps what changes monthly, like the returns policy.

Same first move — read the trace before touching the pipeline, because "stale grounding" and "wrong Action" look identical from a transcript. Then I would push back on the design rather than the schedule. A Data Cloud retriever is semantic search over a copy, and it is the right tool for prose that changes monthly. Order status is a single-owner fact that changes by the minute, so it belongs in a deterministic Action against the live record, inside the roughly 60 seconds an Action gets. If the business genuinely insists on the index, then the honest version is a freshness contract: the retriever returns the timestamp, the agent states it — "as of six this morning" — and we accept a known lag rather than an unknown one. Either way the change gets a case in Agentforce Testing Center built from a record modified after the last refresh, because otherwise this regresses the next time someone re-points the retriever and nobody finds out until support does.

Two separate questions, and people answer only the first. Turning it on needs the admin to hold Customize Application, Data Cloud User, Use Setup with Agentforce (or Use Agentforce) and Execute Prompt Template, which I bundle into a permission set group. Running it needs an agent user: a real user record the agent executes as, which is the security context for every Action. That user needs the object and field access, the record access through sharing, the Apex class enabled on its permission set, run access to the Flow, and Data Cloud access if a retriever is involved. The failure mode is quiet — an Action the agent user cannot execute raises nothing the customer sees, it just stops being an option, so it reads as the agent choosing not to help.

I care about which user, and about the direction the mismatch runs, because it goes wrong both ways. A customer-facing Service Agent has no logged-in human at all — it runs as a dedicated agent user, so that user's profile is both the floor and the ceiling on the conversation. It inherits nothing from the customer. That means least privilege on a purpose-built user, never a real person's account, and never Modify All Data to make an Action work. The other direction is nastier: an employee agent's Apex Action runs in system mode by default, so it can read fields the person typing cannot, which is how a restricted value ends up in a reply. WITH USER_MODE on the query, or Security.stripInaccessible, is the fix, and it belongs in the Action rather than in the instructions. Data Cloud is a third surface again — the index a retriever answers from is governed by Data Cloud's own field and row policies, not by the CRM field-level security on the source object, so I scope what gets ingested instead of assuming CRM sharing carries over.

A Prompt Template is one input, one generation, no decisions. Hand it a record and it drafts the email or summarises the Case, grounded on merge fields, a related list, a Flow or a retriever, and I can call it from code with ConnectApi.EinsteinLLM.generateMessagesForPromptTemplate. If someone already knows what they want and there is exactly one thing to produce, that is the entire job — cheaper, and repeatable, because nothing is choosing anything. I reach for an agent when the input is a conversation rather than a record, or when the work takes more than one step: read the order, work out whether it can still be cancelled, cancel it, tell the customer. If I can write the step order down in advance, I do not need an agent for it.

The dividing line is whether anything has to be decided at runtime. A Prompt Template is a deterministic call with a non-deterministic body — same inputs, same grounding, one generation, and it either succeeds or throws where I can see it. An agent adds a planner on top: it classifies, chooses an Action, evaluates the result and may loop. That buys me multi-turn work I could not script, and it costs me determinism, latency and a metered call per Action that the agent stops waiting for after about 60 seconds. I ask what the user is actually holding. A record open in front of them and a button? Prompt Template, and often a Flow around it. A typed sentence I cannot predict, needing two or three tool calls to answer? Agent. The mistake I see most is an agent built for a one-Action Topic — all the reasoning overhead and none of the benefit, when a Prompt Template behind a button would have been faster and testable. Worth saying out loud: a Prompt Template cannot decide to call a tool, cannot ask a follow-up question and has no memory of the last turn.

Turn it into a diff and a test set, in that order. The instructions are not a text box in Setup, they are metadata: they ride inside the Topic, a GenAiPlugin within the agent's GenAiPlannerBundle, so that bundle is what I retrieve and compare with Friday morning's version in the repo. The diff names the exact instruction, Action description or scope that moved, which beats anybody's memory of a Friday afternoon. Then I pull the failing questions verbatim out of the transcripts and run them through Agentforce Testing Center against both versions, so I have a before and after instead of an opinion. If production holds the only copy and there is no history, that is the actual finding: an agent whose instructions are edited live has no rollback.

The diff and the utterance set are the mechanics; the finding is process. An agent's instructions are the least testable surface it has — in the natural-language instruction model there is no precedence I can rely on and nothing a compiler will catch — so the only regression signal that exists is a saved set of utterances run before deploy. Nobody kept one here, so building it from the transcripts is part of the fix, not overhead. Once I can see the GenAiPlannerBundle diff I would also ask whether the change belonged in instructions at all. "Prefer the shipping article for delivery questions" is a Topic scope or an Action description, both of which the planner reads at classification time and both of which I can test on their own. Buried in a paragraph of instructions it competes with every other sentence in there, silently. So: restore Friday morning, prove it with the utterance set, re-land the intent in the layer that can be tested, and stop editing agent metadata in Agent Builder against production — that is what turned a one-line change into a three-day investigation.

A Topic is a job the agent is allowed to do, like checking an order. Its Actions are what it can run for that job — an Apex method, a Flow, a Prompt Template. Instructions are plain-English rules that apply once it is inside that Topic. It picks the Topic first, then an Action from inside it — so if it picks the wrong Topic, the Action you wanted is not even on the table.

Three layers, and the order they fire in is the whole answer. The agent classifies the message into exactly one Topic, reading the Topic descriptions to do it. Then it picks an Action from that Topic's list — a Flow, a Prompt Template, or an Apex @InvocableMethod — reading the Action descriptions. Instructions are natural-language rules scoped to the Topic, and they only apply after classification already happened. That ordering is the limit people miss: if the message lands in the wrong Topic, the right Action is not even a candidate, and no instruction anywhere else in the agent rescues it. Which is why I spend my time on Topic boundaries and keep them narrow, rather than one Topic with thirty Actions hanging off it.

I treat them as a classifier, a tool registry and a policy layer, because they fail differently. Classification is the expensive failure: the planner reads Topic descriptions and picks one, so two Topics that both talk about cases route by coin-flip and the Action I wanted is out of scope before any instruction runs. Action selection is the cheap failure, and it usually means the @InvocableMethod description reads like a code comment instead of a sentence about when to use the thing. Instructions are the layer I trust least: in the natural-language instruction model, precedence is not something I can rely on, and nothing about a paragraph of prose is testable. Every one I add is another thing that can contradict an earlier one, and the agent will not tell me which won. So in practice — narrow Topics whose descriptions use the words users actually type, Action descriptions written for the planner rather than for me, instructions kept for tone and escalation. Then I prove it in Agentforce Testing Center with real utterances, because none of this is verifiable by reading it.

The Einstein Trust Layer sits between the org and the model. It masks patterns like payment card and Social Security numbers before the prompt leaves. It holds the model provider to zero retention, so nothing you send is stored or trained on. It scores the reply for toxicity and logs the exchange for audit. What it does not do is decide who may see what — that is still sharing and field-level security.

Easier to remember as two directions. On the way out it masks the PII patterns you have configured, defends against prompt injection, and grounds the prompt in your data instead of letting the model answer from training. Salesforce's agreement with the model providers is zero retention, so your prompts are not kept on their side. On the way back, the response is scored for toxicity, masked values are put back, and prompt, response and score land in an audit trail. The limit worth saying out loud: masking is pattern matching. It catches a payment card number. It has no idea that Internal_Margin__c is confidential, and it is not an access-control layer — if the agent user can read a field, the Trust Layer sends it happily.

It is a data-handling guarantee, and people hear it as a correctness guarantee. What I can defend in a security review: prompts and responses are not retained or trained on by the provider, configured PII patterns are masked outbound and demasked inbound, responses carry a toxicity score, and every exchange is auditable — which is genuinely most of what a compliance team asks for. What I have to say in the same breath is what it does not check. It does not know whether the answer is true; grounding reduces invention, it does not eliminate it. It does not stop a badly scoped Action writing a wrong value to a record. It is not field-level security, so an @InvocableMethod running in system mode will hand it data the user could never open, and the Trust Layer will pass that straight through. And masking has a cost I have to design around: mask the order number and the model can no longer echo it back to the customer, so I mask what is sensitive and not everything, then run synthetic data through Agent Builder and read the trace before anyone real is on the other end.

Selection is a reading problem, so I fix the text the planner reads instead of adding rules on top. "Creates a Case" and "Gets a Case" are the same sentence to a classifier. They become "use only when the customer is reporting something new that has no case yet" and "use when the customer refers to a problem they have already reported", and I prove the change in Agentforce Testing Center against the real utterances, ambiguous ones included. Then the inputs, which is where I would bet the money: if Get Case Status demands a Case number the customer never types, the planner takes the Action it can run — and Create Case needs nothing at all.

The trace first, because "chose the wrong Action" and "chose the right Action and could not fill its inputs" are different bugs. If Get Case Status has a required @InvocableVariable for a Case number the customer never has, the planner drops to the Action that needs nothing — and that is fixed in the Action, by accepting a description and a rough date and doing the lookup, not in the instructions. Then the descriptions, which are the actual interface: "Creates a Case" against "Gets a Case" gives the classifier nothing to separate, so each one gets a sentence about when to use it in the words a customer would say. If they still collide I split the Topic — Report a New Problem and Check an Existing Case — because a Topic boundary is a harder line than a description, and only the chosen Topic's Actions are candidates at all. Then Testing Center with the real utterances and the near-misses. And I would say the limit plainly: I can make the boundary unambiguous, I cannot make it certain, so anything irreversible gets a confirmation step rather than trust.

Find the path first, because the trace says whether the value came from the Apex Action or the retriever, and they are different fixes. If it was the Action, that is ordinary Apex: an @InvocableMethod runs in system mode unless you say otherwise, so its SOQL saw a field the running user cannot. WITH USER_MODE on the query, or Security.stripInaccessible before I build the response, plus a test that asserts a restricted user gets nothing back. Returning only the fields the answer needs would have stopped it outright. If it was the retriever, the field has to come out of the DMO mapping and the search index has to be rebuilt — a permission set will not fix that.

Path before patch, because there are three sources and only the trace says which one it was. If the Apex Action produced it — the common case — this is not an Agentforce bug at all: an @InvocableMethod runs in system mode by default, so its query outran the rep's field-level security. The fix is WITH USER_MODE, or Security.stripInaccessible(AccessType.READABLE, records) before building the response, with a test that runs as a restricted user and asserts the field is absent. Better still, return the answer, not the record: an Action that hands back one sentence cannot leak a field nobody asked for. If the retriever produced it, it is slower to fix — the index is governed by Data Cloud's own field and row policies, not the CRM field-level security on the source object, so CRM sharing does not carry over and the DMO mapping is the grant list. The field comes out of that mapping and the index gets rebuilt. Then containment, because the value is in the transcript and the Trust Layer audit trail, so it gets said out loud, not quietly patched. The rule I take away: the agent user's access is the ceiling on what an agent can leak, so least privilege, and Actions return answers, not rows.

Mechanically it is an @InvocableMethod — static, one per class, taking a List of an inner request class and returning a List, with each input marked up as an @InvocableVariable. Then register it as an Agent Action, attach it to a Topic, and grant the class on the agent user's permission set. What decides whether it ever runs is none of that: the planner reads the label and description on the annotation and the description on each variable, and nothing else. It never sees the body. So description='Cancels an order' competes badly against a sibling Action, and description='Use when the customer asks to stop an order that has not shipped' wins. A vague description is a working Action that is never chosen.

The signature is the easy half — what decides whether it ever runs is prose. I write the description the way I would explain the tool to a new colleague, in the words a customer would use, and I say when not to use it, because that is what separates it from the Action next to it. The subtler failure is inputs: if a required @InvocableVariable is something the agent cannot get from the conversation — an internal Id, say — the planner quietly prefers the Action it can fill, and I will swear the descriptions are fine. So inputs are things a person says out loud, and the Action does its own lookup. The half people forget is the return value, because the model paraphrases whatever I hand back, failures included. An Action that throws gives the agent nothing to say, so it improvises; one that returns "no order matches that number" hands it the sentence. Which is why I keep the Action a thin entry point over a service class — testable with no agent involved, bulk-safe under ordinary governor limits, querying WITH USER_MODE so it cannot outrun the asker's access, and idempotent, because the loop can call it twice for one intent.

The Atlas reasoning engine runs a loop rather than a script. It reads the message and classifies it into one Topic, then builds a plan: which Action from that Topic to call, and what inputs it needs. Grounding is pulled in on the way — merge fields, a Flow, or a Data Cloud retriever. The Action runs as the agent user, under normal Apex governor limits and with roughly 60 seconds before the agent gives up on it. The engine evaluates what came back and either loops for another step or phrases the reply. The Einstein Trust Layer wraps both ends: masking and prompt defence outbound, toxicity scoring, demasking and the audit entry inbound.

Classify, plan, ground, act, evaluate, answer — and then possibly all of that again, which is the part that matters. Three consequences I design around. First, scope: only the Actions on the Topic it classified into are candidates, so a misroute makes the correct Action invisible and no instruction elsewhere gets a vote. Second, retries: the loop can call an Action more than once for a single intent, so everything it calls has to be idempotent — a RefundOrder Action that is not will refund twice, and that is a real incident, not a theoretical one. Third, budget: each Action is metered and time-boxed, so long work goes to a Queueable and the agent says it has started instead of blocking the turn. And the honest limit — the same sentence can plan differently on two runs. "It worked when I tried it" is not evidence about an agent. A saved set of utterances in Agentforce Testing Center is, and when something misbehaves I read the Interaction Summary in Agent Builder to see which Topic and Action it picked, not a stack trace.

The forecast is usually wrong about the unit, not the volume. Under Flex Credits the meter runs on Agent Actions — as of Summer '26 an Agentforce Action is metered at 20 Flex Credits and a Voice Action at 30 — so an agent calling a grounding Action, a lookup and a summary every turn costs several times what a per-conversation estimate assumed. So I go and get the Actions per session out of the transcripts, then cut them: grounding that fires only when it is needed, retrieval that returns a short answer rather than a record dump, and cheap deflection in front of the agent for the questions a static article already answers. Nothing caps spend per conversation at runtime, so this is a design fix rather than a monitoring one.

Find out which meter the contract is on first, because the levers differ. On Flex Credits the meter runs per Agent Action — as of Summer '26, 20 credits an Action and 30 for a Voice Action — so cost tracks Actions per turn, and an agent that grounds, looks up and summarises on every turn is three times the forecast at the same conversation count. On pay-per-resolution the shape inverts: a session bills once, so long unresolved conversations are cheap and useless, and the number to watch is resolutions rather than Actions. Then the usual culprits, and they are design faults every time: a grounding Action wired to fire unconditionally, a reasoning loop re-planning because an Action returned something it could not use, and traffic the agent should never have taken. The levers I actually have are all design levers — fewer Actions per Topic, retrieval that returns an answer rather than rows, deflection in front, a session timeout. Digital Wallet shows me the burn and lets me reconcile it; it does not stop a conversation mid-turn. There is no runtime governor that caps spend per conversation, which is exactly why this has to be designed rather than monitored.

Four, in order of how much machinery they need. Merge fields and record context are free and exact, but reach only the record in front of you and its lookups — no search. A Flow or Apex grounding Action — an @InvocableMethod whose query I write myself — is live and precise, and costs a governed Apex transaction on the critical path of the turn. A Data Cloud retriever over a search index searches documents and articles semantically, and costs ingestion, index refresh and a freshness lag. Knowledge grounding is that same retrieval pointed at published articles, so it inherits your article hygiene. The limit behind all four: the agent knows only what you ground, and grounding more is not better — every chunk spends context and can bury the one that mattered.

I pick by two questions: is the answer a fact or a document, and how fresh does it have to be. A fact with one owner — order status, balance, whether the warranty is live — gets a deterministic Action against the record. Never an index, because an index is a copy with a refresh schedule and status changes continuously. A document — policy, troubleshooting, anything written in prose — gets a Data Cloud retriever, where semantic search earns its keep. Then the costs, and money is the least interesting one. Tokens: everything I ground is prompt, so a retriever returning 10 chunks makes every turn slower and dumber than one returning two. Latency, which the customer feels. Freshness, which is a design decision with a bill, not a bug. And permission surface, the one that gets skipped — the index is governed by Data Cloud's own field and row policies, not by the CRM field-level security on the source object, so I treat the DMO mapping as the grant list and scope what gets ingested. If I cannot ground it, I say so in the Topic and hand off instead of letting the model improvise.

When the rules are already written down. A discount over 20% needs the regional director — that is an Approval Process, and it is right every single time. A field that must never be blank when Stage is Closed Won is a validation rule. Dunning emails at 6am for overdue invoices is a Scheduled Flow. Wrapping any of those in an Agent Topic buys a metered Action, a reasoning step that can decide differently tomorrow, and a worse audit trail, in exchange for nothing. My test is whether I can write the step order down in advance. If I can, the platform already has a deterministic tool for it, and an agent that is right 98% of the time on an approval is a finding.

Four situations, and only one of them is about the technology. First, determinism: if the decision fits in a formula, an Approval Process or a Scheduled Flow, it belongs there. Those are testable and auditable, and a rule keyed on StageName is right every time — a reasoning loop cannot promise that. Second, no grounding: if the answer lives in a PDF nobody has ingested into Data Cloud, the agent has nothing to be right from, and building it anyway ships a confident guesser. Third, no measurement — if nobody can tell me what a good conversation looks like or who reads the transcripts, there is no way to know it works and no way to tune it, so it drifts and nobody notices. Fourth, no exit: a customer-facing agent with no handoff to a human traps people, and that costs more than the deflection saves. The version I say out loud to a client is simpler. An agent earns its cost when the input is a sentence you cannot predict. When the input is a record and the rule is known, you are paying per Action for non-determinism you did not want.