Explanation:

Why A is correct:

The question provides two critical diagnostic clues:

• Score reason: "ambiguous subagent match"
• Session Trace: "reasoning engine is consistently selecting the wrong subagent on most turns"

These clues point directly to a semantic overlap problem between subagent configurations. The Atlas Reasoning Engine selects subagents by evaluating their Description (natural language classification) and Entry Conditions against the user's input. When two or more subagents have overlapping, vague, or poorly scoped descriptions, the engine becomes "confused" and picks the wrong one.

The most viable solution is to refine the classification descriptions of the competing subagents. This means:

• Making each subagent's Description distinct, specific, and mutually exclusive (e.g., instead of "handles all billing questions," using "handles payment method changes and invoice disputes").

• Tightening the scope so that each subagent has a clear, non-overlapping domain.

This directly addresses the root cause identified by Agent Optimization and confirmed by Session Trace, without adding unnecessary complexity.

Why B is incorrect:

Adding new subagents for frequently misrouted intents is the opposite of what is needed. The problem is already that there are too many overlapping subagents causing confusion. Adding more subagents would introduce additional semantic overlap and worsen the routing problem instead of improving it. The correct solution is to refine existing subagents, not create new ones.

Why C is incorrect:

Extending the Data Library with more Knowledge articles addresses the grounding layer—what information the agent uses after a subagent has been selected.

However, the issue here is routing/selection (choosing the wrong subagent), not lack of knowledge. Adding Knowledge articles will not fix the reasoning engine’s inability to distinguish between subagent descriptions. The agent would still route incorrectly and simply answer with more information from the wrong path.

References:

• Salesforce Official Documentation: "Agentforce Observability and Agent Optimization" – states that "ambiguous subagent match" score reasons are resolved by refining subagent descriptions and entry conditions to reduce semantic overlap.

• Trailhead Module: "Monitor and Optimize Agentforce Agents" > Unit: "Using Agent Optimization" – emphasizes using Session Trace and quality scores to identify routing issues, then adjusting topic/subagent definitions as the primary remediation step.

Explanation:

The core problem is that employees do not know (and should not have to know) which specialized agent handles which type of request. The correct architectural fix is to remove that decision from the employee entirely by providing a single, unified entry point that intelligently routes the request behind the scenes.

Why SOMA is correct:

A Single Org Multi-Agent (SOMA) architecture does exactly this:

• Employees interact with one central/orchestrator agent.

• That central agent uses natural language understanding (intent classification) to determine what the employee actually needs (e.g., "reset my network password" → IT Support intent).

• It then routes the request to the appropriate specialized agent, topic, or action (IT Support, HR Assistant, Procurement, etc.) as a subagent — without the employee needing to select or even know about the underlying specialized agents.

• This provides centralized control and governance (permissions, monitoring, guardrails) over how requests are routed and handled.

• It also scales cleanly as new specialized agents are added, since new subagents can be plugged into the central router without changing the employee-facing experience.

This satisfies all three requirements: improved UX (no guessing), scalability (easy expansion), and centralized control (single governed entry point).

Why not A:

Adding a validation rule on the Agent Session object to block mismatched prompts is a reactive and brittle workaround, not an architectural solution. It still requires the employee to select an agent first, and validation rules cannot reliably interpret natural language intent. This approach would also require constant maintenance and does not scale as new agents are added.

Why not C:

A standalone multi-agent setup (separate, disconnected agents) does not solve the root problem. Employees would still need to choose the correct agent upfront. Adding prompts like "verify your department or role" only adds friction and still relies on the user to determine routing, rather than allowing the system to intelligently interpret intent.

Reference concepts:

Single Org Multi-Agent (SOMA) pattern in Agentforce: a primary/orchestrator agent with specialized subagents, using intent-based routing so end users have a single consistent entry point regardless of how many specialized capabilities exist behind it. This is Salesforce’s recommended pattern for scaling multiple internal-use agents while maintaining a simple, centralized user experience.

Explanation:

Option C (Correct):

The Agentforce Testing Center provides automated regression testing with metrics like Subagent Pass % and Action Pass %. By re-running the stored test suite, the Specialist can quickly identify regressions introduced by the Billing subagent changes, confirm the scope of misrouting, and extend the suite to cover the new refund escalation path. This ensures systematic diagnosis and compliance with best practices.

Option A:

Utterance Analysis is useful for reviewing logs, but it is reactive and manual. It does not provide regression metrics or systematic coverage. It is better suited for fine-tuning after regressions are already identified, not for confirming the full extent of impact.

Option B:

Manually replicating scenarios in Conversation Preview is time-consuming and error-prone. It cannot scale to cover all possible utterances or provide quantitative regression metrics.

Reference:

Salesforce documentation on Agentforce Testing Center highlights its role in regression testing, automated validation, and ensuring subagent routing accuracy after configuration changes.

Explanation:

Relying purely on natural language system instructions (probabilistic control) to enforce strict business rules or security compliance often leads to hallucinations. When a rule is absolute—such as a security or financial restriction—you must use deterministic guardrails.

Why C is correct:

Agentforce allows administrators to set Action Conditions (or Action Visibility filters) on individual actions. These function exactly like conditional visibility rules elsewhere in Salesforce. By setting a condition where Account Tier EQUALS Platinum, the Agentforce runtime evaluates the current record context or session data before presenting the action to the LLM.

If the customer is a "Standard" tier, the action is hidden from the agent's available toolset entirely. Because the agent does not even know the action exists for that customer, it is physically impossible for it to invoke it, completely preventing backend errors.

Why A is incorrect:

This is what Universal Containers is currently doing. System instructions are probabilistic; while they reduce unwanted behavior, they can still be bypassed or hallucinated under certain conversational contexts.

Why B is incorrect:

Text filtering or blocking keywords like "refund" is brittle, negatively impacts user experience, and does not gracefully handle natural variations in human speech (e.g., a customer saying "I want my money back").

Reference:

Salesforce Agentforce Documentation: Manage Agent Actions. Action conditions let you control when an action is available to an agent based on user permissions, record data, or session variables. This ensures compliance and prevents the agent from executing unauthorized tasks.

Explanation:

Option A (Correct):

Agent Inspection provides full visibility into the entire agent interaction lifecycle — from the initial user request through to resolution. It allows specialists to review transcripts, actions taken, and outcomes, making it the right tool for analyzing agent behavior and response quality.

Option B:

Agent Insights focuses on aggregated performance metrics and trends (e.g., deflection rates, escalation volumes). It does not provide detailed inspection of individual interactions.

Option C:

Agent Optimization is about improving agent performance through tuning and configuration changes. It is not designed for analyzing complete interaction histories.

Reference:

Salesforce documentation on Agentforce Observability highlights that Agent Inspection is the feature used to review full agent sessions for compliance, quality assurance, and behavioral analysis.