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.
A useful Agentforce use case has a clear user, goal and boundary.
Before implementation, document:
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.
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:
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.
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:
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.
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:
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.
Human involvement is not necessarily an agent failure. In many processes it is the correct and safest outcome.
Define escalation conditions such as:
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.
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:
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.
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:
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.
Production launch is the beginning of agent evaluation, not the end.
Monitor technical, behavioural and business measures. Useful indicators may include:
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.
An Agentforce implementation is ready for production when the delivery team can answer “yes” to the following:
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.
This article was developed with assistance from generative AI and reviewed and edited by Audit9.