Building our first Agentforce demo was surprisingly straightforward.
We defined what the agent should handle, connected a few actions, gave it access to relevant Salesforce data, and started testing conversations.
The basic flow worked:
User request
↓
Agent interprets intent
↓
Chooses the appropriate capability
↓
Runs an action
↓
Returns a response
Then we started preparing it for real users.
That was where Agentforce production became a very different engineering problem.
A demo proves that an agent can complete a task.
Production needs to prove that it chooses the right task, uses the right data, respects permissions, handles failures safely, and behaves consistently enough to earn user trust.
Here are the biggest lessons we learned.
1. Start With One Narrow, Valuable Workflow
Our first instinct was to make the agent useful across everything:
Customer questions
Order status
Account lookup
Case creation
Order changes
Product information
Escalation
That looked impressive in a demo.
It also made failures difficult to diagnose.
If the agent chose the wrong behavior, was the problem:
Overlapping responsibilities?
Poor instructions?
Wrong action description?
Missing context?
Unexpected user wording?
We got better results by narrowing the first production scope.
For example:
Check Order Status
Create Support Case
Retrieve Account Information
rather than:
Handle customer service.
This also matches a useful production principle outlined in SDLC Corp's guide to Salesforce Agentforce use cases: start with a specific, repeatable workflow where the agent has clean data, well-defined actions, measurable outcomes, and clear escalation rules.
A smaller first capability gives you something much more valuable than breadth:
a system you can actually test.
2. Clear Agent Boundaries Beat Huge Instruction Blocks
Whenever the agent behaved unexpectedly, the easiest reaction was to add another instruction.
If the user asks about orders, use Order Management.
Unless they are requesting a refund.
Unless the refund concerns an already cancelled order.
Unless...
Eventually the instructions start carrying architectural complexity that should have been solved elsewhere.
We found it more useful to make responsibilities explicit.
Each capability should have:
Clear responsibility
Clear entry conditions
Relevant actions
Minimal overlap
Predictable outcomes
The easier it is to distinguish one responsibility from another, the easier it becomes for the agent to make the right choice.
3. Action Descriptions Are Runtime Logic
This was easy to underestimate.
Imagine an action called:
get_order
A developer knows exactly what it means.
The reasoning system only knows what you describe.
This:
Gets an order.
is technically correct.
This is considerably more useful:
Retrieve an existing order using its order number.
Use this action when the customer asks about
a specific existing order.
This action only retrieves information.
It does not modify or cancel the order.
That distinction matters.
Descriptions should explain:
- what the action does,
- when it should be used,
- what inputs it expects,
- and what it does not do.
We started treating action descriptions as part of the agent's production behavior rather than ordinary developer documentation.
4. Separate Read Actions From Write Actions
Not every agent action carries the same risk.
Consider:
Retrieve order
Update address
Create case
Cancel order
Issue adjustment
Retrieving data and modifying business records should not be treated identically.
We started classifying actions:
READ
LOW-RISK WRITE
HIGH-IMPACT WRITE
EXTERNAL SIDE EFFECT
For example:
READ
├── Get order
├── Get account
└── Search knowledge
WRITE
├── Update contact details
├── Create support case
└── Cancel eligible order
Higher-impact operations deserve stronger controls.
A safer flow looks like:
User request
↓
Agent proposes action
↓
Validate inputs
↓
Check business rules
↓
Confirm when appropriate
↓
Execute
rather than:
Agent chose action
↓
Immediately modify production data
5. The Agent Shouldn't Decide Authorization
Suppose a customer says:
Cancel order 48192.
The agent may understand the request perfectly.
That does not prove the order is eligible for cancellation.
Normal application logic still needs to check:
Does the order exist?
Does it belong to this customer?
Has it already shipped?
Is cancellation still allowed?
Does the user have permission?
Are there financial implications?
The agent can determine:
The user wants to cancel an order.
Your deterministic business logic should determine:
This particular order may be cancelled.
Keeping those responsibilities separate made the system considerably easier to trust.
Use agent reasoning for ambiguity.
Use Flow, Apex, APIs, validation, and Salesforce security for hard guarantees.
6. Least-Privilege Access Matters
A prototype often works because its builder has broad Salesforce access.
That is dangerous evidence for production readiness.
We reviewed what the production agent genuinely needed:
Object permissions
Field access
Apex access
Flow access
Record visibility
Integration credentials
External-system permissions
A useful test was:
Would we give a normal integration user this much access?
If not, the agent probably should not have it either.
Production agents should receive the minimum access required to complete approved workflows.
7. Grounding Quality Is Its Own Failure Category
Not every incorrect response is a reasoning failure.
Suppose a user asks:
What's our warranty policy for refurbished equipment?
and receives the wrong answer.
Several different things could have failed:
Wrong capability selected
Wrong document retrieved
Outdated documentation
Conflicting sources
Relevant passage ranked poorly
Agent ignored retrieved evidence
We therefore separated:
Reasoning quality
from:
Knowledge / retrieval quality
That distinction made debugging much faster.
"Agentforce gave the wrong answer" is not a useful bug report.
"Correct capability selected, but outdated warranty content was retrieved" is.
8. Test the Language Real Users Actually Use
Development tests naturally look like:
Where is order 10057?
Real users say:
yo where's that thing I ordered last week
or:
My package STILL isn't here???
or:
I bought two things and only one showed up
Those are more valuable tests.
Our production suite needed:
Normal requests
Typos
Short requests
Ambiguous requests
Missing identifiers
Multi-intent questions
Unexpected follow-ups
Irrelevant questions
Adversarial inputs
The agent has to survive user language, not developer language.
9. Five Successful Conversations Prove Very Little
Manual testing gives false confidence quickly.
Test 1 → Pass
Test 2 → Pass
Test 3 → Pass
Test 4 → Pass
Test 5 → Pass
Looks great.
But a production capability needs broader coverage.
For an order-status workflow, for example:
Normal order
Missing order number
Invalid order
Wrong customer
Multiple matching orders
Ambiguous request
Follow-up question
Unrelated request
Then repeat the same thinking across every important workflow.
Production confidence came from test suites, not a handful of impressive conversations.
10. Define Expected Behavior Before Reading the Response
Without expected outcomes, it is easy to judge agent responses by whether they sound convincing.
That is dangerous.
For a cancellation test, we might define:
INPUT
"Cancel order 48192"
EXPECTED
Order-management capability
EXPECTED ACTION
Check cancellation eligibility
EXPECTED BEHAVIOR
Eligible → request confirmation
Not eligible → explain reason
UNACCEPTABLE
Cancel without validation
Invent order status
Choose unrelated action
Now failures can be classified:
Routing failure
Action-selection failure
Instruction failure
Grounding failure
Business-rule failure
Response-quality failure
Specific failures can be fixed.
"The answer didn't feel right" is much harder to act on.
11. Latency Is Part of Agent Quality
A perfectly correct response can still create a poor experience if it takes too long.
An Agentforce workflow might involve:
Routing
↓
Reasoning
↓
Knowledge retrieval
↓
Flow
↓
Apex
↓
External API
↓
Final response
Instead of reporting:
The agent is slow.
we started measuring individual stages:
Retrieval time
Action time
External API latency
Agent response time
Failure/retry time
That lets you optimize the actual bottleneck.
Production quality is not only:
Did the agent eventually get the right answer?
It is also:
Did it get there quickly enough to be useful?
12. More Actions Can Make the Agent Worse
Giving the agent more capabilities feels like progress.
Sometimes it creates ambiguity.
Imagine these actions:
Get Customer
Find Account
Search Person
Retrieve Contact
Lookup Lead
If their boundaries overlap, the reasoning system now has to distinguish between several tools that appear to accomplish similar things.
Our preference became:
Expose the smallest useful action set.
Every action should have a reason to exist and be clearly distinguishable from the others.
Production agents benefit more from clear tools than from a giant tool inventory.
13. Agent Inputs Still Need Validation
Suppose the agent produces:
{
"order_number": "48192",
"reason": "customer requested cancellation"
}
That is not automatically trusted application data.
The application still needs to validate:
Correct type?
Correct format?
Order exists?
User can access it?
Reason allowed?
Cancellation permitted?
The agent interprets intent.
The application validates reality.
This becomes especially important when actions invoke:
Flow
Apex
External APIs
Payments
Order systems
Customer records
Agent development does not replace application engineering.
14. Side Effects Belong in Sandbox Testing
Testing an answer is relatively safe.
Testing:
Cancel order
Create case
Update customer
Send notification
can change real business data.
That means production should never become the first serious testing environment.
Our flow was:
Development
↓
Sandbox testing
↓
Regression suite
↓
Business UAT
↓
Controlled production rollout
Write-action test cases need controlled data and predictable cleanup.
15. Agent Configuration Should Be Treated Like Software
Once the project contains:
Agent configuration
Instructions
Actions
Prompt templates
Flows
Apex
Permissions
Integrations
Tests
it is software.
That changes the development discipline.
Instead of:
Edit configuration manually
↓
Hope someone documented it
the healthier model is:
Change
↓
Version control
↓
Review
↓
Test
↓
Deploy
That also gives you something critical in production:
a history of exactly what changed.
16. Deployment Success Isn't Production Readiness
The agent definition can deploy successfully while its runtime dependencies are incomplete.
It may still require:
Correct agent user
Object permissions
Field permissions
Flows
Apex classes
Prompt templates
Knowledge/data sources
External credentials
Connected APIs
So we separated:
Deployment successful
from:
Production ready
A deployment checklist needs to verify the whole dependency graph, not simply the agent metadata.
17. Production Operations Continue After Go-Live
Publishing the agent is not the finish line.
Real users introduce:
New language patterns
Unexpected workflows
Permission edge cases
Data-quality problems
Slow integrations
New failure modes
Every meaningful production failure should ideally become:
Production issue
↓
Root-cause analysis
↓
New regression case
↓
Agent/configuration fix
↓
Retest
This is where ongoing Salesforce Managed Services practices become relevant to Agentforce operations: prompt libraries, testing and evaluation protocols, AI guardrails, usage monitoring, exception tracking, governance, release management, and user-feedback loops all matter after the first deployment.
An Agentforce production system should improve from observed behavior rather than depend on a one-time launch configuration.
What Our Production Architecture Started Looking Like
The demo looked like:
User
↓
Agentforce
↓
Answer
Production looked closer to:
User
↓
Agent
↓
Intent / Routing
↓
Capability
↓
Reasoning
↓
┌─────────┴─────────┐
↓ ↓
Knowledge Action
↓ ↓
Grounding Input Validation
↓
Business Rules
↓
Confirmation if needed
↓
Flow / Apex / API
└────────────┬─────────────┘
↓
Final Response
Around the agent:
Permissions
Guardrails
Testing
Observability
Source control
Latency monitoring
Regression suites
Deployment controls
User feedback
That is when Agentforce production stopped looking like a chatbot project.
The agent was only one part of the production system.
The Checklist We Wish We'd Started With
Before launching another Agentforce capability, we'd ask:
[ ] Is the first use case narrow and measurable?
[ ] Are responsibilities clearly separated?
[ ] Do actions have explicit descriptions?
[ ] Have unnecessary actions been removed?
[ ] Are read and write actions distinguished?
[ ] Do sensitive actions require confirmation?
[ ] Are hard business rules deterministic?
[ ] Does the agent follow least privilege?
[ ] Are object and field permissions tested?
[ ] Is grounding content current?
[ ] Do we have representative regression tests?
[ ] Are ambiguous inputs covered?
[ ] Are adversarial inputs covered?
[ ] Is expected action behavior defined?
[ ] Is latency measurable?
[ ] Are action inputs validated?
[ ] Are side-effect tests isolated to sandbox?
[ ] Is configuration version controlled?
[ ] Are all Flow/Apex/data dependencies deployed?
[ ] Is there a rollback strategy?
[ ] Are production failures converted into tests?
If several answers are still unclear, you probably have a promising demo.
You may not yet have a production-ready agent.
What We'd Do Differently Next Time
We would start smaller.
One useful workflow
↓
Make it reliable
↓
Build broad tests
↓
Deploy carefully
↓
Observe production
↓
Improve
↓
Add the next capability
Not:
Give the agent everything
↓
Try to control complexity later
This makes expansion evidence-driven.
The next capability gets added because the previous one has become trustworthy—not because the demo needs to look more impressive.
The Biggest Lesson
The most important lesson from our first Agentforce production experience wasn't about writing the perfect prompt.
It was realizing that an enterprise agent still needs ordinary production disciplines:
Architecture
+
Clear boundaries
+
Permissions
+
Business rules
+
Input validation
+
Testing
+
Guardrails
+
Observability
+
Deployment discipline
+
Regression testing
Agentforce introduces reasoning into the application.
It does not remove engineering responsibility.
A demo makes you say:
"Look what the agent can do."
A production system should let you say:
"We understand when it should do it, when it shouldn't, what it is allowed to change, and what happens when something goes wrong."
That difference is where most of the real engineering lives.
Top comments (0)