Everyone wants to buy it. Almost no one has the architecture for it.
Agentforce is being bought as a product and deployed as though it were a feature. It is neither. It is an execution framework whose behaviour is entirely determined by boundaries you define — and if you do not define them, it will still do something.
Connect a large language model to a messy CRM without explicit operational limits and you have not bought automation. You have deployed a highly articulate system that will confidently fabricate data, promise discounts you do not offer, and surface records the requester should never see.
ReAct: it cannot do what you have not built
The reassuring part of the architecture is that Agentforce does not improvise actions. It runs a ReAct — Reasoning plus Acting — loop, meaning it reasons about intent and then invokes an explicitly defined Action. If no Action exists for a task, the agent cannot perform it.
This is the control surface. Everything the agent can do to your data is something a person deliberately built and exposed.
Three pillars, and the failure if you skip one
Topics are the job description — they bound what the agent will engage with at all. An agent scoped to Service Resolution declines pricing questions rather than inventing answers.
Instructions are the natural-language guardrails: when an Action may fire, and what must be collected first.
Actions are the execution layer. The agent cannot write to the database directly; it passes parameters to an Apex Invocable or Autolaunched Flow, which executes under the standard Salesforce permission model. That last clause matters more than anything else in this document.
Keep the decision in the code
The most important pattern in the blueprint is where judgement lives. Financial and access decisions must be evaluated server-side, in Apex, and returned to the agent as a single flag — not handed to the model as raw numbers with an instruction to decide.
An agent told “if lifetime value is high, offer a discount” will interpret “high”. An agent told discountAuthorized: false has nothing to interpret. The blueprint carries five Custom Actions with their exact system prompts and accompanying Apex, structured so the LLM handles language and your code handles consequences.
What’s inside
- The hallucination trap — why an ungoverned agent is an articulate liability
- Custom Actions with exact system prompts, not vibes
- Apex invocables as the deterministic execution layer
- Scoping record access so the agent cannot expose what it should not see
- Preventing the agent from promising discounts you do not offer
- Where the LLM decides versus where your code decides — the boundary line
- A reference architecture you can hand straight to your build team
