Agentforce: Meridian PowerPack— Our Running Example for agentforce

💬 In plain words: Abstract concepts are hard to memorize. To understand how Salesforce Agentforce really works, we use one single running example throughout this guide: Meridian PowerPack. Meridian is a fictional electricity utility company. They sell power, read meters, dispatch repair crews, and handle billing disputes. By applying Agentforce features to Meridian's daily operations, the technical architecture becomes instantly clear.

📌 Key Points Covered in This Guide

• How to map standard Salesforce objects (Accounts, Cases, Work Orders) to an AI Agent's thought process.
• The difference between good AI use cases (unpredictable language) and bad ones (deterministic batch processes).
• How to use Data Libraries to ground your agent in reality, preventing dangerous hallucinations.
• Why you must split massive business requirements into specialized Subagents rather than building one mega-agent.
• How strict guardrails prevent your agent from making promises the company cannot keep.

🏢 Concept: Mapping CRM Data to AI Logic

Before an agent can solve a customer's problem, it needs to understand your business model. Large Language Models (LLMs) are incredibly smart, but they don't know how your specific Salesforce org is structured. Here is how Meridian PowerPack's real-world business translates into Agentforce terminology:

• The Customer: The household or business buying the electricity is the Account. The human actually chatting with the bot is the Contact.
• The Hardware: The physical electricity meter on the side of their house is the Asset. Their specific pricing plan is the Contract.
• The Problem: When the power goes out, the resulting ticket is a Case. When a repair truck rolls out to fix a downed line, that is a Work Order.
• The Brains: The chat window sitting on meridianpower.com is the Service Agent (customer-facing). The internal AI assistant that call-center staff use inside the Salesforce Console is the Employee Agent (staff-facing).
• The Integrations: Meridian's legacy billing system, which holds actual PDF invoices, is connected via an External Service using the Model Context Protocol (MCP).

⚡ Real-World Example: Anatomy of an Outage

Imagine a storm hits. A customer logs into the website and types: "My lights just went out, did a tree hit the line?"
1. The Agent Router reads this and hands the conversation to the Outage Management Subagent.
2. The Subagent uses a Tool (an Apex action) to check the customer's Asset ID against the live outage map.
3. The Subagent confirms the outage, automatically creates a Case, and replies with empathy, all without human intervention.

🛡️ Guardrails and Data Libraries

Generative AI is powerful, but it is eager to please. If a frustrated customer asks, "When will my power be back on? Promise me it will be today!", an unconstrained LLM might apologize and promise a 2:00 PM restoration just to be helpful. In the utility business, making false promises breaks regulatory compliance.

To stop this, we use strict Agentforce constraints:

• Guardrails: You configure systemic rules. For Meridian, a strict instruction might dictate: "Never quote an estimated restore time unless the Work Order status is explicitly marked 'Confirmed by Crew'."
• Data Library: If a customer asks a highly technical question (e.g., "Is a buzzing transformer dangerous?"), the agent searches the Data Library. This library is filled with approved engineering PDFs chunked in Data Cloud. The agent reads the official manual, grounds its response in verified facts, and tells the user exactly what safety steps to take.

// Example of a System Guardrail Prompt for the Outage Subagent:
"You are a utility service agent. 
If the customer asks for a restoration time, YOU MUST use the Check_ETA Tool. 
If the Tool returns null, you MUST state that crews are investigating and no time is available. 
DO NOT invent, estimate, or guess a time under any circumstances."

🧠 Memory Trick: One Outage, Whole Platform. Whenever you need to learn a new Agentforce module (like debugging traces, testing tools, or setting up Data Cloud), retell it as a Meridian story. Ask yourself: "What happens to the outage ticket in this layer?"

🧭 360 Card — Meridian Power Example

Rule: Use one single running example everywhere. Consistency beats variety when you are memorizing complex platform architectures.

Gain: You can answer any technical certification or interview question with a concrete, easy-to-follow story instead of reciting abstract textbook definitions.

Price: A made-up company is not proof you built anything. You must eventually pair this knowledge with a real project you shipped.

Limits: This is a study device. Real enterprise implementations will have messier data models and legacy technical debt.

Later: In a job interview, simply swap "Meridian" for the name of the actual client you worked for. The architectural structure remains exactly the same.

💡 Core Q&A: Identifying Good AI Projects

Q: Give me an example of a good Agentforce use case versus a bad one.

🎯 Say this first: A good use case involves unpredictable human language, like an outage report. A bad use case is a deterministic process, like a nightly billing run where nothing varies.

A: Let's use Meridian Power to make this concrete.

• The Good Use Case: A customer reporting an outage. They might type "power cut", "no electricity", "lights are off", or "the whole street is pitch dark." The words vary wildly, but the intent is identical. The agent uses its reasoning engine to classify the intent, check entitlement, and create a case.
• The Bad Use Case: Generating three million monthly bills every night at 2:00 AM. The steps never change. The input is perfectly structured rows in a database.

⚠️ Developer Trap: Do not throw AI at a problem just because it's new. If a process requires zero language comprehension and relies entirely on strict, repeatable data manipulation (like the billing run), use Batch Apex or a Schedule-Triggered Flow. Putting that behind an LLM agent would be incredibly slow, highly expensive, and burn through your digital wallet credits for zero added value.

🚀 Advanced Architecture Follow-ups

Q: The business wants one single agent to handle outages, billing, tariffs, meter readings, complaints, and new property connections. How do you respond?

A: Push back on the architectural shape, not the business ambition.

• What they are asking for is six entirely different business domains. Each domain requires several specialized Subagents.
• If you cram all of this into one massive agent, routing accuracy will plummet. The LLM will get confused by overlapping tool descriptions, and the system will hallucinate or fail silently.
• The Solution: You build distinct, specialized Subagents (e.g., a Billing Subagent and a Technical Support Subagent). The primary Agent Router acts as a receptionist, securely delegating the conversation to the correct specialist based on the customer's opening message.

Q: How does the agent interact with systems outside of Salesforce, like the legacy billing server?

A: Through secure APIs integrated as Tools. Meridian's actual invoices live in an external SQL database. We use MuleSoft or standard REST API callouts to connect to it. In Agentforce, we wrap that API in a Flow or Apex class, expose it as an Action, and assign it to the agent as a Tool. When the customer asks, "Why is my bill so high?", the agent dynamically decides to fire the API tool, fetches the raw data, and uses its LLM reasoning to summarize the charges in plain English.

Q: What happens if a standard chatbot rule conflicts with Agentforce logic?

A: Agentforce replaces the rigid, menu-driven decision trees of older chatbots. Legacy bots forced users to click "Press 1 for Billing, Press 2 for Outages." Agentforce uses natural language generation (NLG) and intent classification. If you are migrating from a legacy Einstein Bot, you strip out the rigid dialog trees and instead write clear instructions and tools for your Subagents, allowing the AI to navigate the conversation fluidly.

🔗 Connecting the dots: Now that you know how to structure the agent, how do you actually write the descriptions that tell the Agent Router which Subagent to pick? (Hint: It involves mastering the art of concise metadata prompt engineering!)