How to ground Salesforce Agentforce with custom company rules

Go-to-market operations teams deploying Salesforce Agentforce face a persistent consistency problem as they scale automated customer outreach. While these embedded CRM AI agents excel at draft composition and record updates, they lack access to a centralized repository of company positioning. Consequently, Agentforce agents frequently generate email pitches containing outdated product descriptions or unauthorized pricing discounts.

Standard prompt engineering and vector-based retrieval methods fail to maintain consistency across a scaling sales agent fleet. Stashing company rules inside static system prompts consumes valuable context window space and fails when pricing updates occur mid-campaign. Similarly, standard document retrieval returns whatever is written in the source files, propagating stale facts directly to your customers.

The Commercial Truth manifesto argues that enterprise GTM teams must manage their messaging as version-controlled operational infrastructure. Securing your CRM agents requires shifting from static prompt configurations to a dynamic, protocol-based knowledge gateway. For RevOps leaders, the objective is to implement a Model Context Protocol bridge that grounds Agentforce in your canonical Truth Graph.

Architectural assumptions

Our implementation relies on exposing the Orchestration engine’s capabilities to Salesforce Agentforce through a secure MCP server. Instead of forcing Agentforce to search unstructured document folders, we configure it to invoke typed tools. This protocol-based connection allows the CRM agent to request approved pricing and positioning rules dynamically.

The connection flow uses two-way communication to retrieve and validate facts before they are sent to prospects. First, the Agentforce agent translates the user’s intent into a specific tool call, such as querying pricing parameters. Second, the MCP server queries the local Truth Graph, verifying the source-type and confidence score of the target claim.

+------------------------+      MCP Call       +------------------------+
|  Salesforce Agentforce | ==================> | Assay MCP Server       |
|  (CRM Client Agent)    |                     | (PRD-06 Integrations)  |
+------------------------+                     +-----------+------------+
                                                           |
                                                           | Query Graph
                                                           v
                                               +------------------------+
                                               | GTM Truth Graph        |
                                               | (PRD-01 Substrate)     |
                                               +------------------------+

Third, the server applies our local policy rules, filtering out any claims that are marked stale or lack human approval. The response returned to Salesforce contains the verified text, a source-type pill, and the credible interval. If the requested information is not verified, the server returns a specific status indicating the claim is not yet confirmed.

Step-by-step implementation

To configure this grounding layer, we build an Apex class inside Salesforce that interfaces with our MCP server gateway. This Apex handler executes during the Agentforce reasoning cycle, intercepting prompts and enriching them with verified claims. Follow these steps to set up the connection:

Step 1: Set up the named credential in Salesforce

Before writing code, configure a Named Credential in your Salesforce Setup to manage authentication and routing to the Assay gateway. This credential stores the endpoint URL and your secure integration token, encrypting them in accordance with SOC 2 requirements. The Named Credential ensures that Apex callouts do not hardcode authentication secrets.

Name the credential Assay_Integrations_API and point it to your deployed gateway URL. Set the authentication headers to include your client key. This configuration routes all callouts through the Salesforce security boundary.

Step 2: Implement the mcp client class

Create a new Apex class in your Salesforce Developer Console to handle the tool execution requests from Agentforce. The class parses the incoming query parameters, formats the JSON payload, and sends an HTTP request to the Assay gateway. It then processes the returned claims and formats them for the agent’s context.

Save the following Apex code representing the core tool callout handler:

public class AssayMcpConnector {
    @InvocableMethod(label='Get Canonical GTM Claims' description='Queries the Assay Truth Graph for verified company rules.')
    public static List<String> getCanonicalClaims(List<String> categories) {
        List<String> results = new List<String>();
        String category = categories[0];
        
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:Assay_Integrations_API/v1/tools/get_positioning_claims');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setBody('{"category":"' + category + '"}');
        
        Http http = new Http();
        try {
            HttpResponse res = http.send(req);
            if (res.getStatusCode() == 200) {
                results.add(res.getBody());
            } else {
                results.add('{"error":"Failed to fetch claims. Status: ' + res.getStatus() + '"}');
            }
        } catch (Exception e) {
            results.add('{"error":"Exception occurred: ' + e.getMessage() + '"}');
        }
        return results;
    }
}

Step 3: Configure the Agentforce action

Inside the Agentforce Builder workspace, create a new Custom Action that references the invocable Apex method we created. Define the input parameter as the target category string and map the output array to the agent’s context. This action exposes the query tool directly to the agent’s decision-making loop.

Set the action’s instruction metadata to guide when the agent should call the tool. For example: “Invoke this action when a customer asks for pricing details or competitive comparisons.” This instruction tells the agent to query the canon instead of guessing.

Step 4: Map pricing and positioning categories

In the Assay Entity Command Center, organize your GTM rules into distinct categories matching the parameters Agentforce queries. Ensure that pricing tiers, competitor reframes, and case studies are tagged with clean category labels. The system uses these tags to resolve query matches when Salesforce makes callouts.

If product marketing updates a pricing tier, the cascade engine flags the change immediately. The update propagates to the API layer, ensuring that the next Agentforce execution reads the new values. This setup prevents the CRM agent from using cached or stale parameters.

Step 5: Test the grounding connection in sandbox

Use the Agentforce Simulator to test the tool execution path before deploying the class to your production instance. Enter a prompt simulating a prospect requesting starter pricing details. Verify that the agent pauses execution, triggers the Apex callout, and receives the structured JSON claims.

Inspect the simulator logs to confirm that the agent’s draft message is grounded in the returned statements. If the draft matches the Truth Graph text, the integration is working. The simulation transcript is saved to the audit log for compliance review.

Step 6: Set up confidence-score gates

In the Assay settings panel, configure the confidence-score gate for the Salesforce destination to 0.80. This gate prevents Agentforce from retrieving any claims that carry a confidence score below this threshold. If a competitor reframe is un-audited or has expired, the MCP server filters it out of the response.

Instead of returning the low-confidence claim, the server returns an instruction directing the agent to routing the exception to a human. This prevents the AI from delivering unverified assertions to prospects. It ensures that the sales agent remains within compliant boundaries.

Step 7: Configure the validation webhook

Configure Salesforce to send all draft outreach generated by Agentforce to our verification webhook before sending. The validation handler parses the draft text and compares it to the original claim node in the Truth Graph. If the verification returns a rejection status, the system quarantines the email.

[Agentforce Draft Output] ===> [Assay Verification Webhook] ===> [Verdict: APPROVED]
                                                                        |
                                                                        v
                                                               [Deliver to Customer]

This final pre-flight check catches any instances where the agent drifted from the retrieved facts during composition. If the draft passes, the system approves delivery and logs the event to the audit trail. This step completes the grounding cycle, guaranteeing that your CRM outputs remain compliant.

Verification and sample outputs

We verify the Salesforce integration by executing the Apex connector and inspecting the returned JSON payloads. The sandbox simulator logs show the exact RPC message exchange between Agentforce and the Assay MCP server. This log proves that the agent is querying the canon dynamically.

Below is an example of the output payload the Apex method returns to the Agentforce reasoning engine:

{
  "claims": [
    {
      "id": "claim-sf-pricing",
      "statement": "Salesforce Integration tier is $150 per user per month, billed annually.",
      "sourceType": "FIRST_PARTY_VERIFIED",
      "confidenceScore": 0.95,
      "lastAudited": "2026-05-25T10:00:00Z"
    }
  ]
}

The Agentforce engine reads this structured payload and uses the statement verbatim in its response. If the prospect attempts to negotiate a lower rate, the agent queries the exception policy tool. The log shows that the agent handles objections using approved, grounded talk tracks.

This integration is tracked on the Topology Canvas, which visualizes the live connection between the Truth Graph and Salesforce. The canvas displays the sync status, connection health, and query latency in milliseconds. This transparency gives RevOps the operational visibility needed to manage the integration.

[Truth Graph] ──(VERIFICATION GREEN / 45ms)──> [Salesforce Agentforce]

Production-readiness checklist

Before deploying this integration to your production Salesforce environment, complete the following setup checks. These controls ensure that the connection remains secure and that the agent’s access is restricted. This checklist guarantees that your CRM automation matches enterprise compliance standards.

Confirm that your deployment satisfies the following criteria:

• Isolate client credentials. Ensure the integration token used by the Named Credential is stored securely and lacks platform write permissions.
• Implement fallback defaults. Define default talk tracks that Agentforce can use if the Assay API gateway experiences temporary latency.
• Configure daily sync checks. Schedule a job to verify that the active Named Credential connection remains validated.
• Set up exception routing. Map a queue in Salesforce to receive drafts that fail the verification webhook, alerting managers.
• Audit simulator logs. Review the sandbox execution records weekly to verify that the agent is invoking the tool correctly.

The alignment of your Agentforce deployments is measured by the methodology Assay is developing for the Commercial Truth Index. The index evaluates whether the substance your CRM agents emit remains grounded, coherent, and audit-traceable. Implementing this Apex MCP connector is a critical step in bringing your Salesforce automation into alignment with those standard criteria.

This essay is grounded in the orchestration spec and the integrations product canon.