Introduction
My first Agentforce agent could update customer addresses, check order status, and answer common questions about sales orders. On paper, it was exactly what our support team needed—a way to handle the endless stream of "Where's my order?" requests so our reps could focus on complex customer issues.
It took me a couple of tries to get it right.
The difference between my failed attempts and the final working version?
Learning that the word "may, can" is dangerously vague for AI instructions
You can't bolt security on as an afterthought
The best automation knows when to step aside for human judgment.
Today, I'm sharing the three critical mistakes that were made—and how I fixed them. If you're building your first Agentforce agent, these lessons will save you weeks of frustration.
The Problem that Was Solving
Support reps were drowning in repetitive requests:
"Where's my order?"
"Can you change my delivery address?"
"What's the status of my case?"
"How do I return something?"
These weren't complex questions. They were just... constant. Meanwhile, critical situations desperately needed human attention: angry customers with legitimate complaints, complex technical issues requiring investigation, and high-value accounts needing personalized consultation. But our skilled reps were stuck answering the same basic questions repeatedly.
The goal: Automate the repetitive work so humans can focus on what actually requires human judgment, empathy, and creativity.
What the agent needed to handle:
Provide case updates and order status
Change delivery addresses (with verification)
Answer general product questions
Handle routine FAQs
What it should never do:
Replace humans for critical customer escalations
Make complex judgment calls alone
Compromise customer satisfaction for efficiency
The philosophy guiding everything: AI transformation can't stop business operations. We augment support, we don't replace the human touch when it matters most.
Mistake #1: Treating Security as an Afterthought
First Attempt (Disaster)
Instruction (Version 1):
You are a helpful customer support agent. Help customers
with their orders and cases. Be friendly and provide
accurate information.
Sounds reasonable, right? It's friendly, it's clear about being helpful. What could go wrong?
Everything.
The agent was too helpful. A customer would say "What's the status of order #12345?" and the agent would immediately look it up and provide full details. No questions asked. No verification required.
🚨 Complete security nightmare.
The Fix: Authentication First, Always
Security can't be bolted on. It has to be the foundation.
Instruction (Version 2):
You are a Customer Support Agent.
CRITICAL - AUTHENTICATION FIRST:
Before providing ANY order or case information, you MUST
verify customer identity using their unique Customer ID.
AUTHENTICATION PROCESS:
1. Ask the customer for their Customer ID
2. Verify it matches the account in the system
3. Only after successful verification, proceed with assistance
DO NOT:
- Provide order details without a verified Customer ID
- Accept email addresses or names as verification methods
- Bypass authentication for "urgent" requests
- Share any account information before verification
Authentication Flow:
Agent asks customer for their Customer ID
System checks if the ID exists and matches an account
If match found → ✅ Verified → Agent proceeds
If no match → ❌ Rejected → Agent asks to try again or transfers to human
Why this matters:
Customer trust
Legal compliance (GDPR, CCPA, HIPAA)
Business survival
Reputation
Mistake #2: Using Vague Language That Invited Chaos
The Problem with "May"
Instruction (Wrong):
You may help customers update their delivery address
if they request it. You can verify their information
and make changes as needed.
Result: unpredictable behavior, hallucinations, skipped verification.
The Fix: Directive Language
Instruction (Correct):
You MUST verify customer identity before any address updates.
You SHOULD NOT update delivery addresses if:
- The order has already shipped
- The new address is international (escalate to human)
- Customer verification fails
You MUST follow this exact process:
1. Confirm current delivery address with customer
2. Ask for the complete new address
3. Repeat the new address back for customer confirmation
4. Update the record only after customer confirms
5. Send confirmation email
6. Log the change with timestamp
Words that work: MUST, SHOULD NOT, ALWAYS, NEVER, ONLY Words to avoid: May, Could, Might, Perhaps, Try to
Mistake #3: Thinking Automation Means "Handle Everything"
Automation ≠ better results.
The Temptation
“Our AI can handle almost anything! Let’s maximize efficiency by automating everything we can!”
The Reality
Angry customers don’t need order status—they need empathy and accountability.
The Fix: Human-in-the-Loop by Design
Escalate immediately if customer:
Uses emotional language (angry, furious, lawsuit, etc.)
Asks for a manager or human
Has high-value order (>$5,000)
Mentions competitors
Requests refunds/account changes
Describes problems outside training
Escalation process:
Acknowledge concern with empathy
Connect to a specialist immediately
Create High Priority case with summary
Transfer to human queue
Provide full conversation context
What I Learned: The Real Success Factors
Security isn’t optional — authentication first, no shortcuts.
Language precision prevents hallucinations — directive words create predictable behavior.
Human touch is irreplaceable — empathy and judgment can’t be automated.
Meta-lesson: Building an Agentforce agent isn’t about the AI. It’s about:
Understanding business processes deeply
Setting clear boundaries
Knowing when humans add irreplaceable value
Protecting customer trust and data above all else
Get these basics right, and the technical execution becomes easy. Get them wrong, and no amount of fancy AI can help you.
Coming Up in Part 2
These three mistakes taught me what NOT to do. But I still had critical questions about the technical architecture:
Action permissions: What can agents actually modify? (Spoiler: never give delete access, and be very careful with updates)
Topic organization: How do you structure agent knowledge so it doesn't get confused when customers ask about multiple things?
Mental models: Why did my first attempt fail even though I thought I "understood" the process?
Agentforce Done Right: Permissions, Topics, and Why Your Brain Needs Organizing First.
I'll share the architectural decisions and organizational strategies that transformed my chaotic first attempt into a reliable production agent.
Don't miss it! Follow me here on Dev. to so you get notified when Part 2 drops next week.
Good luck with your first Agentforce Agent, and share your experience.
Top comments (2)
Wait so you tell the agent to handle the auth? never do this.
Make sure in code the agent is only ever displayed to authenticated user and can only ever operate within that user's scope. For example, the query tools like 'findOrders' should already be filtering by that user (outside of the agent's control).
If you rely on the LLM for security you'll get hacked real fast.
You’re absolutely right — that was the mistake we encountered when building our very first agent. To address it, we implemented bridge authentication as an intermediary step.
Now, whenever a customer launches the agent and requests assistance, the initial action is a bridge API call to verify the customer. Only if the verification succeeds does the agent proceed with providing information.