Explanation:

The Model Context Protocol (MCP) is an open standard designed to simplify and secure the way AI agents connect to external systems. Its primary role is to provide a consistent, standardized interface for delivering context (structured data, metadata, or external information) into AI models. This avoids the need for custom integrations or proprietary APIs for each new system.

Option A is correct because MCP ensures interoperability and secure context delivery across diverse environments.

Option B is incorrect because MCP does not replace RAG or embed external data into LLM weights; RAG remains necessary for dynamic retrieval.

Option C is incorrect because MCP is not about autonomous negotiation or agent-to-agent task delegation; it focuses on context exchange standards.

Reference:
Salesforce Documentation: Agentforce Integration with MCP
OpenAI & Salesforce Technical Notes: Model Context Protocol Overview
Trailhead Module: Agentforce AI Integration Basics

Explanation:

Why C is correct:
In Agent Script, variable declarations have specific keywords that control mutability. The syntax is:
text
variable_name: type = value

By default, when you declare a variable without the mutable keyword, it is treated as read-only (immutable). This means:

* The variable can be initialized with a value (e.g., order_id: string = "").
* However, it cannot be updated or reassigned at runtime, including by actions or utilities like @utils.setVariables.
* Attempting to update an immutable variable via @utils.setVariables will fail silently or produce an error, and the variable will retain its original value ("") in this case.

For a variable to be updatable at runtime, it must be explicitly declared with the mutable keyword:
text
mutable order_id: string = ""

This design ensures that specialists can intentionally protect certain variables from being overwritten during the conversation, providing better control and security.

Why A is incorrect:
The mutable keyword is not optional if you intend to update the variable. It has a critical effect: its presence determines whether the variable can be changed at runtime. Without it, the variable is read-only. The statement that "the mutable keyword is optional and has no effect" is factually incorrect in Agent Script.

Why B is incorrect:
Omitting the mutable keyword is not a syntax error. The declaration order_id: string = "" is perfectly valid Agent Script syntax. It simply creates a read-only variable. The agent will deploy and run successfully, but the variable will not update when @utils.setVariables is called. The failure is a runtime behavior issue, not a deployment syntax error.

References:
Salesforce Official Documentation: "Agent Script Variables and Mutability" – explicitly defines that variables declared without the mutable keyword are immutable and cannot be modified by actions or utilities after initialization.

Trailhead Module: "Build Agentforce Agents with Agent Builder" > Unit: "Manage State with Agent Script Variables" – demonstrates declaring variables with and without mutable, showing that mutable is required for runtime updates.

Agentforce Exam Guide (AI-201): Under "Agent Script and State Management" – emphasizes understanding variable mutability rules, including the use of the mutable keyword, and the behavior of @utils.setVariables with immutable variables.

Explanation:

In Data Cloud (Data 360) / Agentforce architecture, once unstructured data (like meeting notes) has been chunked and vectorized into a search index, the way to make that data usable for grounding a prompt is through a retriever. A retriever is the component specifically designed to query a vector/search index and pull back the most semantically relevant chunks of data based on the input at runtime.

A Flex (Freeform) prompt template is the prompt template type that supports advanced grounding, including referencing retrievers directly. This allows dynamic, similarity-based search rather than static field merges. By referencing a retriever inside the Flex template, the specialist enables the prompt to dynamically refine search criteria and pull the most relevant unstructured content at execution time.

Why the other options are incorrect:

A. Data Lake Object (DLO):
DLOs store raw, ingested data before it is mapped and harmonized. You do not reference a DLO directly in a prompt template for semantic search because DLOs are not the searchable or vectorized construct. Retrievers are built to query search indexes, which sit on top of indexed and harmonized data, rather than raw DLOs.

C. Data Model Object (DMO):
While DMOs are the harmonized, standardized data objects in Data Cloud and can be used for structured grounding, they are not the mechanism for querying a vectorized or unstructured search index. For unstructured, vector-based semantic search, a retriever is the correct construct rather than a direct DMO reference.

Reference:
Salesforce Data Cloud documentation on Retrievers and Grounding with Data Cloud (Prompt Builder – Flex templates and Vector Database/Search Index grounding).

Explanation:

When using the Agentforce Testing Center to evaluate agent responses, standard metrics can tell you if an agent followed simple instructions or if the text is structured correctly. However, analyzing highly specific qualitative traits—like a company's unique tone, brand voice guidelines, or complex internal quality rubrics—requires customized grading logic.

Why C is correct:
Standard, out-of-the-box evaluations are rigid and do not know your corporate brand identity. Agentforce allows specialists to define Custom Evaluations powered by an LLM Judge. By configuring a custom LLM judge, you can supply your company's precise brand-voice playbook and criteria as prompt parameters. The testing engine will then use that specialized context to grade your agent's test-run outputs on a nuanced scale rather than a binary pass/fail check.

Why A is incorrect:
The Coherence evaluation is a standard metric that looks for logical flow, clarity, and grammatical consistency. It measures whether a response makes general sense, but it cannot evaluate whether the text aligns with Universal Containers' specific brand voice.

Why B is incorrect:
The default Response Evaluation metrics cover foundational traits like helpfulness, accuracy, and safety. They are not tailored to custom corporate guidelines.

Reference
Salesforce Help / Agentforce Developer Guide: Testing Center Custom Metrics. For advanced quality assurance that goes beyond standard evaluation parameters, administrators can create custom metrics utilizing a LLM judge. This allows organizations to provide custom guidelines, scoring definitions, and rubrics to monitor brand alignment and response voice.

Explanation:

The key distinction is who decides whether the action executes.

reasoning.actions
Actions listed here are available to the LLM as tools.
The model chooses whether or not to invoke them based on its reasoning and the current conversation.
There is no guarantee that a listed action will be executed on every applicable turn.

run @actions.<action_name>
This is an explicit instruction to execute the specified action.
It bypasses the LLM's discretionary tool selection and ensures the action runs deterministically whenever that line is reached in the Agent Script.
This approach is appropriate for mandatory business logic, such as:
- Checking cancellation eligibility
- Performing compliance or security validations
- Verifying customer identity
- Logging audit events

Since the requirement is to guarantee that "Check Cancellation Eligibility" executes on every relevant turn, using run @actions.CheckCancellationEligibility is the correct implementation.

Why the Other Options Are Incorrect

A. ❌ Incorrect
reasoning.actions does not automatically execute actions on every turn. It merely exposes them as tools the LLM may use. Therefore, the difference is not merely syntactic.

B. ❌ Incorrect
The run command is not limited to being nested inside reasoning.actions, nor is reasoning.actions required for the LLM to access an explicitly invoked action. run is used specifically to force execution, not simply to pass parameters.

Reference
- Salesforce Agentforce documentation on Agent Scripts and action invocation (concepts of deterministic execution vs. LLM-selected tools).
- Salesforce Agentforce Specialist (AI-201) Exam Guide covering Agent Scripts, reasoning, and action orchestration.

Exam Tip
A common exam pattern is distinguishing deterministic execution from LLM-driven reasoning:

- reasoning.actions → The LLM decides whether to call the action.
- run @actions.<name> → The action always executes when that step is reached.

If a question includes phrases such as "must always execute," "guaranteed," "mandatory," "deterministic,"or "without relying on the reasoning engine,"the correct choice is typically the explicit run invocation.