Agentforce & AI
An Agentforce action is a production API—not a prompt trick
The action boundary is where AI becomes operational
A convincing Agentforce demonstration can answer questions, select a topic and call a Flow in a few minutes. That proves the conversation is possible. It does not prove that the resulting action is ready to create an order, change an address, approve a refund or send information to another system. The moment an agent can produce a side effect, the action becomes a production interface.
Treat it with the same discipline as an API used by an external application. It needs a precise purpose, validated inputs, enforceable authorisation, predictable outputs, idempotency, observability and a versioning strategy. Prompt instructions help the reasoning engine choose and use an action; they are not a substitute for controls at the boundary where business state changes.
Give each action one business responsibility
Salesforce's Agentic Integration Patterns guidance recommends actions with a single responsibility. An action that creates a billing account, updates CRM and sends a confirmation message is hard to reason about and harder to retry. If the third step fails, the agent cannot safely know whether repeating the whole action will create another account or overwrite a successful update.
Design smaller contracts such as ValidateBillingRequest, CreateBillingAccount and SendBillingConfirmation. This does not mean exposing every technical method to the agent. Keep low-level integration detail behind a business-shaped action, but make each side effect and completion condition clear. Atomic actions give the reasoning layer useful choices while keeping transaction and recovery logic deterministic.
Descriptions are routing metadata
An agent selects actions partly from their names, descriptions and input metadata. Salesforce advises intent-based descriptions rather than technical signatures. CallsBillingApi says where code goes; Creates a billing account and returns its identifier explains the business outcome. The description should also state when the action must not be used and which preconditions are required.
Apply the same care to every input and output. CustomerId is stronger than recordId when the business identity matters. A structured result should distinguish success, validation failure, authorisation failure, retryable technical failure and an accepted asynchronous request. Do not return an ambiguous string such as Done when downstream processing has only been dispatched.
Validate what the model inferred
Natural language is useful for gathering intent, but inferred parameters are untrusted input. Salesforce's architecture guidance explicitly recommends defensive validation at the action boundary. Check required values, formats, ranges, record state and cross-field rules in Flow, Apex or the target service. Re-query authoritative data instead of trusting a conversational summary of the record.
Separate correction from execution. An agent can ask the user to clarify an invalid date or missing account, but the action must still reject an unsafe request if that conversation fails to provide valid data. Business constraints such as refund limits, contract status and inventory availability belong in deterministic logic. If a rule matters enough to prevent harm, it should not exist only as a sentence in an instruction.
Authorisation must survive a hostile conversation
Agent access depends on execution context. Salesforce distinguishes employee experiences that commonly operate in the logged-in user's context from customer-channel agents that can use a dedicated agent user. For customer-facing use cases, Salesforce recommends minimum permissions and identity confirmation built directly into sensitive actions. The agent should never be able to talk its way around those controls.
Classify actions as public or private according to the consequence and data involved. Public knowledge retrieval may need no customer identity. Viewing an order, changing personal information or making a purchase may require verified identity and explicit authorisation. Enforce that decision server-side using permissions, sharing, filters and action logic. A prompt saying verify the customer first is guidance; a verified session check inside the action is a control.
Assume an action can be called again
An agent reasoning loop may retry an action when the response is ambiguous. Networks and downstream services can also retry. Salesforce therefore recommends idempotent write actions: repeated invocation with the same business request should produce the same outcome rather than duplicate it. This is essential for payments, bookings, orders and outbound communications.
Require an idempotency key for consequential writes and persist it with the result. On a repeated call, return the existing outcome. Distinguish safe reads from writes, and do not hide several non-idempotent operations behind one action. If the work is asynchronous, return a durable reference and a truthful Accepted status, then provide a separate action or event for checking completion.
Test the action and the agent separately
First test the deterministic contract without the agent: permissions, validation, bulk or repeated calls, timeouts, partial failure and error sanitisation. Then test whether the agent chooses the right action, supplies the right inputs, interprets outputs correctly and stops when a control rejects the request. These are different failure classes and they need different evidence.
Salesforce supports manual testing in Agentforce Builder and broader scenario testing through Agentforce Testing Center. Use both positive and adversarial cases: vague requests, conflicting instructions, unverified users, prompt injection attempts, missing records, duplicate submissions and unavailable downstream services. Include ground truth for the expected subagent, action, outcome and response—not only whether the final wording sounds plausible.
Operate actions as a governed portfolio
Maintain an inventory showing each action's owner, purpose, agent consumers, execution identity, permissions, data classification, side effects, dependencies, timeout, retry policy, idempotency mechanism and current version. Log correlation identifiers, inputs in a safely redacted form, selected outcome and downstream reference. Monitor unusual volumes, repeated failures and actions invoked outside their intended journey.
Changes to an action description can alter selection even when the underlying code is unchanged. Changes to an output schema can alter how the agent reasons about success. Treat metadata, instructions, Flow and Apex as one releasable unit, run regression scenarios before activation and preserve a rollback path. Agent behaviour is partly non-deterministic; the surrounding lifecycle cannot be casual.
The JSBC Labs view
The safest Agentforce architecture concentrates flexibility in understanding intent and keeps authority at deterministic boundaries. Give actions narrow business responsibilities, precise metadata, validated inputs, least-privilege execution, idempotent writes, structured outcomes and observable references. Let the agent decide which approved capability fits; never let it redefine what that capability is allowed to do.
A better prompt may improve a demonstration. A better action contract improves the system. When teams review agent actions with the seriousness they already apply to production APIs, they can add conversational intelligence without weakening the controls, recovery paths and accountability that enterprise operations require.