Mastering Salesforce Agentforce Guardrails: Instructions vs. Filters

💬 In plain words: An instruction tells an AI model what it should do. A filter (or guardrail) controls what an AI model can do. A determined user can always manipulate an AI into ignoring what it "should" do, but nobody can bypass hard-coded system filters that dictate what it "can" do.

⚡ Key Points

• Instructions are just suggestions: Text prompts like "Never offer more than a 15% discount" can be overridden by a persuasive user.
• Filters enforce hard limits: Using an after_reasoning logic flow to hard-cap a discount at 15% is a true guardrail.
• Filters reduce costs: By hiding tools dynamically (using conditional logic) instead of just telling the AI not to use them, you save on token usage and improve routing speed.
• Security requires physical boundaries: "The agent will not say it" is a weak instruction. "The agent cannot read the data" is a strong security filter.

🏗️ Core Concept: "Should" vs. "Can"

The distinction between should and can is the sharpest design principle you can apply when building bots with Salesforce Agentforce.

• "The agent will not do it" simply means you asked the AI nicely in the prompt.
• "The agent cannot do it" means you structurally removed its ability to perform the action.

If you want to test the strength of your Agentforce design, ask yourself this simple question: What happens if a user spends ten minutes actively trying to break this rule? If the answer relies on the AI "holding its nerve" against a manipulative prompt, you've built an instruction, not a guardrail.

🎬 Real-Life Example: The Discount That Kept Growing

The Old/Bad Way: A development team wrote "never offer more than a 15% discount" into the Agentforce subagent's prompt instructions and shipped it to production. Within a week, a persuasive customer argued their way into a 40% discount.

Why this fails: An instruction is just one sentence in a massive context window. The Large Language Model (LLM) weighs your instruction against everything else, including a highly aggressive or logical customer argument. Under enough pressure, the AI caved.

The New/Good Way:

1. The AI generates a proposed discount figure and stores it in a variable.
2. An after_reasoning logic block (a Salesforce Flow or Apex action) intercepts the variable, compares it to the 15% maximum, and forces it down to 15% if it exceeds the limit.
3. The subagent is instructed to only state the final approved figure from the variable, completely bypassing its own judgment.

The Payoff: The number is physically capped by system logic before the AI even speaks. The customer’s persuasion tactics now have absolutely nothing to act on.

🗺️ Visualizing the Difference

Here is a quick cheat sheet for converting weak instructions into strong filters:

SHOULD (Weak Instruction)          CAN (Strong Filter / Decision)
-------------------------          ------------------------------
├─ 'never offer >15%'              ├─ Clamp variable in after_reasoning
├─ 'do not discuss X'              ├─ Hide the tool using tool-level criteria
├─ 'only if confirmed'             ├─ Branch logically on a stored variable
└─ Fails under prompt injection    └─ Structurally immune to manipulation

🧭 360 Card — Instruction vs. Filter
Rule: Anything involving a hard number, a financial transaction, or a legal consequence requires a logic-based filter. It must never be left as a prompt instruction.
Gain: Your system holds up under adversarial pressure and prompt injection attacks.
Price: Filters take more time to build. Changing a hard-coded business rule now requires a deployment rather than simply tweaking a text prompt.
Limits: You cannot use logic filters to control subjective things like "tone of voice" or "empathy." Those must remain as instructions.
Connects to: AI Trust Layer, Tool Availability Rules, Agentforce Guardrails.

⚠ INTERVIEW TRAP: Defining Guardrails
If you are interviewing for an AI or Agentforce role, do not claim that a prompt instruction is a guardrail. Interviewers ask this question specifically because confusing an instruction with a hard guardrail is the most common and dangerous misunderstanding in Generative AI development today.

🎯 Core Q&A

Q: What is the exact difference between an instruction and a guardrail in Salesforce AI?

🎯 Say this first: It comes down to "should" versus "can". An instruction asks the model to behave a certain way. A guardrail physically removes the possibility of the model breaking the rule.

A: While they might look similar in a design document, they behave completely differently in production.

• An instruction is text in a prompt. The LLM weighs your text against the user's input. A manipulative user can easily "talk past" an instruction.
• A guardrail is a definitive filter—usually Apex logic, a Flow, or a strict tool availability rule—that intercepts the process. It either sets a hard limit on a value or hides a capability entirely.

For example, if you are building an AI to handle refunds, you don't say "Do not refund more than $50." You build an after_reasoning logic block that caps the output variable at $50 before the API call is made. The rule is simple: if a constraint protects money, data, or legal liability, it must be a filter.

🧠 Core Takeaway: A user's prompt can argue with an instruction. It cannot argue with a system-level control. Build your Agentforce actions assuming the user will try to break them.