Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CRO, CMO, CFO or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Twenty-two pages on Agentforce as the Salesforce platform for autonomous and semi-autonomous AI agents; the conversation-credit metric and the credit-per-conversation multiplier; the agent topology across Service, Sales, Marketing, Commerce and custom agents; the Data Cloud dependency; the included-versus-premium boundary; the credit-pool sizing methodology; the pilot-to-production discipline; and the renewal posture inside the Salesforce contract cycle.
Agentforce is the Salesforce platform for autonomous and semi-autonomous AI agents that act inside the Customer 360 estate. The roadmap follows a clear commercial arc from Einstein AI as embedded prediction inside the platform, through Einstein Copilot as an embedded chat assistant, to Agentforce as a separately priced platform for agentic capability.
The publisher-side commercial logic is to convert the AI surface from an embedded enhancement of the seat subscription into a separately priced platform with its own meter. The buyer-side commercial reading is that the agentic capability is real and the value proposition can be material, but the credit-meter construct is unfamiliar territory in a Salesforce procurement conversation and the sizing risk sits on the buyer.
The Admodum reading is that Agentforce is a credible procurement decision when the use case is defined, the credit-per-conversation multiplier is modelled and the commitment is sized against deployed-use evidence. The decision is not credible when it is led by the marketing-led conversation count, when the credit multiplier is assumed at one and when the commitment is sized against a roadmap projection rather than a pilot read. This paper is the methodology Admodum applies inside the Salesforce practice across the cycle.
Agentforce prices on a conversation-credit construct. The buyer enrols a defined credit pool against a defined contract term, with a published credit schedule that determines how many credits a given conversation type consumes and an over-consumption rate that prices credit drawn above the committed pool.
A Salesforce conversation under Agentforce is not the same unit as a customer conversation. The Salesforce definition counts events at the agent invocation, context retrieval and model invocation level. A single end-to-end customer interaction may register as several Salesforce conversations against the credit pool, particularly where multi-agent flows hand control between agents (Service to Sales, Sales to Marketing, Marketing to Commerce) inside a single customer journey.
The procurement question is the multiplier. Where the publisher forecast assumes one credit per customer conversation, the deployed reality often runs at three, five or higher. The credit-per-conversation multiplier is the load-bearing input to the credit-pool sizing.
The published credit schedule sets out the credit consumption for each conversation type and each agent type. The schedule is the property of Salesforce and can be adjusted at renewal; the buyer-side commercial discipline is to model the consumption against the schedule in effect at signature and to require pricing protection against material schedule changes during the term.
The over-consumption rate prices credit drawn above the committed pool at a published per-credit rate that materially exceeds the implicit committed-pool unit price. The over-consumption is the risk; the committed-pool sizing is the procurement instrument that controls it.
Agentforce sells a defined population of agent SKUs alongside the platform for custom agents built on Agent Builder. Each agent has a defined scope, a defined role-type alignment and a defined credit-consumption profile. The procurement decision is which agents belong inside the deployment and what credit profile each carries.
The published agent population at the time of this paper includes the Service Agent for customer service automation, the Sales Agent for sales motion automation, the Marketing Agent for campaign and audience automation, the Commerce Agent for commerce-cloud automation, the Personal Shopper for the consumer-facing commerce surface and the Health Agent for healthcare-vertical workflow. Additional named agents are anticipated across subsequent release windows.
The Agent Builder is the platform tool that lets the buyer construct custom agents against the Salesforce data model. Custom agents draw against the same credit pool as the named agents and follow the same credit-consumption protocol. The Agent Builder licence and the credit pool are independent commercial constructs and must be sized independently.
The procurement methodology is to enumerate the use cases first, map each use case to either a named-agent SKU or a custom-agent build, and then size the credit pool against the consolidated agent population. The wrong sequence enrols a credit pool against a notional agent estate that has not yet been defined.
Agentforce is a downstream consumer of Data Cloud. The agents draw context from the Data Cloud profile and event store, and the agent output writes events back into the Data Cloud event stream. The Data Cloud commitment is the substrate that makes Agentforce deployable; it is also a separate procurement decision with its own credit-consumption metric.
The interaction is direct. An Agentforce deployment without a sufficient Data Cloud commitment will fail at the context-retrieval boundary or will draw against an over-consumption schedule on Data Cloud that materially changes the all-in Agentforce economics.
The Admodum methodology sizes Agentforce and Data Cloud as a joint commitment, with the Data Cloud profile and event counts, the segmentation cadence and the activation volume each modelled against the Agentforce use cases. The joint-commitment work is set out in detail in the companion paper Salesforce Data Cloud Commitment; the Agentforce reading and the Data Cloud reading are interdependent.
The procurement question that recurs through every Agentforce conversation is where the included Einstein entitlement ends and where the paid Agentforce credit begins. The boundary is contestable and the buyer-side methodology is to contest it explicitly.
The Einstein AI surface that ships inside the existing Salesforce subscriptions (Sales Cloud, Service Cloud, Marketing Cloud) carries an included AI population. The Einstein Copilot legacy carried an embedded conversational interface as part of the subscription. The Agentforce position is that the agentic capability sits outside the included entitlement and prices separately on the credit construct.
The buyer-side reading is that the boundary is a commercial framing rather than a technical one. Many of the included Einstein capabilities continue to deliver against the use cases that Agentforce is being proposed to address; the procurement question is whether the Agentforce capability is materially superior to the included Einstein position for the buyer’s use cases.
The methodology runs a use-case-by-use-case read against the Einstein included surface before proposing an Agentforce commitment. Where the included Einstein capability is sufficient, the Agentforce commitment is reduced or deferred. Where the Agentforce capability is materially superior and the value capture is defensible, the credit pool is sized against the deployed-use evidence.
The Admodum buyer-side Agentforce credit-pool sizing runs against a defined five-stage protocol. The protocol produces a single credit-pool size with a contingency band and a defensible methodology trail.
The output is the buyer-side committed credit pool, sized against deployed-use evidence and accompanied by a defensible methodology trail. The trail is the load-bearing document at the next renewal.
The Agentforce pilot is the load-bearing input to the production commitment. The Admodum pilot discipline runs against three guardrails that protect the production sizing from being driven by pilot enthusiasm rather than by deployed-use evidence.
The pilot agreement should expose the production credit-pool pricing at the moment of pilot start. Where Salesforce proposes a discounted pilot construct, the production unit pricing must be visible at pilot start. The pilot should not be the price-discovery instrument for the production commitment.
The pilot deliverable is a memo to the CIO, CRO, CMO and CFO that scores the deployed-use evidence by use case, scores the credit-per-conversation multiplier observed during the pilot, recommends the production credit-pool sizing with contingency band, and recommends the agent-by-agent rollout cadence. The memo is the procurement instrument; the conversation does not run from the pilot satisfaction survey.
The production ramp opens against the agent with the strongest evidence (typically Service Agent or Sales Agent against a defined motion), steps to the next agent against the next-strongest evidence at year two, and reviews the lower-evidence agents at year three. The ramp is rarely a flat commitment; the agent-by-agent ramp design is the procurement instrument.
Agentforce sits inside the Salesforce renewal cycle. The user-type reconciliation, the MuleSoft and Tableau adjacencies, the shelfware identification and the Data Cloud joint-commitment (all set out in the Salesforce Renewal Defence paper) interact with the Agentforce credit-pool sizing.
The interaction with user-type reconciliation is direct: an Agentforce credit pool sized against an inflated CRM user count is sized incorrectly. The user-type reconciliation runs first; the Agentforce credit-pool sizing then runs against the corrected user population and the role-type alignment.
The interaction with Data Cloud is direct and bi-directional: the Data Cloud commitment determines the substrate that makes Agentforce deployable, and the Agentforce credit consumption determines the activity volume that flows through the Data Cloud segmentation and activation surface. The two are sized together as a joint commitment, set out in Salesforce Data Cloud commitment.
The closing posture protocol runs inside the Renewal Programme on a fixed fee, contingency or annual retainer basis. The Agentforce credit pool, the agent topology, the Data Cloud joint-commitment and the multi-year ramp design are each carried through to the closing memorandum.
The Salesforce Agentforce paper sits inside the Salesforce cluster of the Admodum white paper library and the broader AI-commercial reading. The companion papers extend the methodology to adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across the Salesforce Agentforce engagements of the past twelve months. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer. The full case studies library carries Agentforce engagement summaries; the blog publishes the running practice analysis.
A senior Admodum advisor will walk the methodology through with your CIO, CRO, CMO, CFO or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.