🚀 Mastering Agentforce Subagents: before_reasoning & after_reasoning Guardrails

💬 In plain words: When building AI agents in Salesforce Agentforce, before_reasoning and after_reasoning are two optional logic blocks inside a subagent. One runs exactly before the AI thinks, and one runs exactly after. They contain hard logic (code), not prompt suggestions. This is where your absolute, unbreakable rules must live.

📌 Example: A utility company verification agent checks if a caller actually owns the meter in the before_reasoning block. Later, it escalates any refund request above $100 inside the after_reasoning block. Neither of these critical business decisions is left up to the AI language model.

🔑 Key Points

• Code Over Prose: Natural language prompts are suggestions; logic blocks are mandates.
• Setup vs. Validation: before_reasoning is ideal for setup and data verification, while after_reasoning is perfect for clamps, logging, and escalations.
• Transition Trap: If an agent hands off the conversation to another agent during its reasoning phase, the original after_reasoning block gets skipped entirely.

🏗️ The Subagent Execution Concept

In Salesforce Agentforce architecture, every subagent follows a strict lifecycle. Here is exactly how these blocks fire during a user request:

subagent
├─ before_reasoning   → Runs FIRST on every request.
│                       Logic only. Verify, setup, or transition away.
├─ reasoning          → AI processing (Instructions + Tools).
└─ after_reasoning    → Runs LAST on every request.
                        Logic only. Clamp values, escalate, log data.
                        ⚠ SKIPPED if transitioned away mid-reasoning!
  

🧠 Before sets up, after guards. Both contain hard logic, and both run on every request—unless the AI transitioned the conversation away first.

🎬 Real-Life Example: The Guard That Never Ran

The Old/Bad Way: A development team placed a strict refund ceiling inside the after_reasoning block on their billing subagent. It passed all tests in the sandbox. But in production? Massive refunds still slipped through.

Why this fails: During failing production conversations, the AI agent decided to transition to an escalation subagent partway through its own reasoning. When a subagent transitions away mid-thought, its own after_reasoning block never executes. The refund ceiling was bypassed exactly when it was needed most.

The New/Good Way: You have two secure options. Either move the ceiling check into the destination subagent being transitioned to, or run the check before the transition can happen (using the before_reasoning block).

The Payoff: The security guard now stands precisely at the door everyone actually walks through, rather than where the code simply looks the neatest.

⚠ INTERVIEW TRAP: Never tell a hiring manager or architect that a guardrail inside after_reasoning "always runs." It does not run if the subagent transitions away. Explicitly naming this exception is the answer that separates senior architects from the crowd.

🧭 360 Card Summary

• Rule: Put anything that absolutely must happen in a directive block (logic), and structurally ensure it will actually run.
• Gain: You get a coded guarantee rather than a polite request to the LLM. The AI model isn't consulted on the rule; it is forced to obey it.
• Price: Logic is split across three distinct places in a single subagent, meaning readability suffers slightly.
• Limits: Prompt text is strictly disallowed in these blocks. Remember the mid-reasoning transition skip behavior.
• Performance at Volume: Because before_reasoning runs on every single user request, keep the logic lightweight. Heavy API calls here mean you pay a massive latency tax on every conversational turn.

Core Q&A

Q: Where would you put a business rule that must absolutely never be broken?

🎯 Say this first: In a directive logic block—either before_reasoning or after_reasoning. Never in an instruction sentence or prompt.

A: A rule written in prompt prose is merely a request to the LLM. A rule written in logic is a strict control. Neither of these logic blocks accepts prompt text, so there is no way for a clever user to "talk past it" and trick the AI into bypassing the rule.

Q: How do you decide between using the 'before' block versus the 'after' block?

A: Use before_reasoning for data setup, user verification, or routing checks before the AI wastes processing time. Use after_reasoning for clamping output values, triggering escalations based on what the AI decided, or writing mandatory logs. But remember to check your transition paths—if the agent might hand off the chat during reasoning, critical rules must be moved to the front or placed in the destination agent.

Q: Can I use AI prompt piping inside these logic blocks?

A: No. Neither block supports prompt piping or text generation commands. They are strictly reserved for logic: running background actions, setting variables, and forcing hard transitions.