#AgentforceBuilder19 discussing

Hi @Manohar Goud

This is a common issue when we work with multiple subagents and actions in Agentforce.

Here are a few things I would suggest: 

1. Clear Responsibilities: Give each subagent a specific job. Try to avoid overlapping responsibilities.
2. Proper Instructions: Clearly explain when to use a subagent, when not to use it, and what it should do.
3. Meaningful Names: Use clear names and descriptions for subagents and actions so Agentforce can understand their purpose.
4. Avoid Similar Actions: If two actions perform almost the same task, try to combine them or clearly separate their use cases.
5. Use Agent Script: For complex or critical scenarios, use conditions and explicit routing instead of depending completely on AI decisions.
6. Availability Conditions: Use available when conditions wherever applicable to control which subagents or actions can be selected.
7. Handle Unclear Requests: If the user request is confusing, let the agent ask a follow-up question instead of choosing the wrong action.
8. Test Multiple Scenarios: Test different ways users might ask the same question, including negative and overlapping scenarios.
9. Monitor Agent Behavior: Review session traces regularly to understand why a particular subagent or action was selected.

For example:

If we have three subagents for Order Inquiry, Order Cancellation, and Order Modification, each should have clear instructions about which requests it handles.

In my view, the best approach is to start with fewer subagents and actions, test them properly, and then gradually add more. 

One important point: Don't depend only on AI instructions for critical business processes. Use proper conditions, permissions, and validations to control execution.

Hope this helps! 

Thank you, 

Venkat Yadav.

Hey Jiyaulla,

Here’s how I would approach the solution design:

1. Agent Boundaries & Routing

• Split by persona: Don't build one monster agent. Keep Employee Desk (IT/HR Q&A via Knowledge), Coworker (sales/service reps on record pages), and OOTB Service Agent in clean, separate buckets.

• Topics & Hand-offs: Limit each agent to 4–6 tightly scoped Topics. Write explicit "When to use" instructions so the reasoning engine doesn’t cross wires. Always map human escalation via Omni-Channel, carrying the chat summary over.

2. Actions & Grounding (The Engine)

• Actions: Use Autolaunched Flows for standard CRM updates and Invocable Apex for external API lookups. Keep JSON outputs short; feeding raw multi-page payloads burns tokens and slows reasoning down.

• Flex Prompt Templates: Stick to a 4-part prompt: Role, Grounded Context, Guardrails (what NOT to do), and exact Output Format.

• Knowledge & Data Cloud: If grounding with PDFs or policies, ensure your Data Cloud search indexes chunk properly. Watch Field-Level Security—if the running agent user can’t see the field, the LLM hallucinates.

3. Trust, Guardrails & Security

• Einstein Trust Layer: Decide upfront if PII needs data masking and where audit logs get retained.

• Hard Refusals: Put explicit negative prompts inside each topic (e.g., "Never disclose salary bands; route user to Workday").

4. Licenses & Consumption Reality Check

• Cost control: Agentforce bills per conversation, and custom prompt calls burn credits. Don't use the LLM for things a simple Flow lookup or formula can solve deterministically.

• Token limits: Heavy record grounding causes latency spikes. Keep grounding payloads minimal.

5. ALM & Deployments (Where Projects Trip Up)

• Metadata API: Topics, Actions, and GenAiPromptTemplate deploy through standard DevOps pipelines (Copado, Flosum, SFDX).

• Manual Post-Deploy: Playbooks always break here. You must manually:
  1. Assign permissions and FLS to the Agent Execution User.
  2. Activate the Agent version in Target Org.
  3. Validate Data Cloud search index syncs.

Hey Karthick, 

The errors in your second screenshot tell you exactly what's wrong: 

"Action input 'Guests' in 'Create_Experience_Session_Booking' has primitive type 'number' and does not require 'complex_data_type_name'" 

"Action input 'startDate' in 'Get_Sessions' has primitive type 'date' and does not require 'complex_data_type_name'" 

Basically, someone (or the auto-generation) set a complex_data_type_name on these two inputs, but that field is only meant for object or list[object] type inputs. Since Guests is a number and startDate is a date, both primitive types, that field should be empty for them. 

Fix: 

1. Open the Create Experience Session Booking action, find the Guests input parameter, and clear out the complex_data_type_name value, leave it blank 

2. Do the same for the startDate input in the Get Sessions action 

3. Save, then check the Problems panel again, the 2 warnings under it are worth reviewing too but the 3 errors should clear once these two inputs are fixed 

These usually come from the action being generated off a Flow or Apex class where the parameter metadata got mismatched. If you're pulling these actions from a Flow, double check the Flow's input variable data types match what's expected (number/date, not a record/object type) before regenerating the action. 

Reference: