💬 In plain words: One example company runs through this whole notebook: Meridian PowerPack, an electricity utility. It sells power, reads meters, fixes outages, and sends bills. Every module retells one part of that business as an agent problem.
📌 Example: Follow one outage. A customer reports it. The agent checks whether the meter is theirs. It looks up the outage map. It creates a case. It refuses to promise a restore time.
Concept
- The household or business that buys power = Account. The person who calls = Contact.
- Each electricity meter = Asset. Its tariff plan = Contract.
- A reported outage or bill dispute = Case. A crew visit = Work Order or Task.
- A rule like "never quote a restore time that is not confirmed" = a check in
after_reasoning. - The engineer manual PDFs the agent quotes from = a Data Library.
- The chat window on meridianpower.com = a Service Agent.
- The panel the call-centre staff use in Lightning = an Employee Agent.
- The billing system that holds the actual invoice = an External Service or MCP tool.
🧠 One outage, whole platform: to revise any module fast, retell it as a Meridian story. What happens to the outage here?
🧭 360 Card — Meridian Power — Our Running Example
Rule: Use one running example everywhere. Consistency beats variety when you are memorising.
Gain: You can answer any question with a concrete story instead of an abstract definition.
Price: A made-up company is not proof you built anything. Pair it with something you actually shipped.
Limits: None technical. This is a study device.
Mirror — a fresh example per topic: More interesting to read, much harder to recall under pressure.
Later: In an interview, swap Meridian for the client you actually worked for. The structure carries over.
Core Q&A
Q: Give me an example of a good Agentforce use case and a bad one.
🎯 Say this first: Good: an outage call, where the words vary wildly. Bad: the nightly billing run, where nothing varies.
A: Use Meridian to make it concrete.
- Good use case: A customer reports an outage. They might say "power cut", "no electricity", "lights are off", or "the whole street is dark".
- The words vary, the intent is one thing, and the agent needs to check entitlement and create a case.
- Bad use case: Generating three million bills every night. The steps never change and the input is structured.
- That is Batch Apex. Putting it behind an agent would be slower and cost credits for nothing.
- The dividing line is not difficulty. It is whether the input is unpredictable language.
Follow-ups (Scenario-Based)
Q1: The business wants one agent to handle outages, billing, tariffs, meter readings, complaints, and new connections. What do you say?
A1: Push back on the shape, not the ambition.
- That is six domains. Each needs several subagents, and the ceiling is 15 per agent.
- Routing accuracy also falls as descriptions crowd together, and the failure is invisible.
- The answer is one agent per domain, or an orchestrating agent that delegates to specialist agents.
- Common mistake: Agreeing, building one giant agent, and discovering the ceiling three sprints in.