hello@audit9.com

From Agentforce Prototype to Production: An Architect’s Readiness Checklist

By Claire Adams

Creating an Agentforce prototype can be quick. Creating an agent that can be trusted with real users, real customer data and real business processes requires a broader set of architecture decisions.

The difference is important. A prototype demonstrates that an agent can respond to a controlled prompt and complete a selected action. A production implementation must continue to perform when requests are ambiguous, data is incomplete, integrations are unavailable and users behave in unexpected ways.

Salesforce describes an Agent Development Lifecycle spanning ideation and design, development, testing and validation, deployment, and continuous monitoring and tuning. The following checklist translates that lifecycle into practical production-readiness questions for Salesforce architects and delivery teams.

1. Start with a bounded use case

A useful Agentforce use case has a clear user, goal and boundary.

Before implementation, document:

  • who can invoke the agent;
  • which outcomes it is expected to deliver;
  • which requests are explicitly outside its scope;
  • which records and systems it may access;
  • which actions it may perform;
  • when it must escalate to a person; and
  • how success, failure and business value will be measured.

The initial scope should favour a small number of high-value journeys over a long list of loosely related topics. A narrow agent is easier to instruct, secure, test and support. Additional capabilities can be introduced when evidence shows that the existing scope is reliable.

2. Establish trusted grounding data

An agent cannot compensate reliably for an unclear data model or poor-quality source data. If customer records are duplicated, status values are inconsistent or important fields are incomplete, the agent may confidently act on the wrong context.

For every response or action, identify the authoritative source. Consider whether the agent requires:

  • structured Salesforce records;
  • knowledge content;
  • Data 360 data;
  • information retrieved from an external system; or
  • a combination of these sources.

Then assess the data against the intended task. Completeness, accuracy, timeliness and identity resolution all matter. So do access controls: grounding must not expose information that the invoking user is not entitled to see.

Data quality should be monitored after launch rather than treated as a one-off migration activity. Production conversations often reveal missing knowledge, inconsistent classifications and weak ownership that were not visible during a prototype.

This is where an operational master data management capability can become part of the Agentforce architecture. clearMDM is a Salesforce-native Operational MDM solution developed by Audit9. It continuously cleanses, matches and merges customer data to maintain a trusted Golden Record, giving Agentforce a governed and authoritative customer view rather than leaving each agent implementation to resolve identity and data quality independently.

3. Design topics, instructions and actions as a contract

Topics define the work an agent can perform. Instructions guide its reasoning within that scope. Actions allow it to retrieve information or change the state of a business process.

These elements should form a clear contract:

  • topic classification determines whether the request belongs to the agent;
  • instructions state the rules and constraints;
  • actions provide specific, controlled capabilities; and
  • outputs make success or failure unambiguous.

Avoid relying on a long instruction to correct an action with an unclear interface. Action names, descriptions, inputs and outputs should be explicit enough for the reasoning engine to select and use them consistently.

The clearMDM Data Steward Agent provides a practical example. Its Agentforce capabilities are integrated with governed clearMDM matching and stewardship processes, supporting AI-assisted match scoring and duplicate review as well as automated acceptance or rejection within defined rules.

4. Enforce Least-Privilege Access and Layered Controls

An Agentforce agent operates within the Salesforce security model, but secure production design remains a shared responsibility. The agent should have only the permissions required for its defined use cases.

Review:

  • the agent user and assigned permission sets;
  • object, field and record-level access;
  • Apex, Flow and external-service permissions;
  • credentials and authentication used by integrations;
  • access to knowledge and grounding sources; and
  • logging of sensitive inputs and outputs.

Do not grant broad access simply to make a prototype work. Excess permissions increase the impact of an incorrect topic selection, a misunderstood request or a compromised integration.

Agentforce should be protected by more than one type of control. The agent’s instructions can explain what it should and should not do, but important rules should also be enforced by Salesforce. Validation rules, Flow decisions, Apex checks, API controls and approval processes provide predictable safeguards that do not rely on the agent interpreting an instruction correctly.

5. Make escalation a designed outcome

Human involvement is not necessarily an agent failure. In many processes it is the correct and safest outcome.

Define escalation conditions such as:

  • the request is outside scope;
  • required data is absent or contradictory;
  • identity or entitlement cannot be established;
  • an integration or action fails;
  • the user disputes the result;
  • the action exceeds a financial or operational threshold; or
  • policy requires human approval.

clearMDM can use its Data Steward Agent to provide reasoning and a second opinion on potential duplicate records while leaving the final decision with a human data steward. As confidence, rules and operational evidence mature, selected decisions can be automated.

Include a safe default for uncertainty. When the agent cannot establish that an action is permitted, it should stop or escalate rather than improvise.

6. Test behaviour, not only configuration

Traditional unit and integration tests remain necessary for Flow, Apex and APIs. They are not sufficient for an AI agent, because natural-language input and model reasoning introduce variation.

A representative Agentforce test set should include:

  • expected requests expressed in different ways;
  • ambiguous and incomplete requests;
  • requests that belong to similar topics;
  • out-of-scope questions;
  • missing, stale and conflicting data;
  • unauthorised requests;
  • action and integration failures;
  • attempts to bypass instructions;
  • multi-turn conversations; and
  • escalation and recovery scenarios.

Evaluate more than the final wording. Check topic selection, action selection, action sequence, grounding, instruction adherence, record changes and escalation behaviour.

Salesforce currently supports agent testing through the Agentforce Testing Center, Agentforce DX and the Testing API. Tests run in sandboxes and can consume requests and credits; they may also modify data. Test data and cleanup therefore need to be designed intentionally.

7. Plan deployment and rollback

Agentforce configuration should follow the same controlled delivery principles as other Salesforce metadata, while recognising that the agent also depends on data, knowledge, integrations and model-driven behaviour.

A release plan should identify:

  • all configuration and metadata dependencies;
  • required permission and credential changes;
  • grounding data and knowledge dependencies;
  • environment-specific endpoints;
  • activation order;
  • smoke tests;
  • business ownership and support arrangements; and
  • rollback or deactivation steps.

Consider a phased release to a limited audience or a small proportion of traffic. Start with lower-risk actions, observe real interactions and expand autonomy only when the evidence supports it.

8. Operate a continuous evaluation loop

Production launch is the beginning of agent evaluation, not the end.

Monitor technical, behavioural and business measures. Useful indicators may include:

  • sessions and adoption;
  • successful completion rate;
  • escalation and abandonment rates;
  • topic and action errors;
  • latency and integration failures;
  • quality or helpfulness scores;
  • customer or employee feedback;
  • agent consumption and cost; and
  • the business outcome defined for the use case.

Aggregate metrics reveal trends, while session-level traces help diagnose individual failures. Salesforce’s Agentforce Observability capabilities are designed around this combination, including session tracing, conversation clustering, quality measures, health monitoring and consumption analysis.

Establish ownership for reviewing this evidence. Changes to topics, instructions, actions and grounding should be versioned, tested and released through the same controlled process as the original implementation.

Also define incident thresholds. A sudden increase in action errors, unsafe outputs or escalations may require an alert, restricted functionality or immediate deactivation.

A practical production gate

An Agentforce implementation is ready for production when the delivery team can answer “yes” to the following:

  • Is the use case bounded and measurable?
  • Are the grounding sources trusted, current and appropriately secured?
  • Do topics, instructions and actions have clear contracts?
  • Does the agent operate with least privilege?
  • Are critical controls deterministic?
  • Are escalation paths intentional and tested?
  • Does a repeatable regression suite cover normal and adverse behaviour?
  • Can the solution be deployed, limited and rolled back safely?
  • Are quality, reliability, consumption and business outcomes observable?
  • Is there clear ownership for continuous improvement?

The objective is not to remove all uncertainty. That is unrealistic for any non-trivial production system and particularly for one that includes probabilistic reasoning. The objective is to constrain uncertainty, detect it and ensure that failures are safe and recoverable.

Agentforce can provide a flexible interaction and orchestration layer across Salesforce data and business processes. Its production value, however, depends on the architecture around the agent: trusted data, well-designed actions, layered security, repeatable testing and disciplined operations.

References

This article was developed with assistance from generative AI and reviewed and edited by Audit9.

Related Posts

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.