Autonomous agents consume Salesforce resources differently than deterministic automation. Agent workloads are unpredictable and continuous, rather than fixed and transaction-bound. The value-per-cost thesis of the Resource and Cost Optimization pillar carries directly into the Agentic Enterprise. Resource efficiency means using the capacity you already pay for, and cost optimization means directing spend deliberately toward the autonomous capabilities that earn a return. Agents change the shape of both. Efficient agent design keeps consumption in check, and pricing-model selection, total cost of ownership (TCO) modeling, and financial governance keep spend aligned with value. This document treats resource efficiency and cost optimization as one decision, because for agents, they're two views of the same goal.
Agents change the predictability of consumption. A traditional Apex process operates on a known record set with a known resource cost. An agent operates conversationally, and a single conversation can execute dozens of actions as the agent reasons through a task. Each action consumes governor limits inside its own transaction rather than accumulating them across the conversation. Context preparation for one turn may query 200 records or 20,000, depending on what the user asks. API consumption accelerates because agents can act autonomously, and proactive, outbound, and scheduled agents act continuously rather than only during a user transaction. This unpredictability is why agent resource management has to be defensive by design rather than tuned after a consumption spike occurs.
The cost side changes just as much. Autonomous agents introduce consumption-based pricing that behaves differently from traditional per-seat licensing. Agentforce offers two consumption-based pricing models, Flex Credits and Per-Conversation. Each agent deployment selects one of these models. An org uses one consumption model at a time, but a Per-User add-on, offered per user per month for unmetered usage, can layer alongside a consumption model so that customer-facing agents run on Flex Credits or Per-Conversation while employees use unmetered licenses. Data 360 powers agent grounding through vector search and retrieval, and consumes data-processing capacity, while MuleSoft enables agent integrations that consume API capacity. These variable costs scale with agent usage, which creates an investment pattern that needs financial governance built for variability rather than for a fixed annual subscription.
Solutions designed for business value with optimized cost in the Agentic Enterprise keep agent consumption efficient through actions that process records in bulk, disciplined context windows, and caching. They also deliberately direct spend through the right pricing model, complete TCO modeling, and continuous cost monitoring against business outcomes. Without that alignment, agent deployments accumulate cost without demonstrating proportional value, and an agent that reasons in an unbounded loop can burn credits faster than human oversight can intervene. The same efficiency work that keeps an agent within its governor limits keeps it within its credit budget, which is the pillar thesis expressed in agentic terms.
This document covers what changes when agents are in the picture. For the foundational resource and cost optimization patterns that apply to every Salesforce solution, including performance optimization, governor limits, TCO analysis, and licensing discipline, see the Resource and Cost Optimization pillar. Agent governance and human oversight connect to the Trust and Fairness pillars, which cover the program components that keep autonomous behavior safe and accountable.
Agent resource consumption follows the same platform mechanics as Flow or Apex, but its unpredictable, conversation-driven invocation makes consumption harder to forecast and therefore requires defensive patterns. Your optimization responsibilities span governor-limit budgeting across action chains, API consumption, response latency, Data 360 grounding efficiency, context window management, and the composable design that lets agents scale without duplication. Each responsibility is a value-per-cost decision before it's a technical one, because agents repeat inefficiencies across every conversation.
Agents invoke actions that trigger Apex, Flows, and integrations. A single conversation can execute dozens of actions as the agent reasons through a complex task. The foundational discipline is the same as for any Salesforce solution, but the unpredictable invocation pattern raises the stakes. Design actions to accept collections so that an agent updating 50 cases invokes one action rather than 50 separate calls. A single action operating on a collection of records consumes far fewer Salesforce Object Query Language (SOQL) queries and Data Manipulation Language (DML) operations for the same work. Manage the SOQL budget across action chains deliberately, since a workflow that invokes 10 to 15 actions can approach or exceed the 100-query synchronous limit when each action runs several queries of its own. Use relationship queries to retrieve parent and child data in a single statement, and reference data cached in Platform Cache across actions within the same conversation. These two practices keep a multi-action chain inside its budget.
Move agent operations that exceed synchronous limits into Queueable or Batch Apex, where the asynchronous context roughly doubles the SOQL and CPU headroom available to the work. Large analytical operations, such as scoring 1,000 leads or analyzing sentiment across historical cases, belong in asynchronous processing rather than blocking a conversation. Large-language-model inference itself happens outside Salesforce and consumes Flex Credits rather than Apex CPU time, so the CPU budget you profile is consumed by the action logic, data transformations, and the integrations the agent triggers. Data skew scenarios where parent records are associated with thousands of child records deserve particular defensive attention with agents. This vulnerability arises because an agent may request "all history" for an account with tens of thousands of related records in a way a deterministic query never would. Design actions with hard child-record limits and pagination, and apply sampling when volumes exceed the data-skew threshold. These limits prevent an unpredictable request from turning into an unbounded query. Agentforce Session Tracing identifies which actions consume excessive queries at the session level, and Scale Center monitors overall Apex transaction performance and org health.
Agent architectures consume APIs faster than user-driven workflows, because agents operate autonomously and, for proactive or scheduled agents, continuously. How an agent is surfaced determines how it draws down API capacity. Agents invoked through the REST API consume one call per conversation turn. Agents embedded in Lightning pages through standard components don't consume an API call per interaction, though their cost is still measured in the credits or conversations of the chosen pricing model. Custom Lightning Web Components that make direct REST calls consume API capacity. Components built on Lightning Data Service wire adapters don't, because Lightning Data Service serves from a shared client-side cache rather than issuing an API call. Monitor consumption in Event Monitoring during a pilot so that you understand actual usage before a full rollout.
Event-driven patterns are the largest lever on wasteful agent API consumption. Publishing a Platform Event when a condition requires agent intervention avoids the scheduled polling that consumes API calls whether or not there's work to do, and an agent that subscribes to Change Data Capture events maintains current context without the daily polling calls an external orchestrator would otherwise make. The value-per-cost logic is direct: A poll that finds no work is capacity spent for nothing, and an event that fires only on a real change is capacity spent only on real work. Retrieval-augmented generation adds its own consumption, because each vector search against Data 360 consumes compute, so set retrieval limits to return only the results the agent actually uses.
Latency for an agent turn is the sum of LLM inference time, action execution time, Data 360 query time, and integration time when those steps run in sequence. When they don’t, it's the longest parallel branch plus any sequential steps. Latency is a cost concern as well as an experience concern, because a slow action holds resources open longer and a frustrated user starts more conversations than a resolved one would. Shorter prompts generate faster responses, so remove verbose instructions, redundant examples, and unnecessary context. Selective context improves both latency and answer quality, where an exhaustive context dump only adds noise. Keep actions fast through selective SOQL on indexed fields, bulkification, and cached reference data, because a 3-second action becomes a bottleneck no matter how fast inference is. Validate action queries with the Query Plan tool to identify full table scans that increase action latency.
Agent Builder orchestration can execute actions in parallel when no dependencies exist between them, for example, retrieving account details and related opportunities at the same time takes as long as the slower of the two rather than the sum of both. For calls fanning out to multiple downstream systems, pair Agentforce with an integration platform like MuleSoft; the agent invokes a single action, MuleSoft receives the request and issues parallel calls to backend systems, then returns one aggregated response. Platform Cache removes inference and query latency for repeated requests, and processing non-urgent work asynchronously, such as a long document analysis, lets the agent acknowledge the request immediately and return the result when it's ready rather than holding the conversation open.
Data 360 provides the vector search that grounds agent responses in current data rather than in the model's training data alone, and its efficiency governs both grounding quality and the compute you consume to achieve it. Chunking, embedding selection, metadata filtering, and result limits are the most valuable decisions. Chunk knowledge into semantically meaningful segments, because chunks that are too small force many retrievals for one question while chunks that are too large dilute relevance with irrelevant context and inflate the token budget carried into inference. Choose an embedding model that matches the way your agents actually query, since question-answer similarity behaves differently from document classification, and validate the choice against representative queries. Combine semantic similarity with metadata filters so that business constraints hold regardless of similarity, such as excluding discontinued products from a recommendation no matter how close the match. Set top-k limits to return only the results the agent uses. For example, if 5 results inform an answer, retrieving 50 adds 45 unused results to the grounding payload and token budget.
Unified profiles are resource-efficient because an agent that queries one Data 360 unified profile retrieves complete customer context in a single operation rather than orchestrating separate queries against Account, Contact, Opportunity, Case, and Campaign for every turn. Configure Data 360 instances in the regions that regulatory requirements demand so that agents processing data for a given jurisdiction query the instance that keeps personal data inside it.
Large-language-model context windows hold a finite number of tokens, and managing that budget keeps a long conversation coherent without exhausting capacity or inflating the cost of every inference call. Prioritize deliberately rather than truncating arbitrarily: recent conversation history takes highest priority, critical business data such as current record state and permissions comes second, and older history is included only when space allows. After the first several turns, summarize earlier conversation into a concise overview that preserves critical facts without carrying full verbatim history. This summary preserves continuity without growing the token budget. Store extended context in Data 360 or custom objects as external memory queried on demand rather than replaying the full history in every call, and return only the essential fields from each action, because a response that carries all 50 fields of a record when the task needs 8 spends context budget better allocated to conversation or grounding.
Building agents from reusable components reduces development and maintenance costs. A capability built once and reused is far cheaper over its lifetime than the same capability reimplemented and separately maintained for every agent. Centralized action libraries covering record operations, approvals, notifications, and validation let platform teams maintain consistent behavior, security, and performance across every consuming agent, and they let a new agent be assembled from proven building blocks in days rather than built from custom actions over weeks. Focused specialist agents with clear domain boundaries maintain narrower context and clearer behavior than a single universal agent attempting every scenario, and Agent Builder orchestration coordinates specialists when a task crosses domains. Validated prompt templates in Prompt Builder capture proven patterns for grounding, reasoning, and response formatting so that quality stays consistent as development accelerates, and a shared knowledge base in Data 360 grounds many agents from one source, so an update reaches every consumer at once rather than requiring a change to each agent.
Enterprise teams increasingly compose multiple agents together rather than building single monolithic agents, with an orchestrator agent decomposing a request and delegating to specialist subagents, or specialist agents handing off to one another as a conversation moves across domains. This composition raises resource and cost questions beyond what a single agent faces, because orchestration overhead, inter-agent trust, and state handoff all compound across a chain rather than staying contained to one action. Keep orchestration prompts narrow, limited to classifying intent and routing, rather than asking the orchestrator to also reason about the underlying task, since that reasoning belongs in the subagent with the relevant context, and cap chain depth unless a use case clearly requires deeper nesting than orchestrator-to-subagent. Treat each subagent response as untrusted input, as you would an external API response. Validate its expected shape and compliance with business rules before acting on it. Enforce field-level security and sharing independently for each agent action.
Pass only the state the receiving agent needs, using a structured handoff payload of record IDs, task summary, and relevant fields rather than forwarding raw conversation history, so token budget across the chain stays controlled, and persist cross-agent session state in Data 360 or a custom object when a handoff must survive across separate transactions. Governor limits apply per agent, not once per conversation, so every agent in a chain draws its own SOQL, DML, and CPU budget. A chain of an orchestrator and three subagents consumes each of those limits four times over, and deeper chains multiply consumption further. The same multiplication drives cost, which makes unbounded chain depth a cost risk more than a governor-limit one.
Define what the orchestrator does when a subagent fails, times out, or returns a low-confidence result, whether that's a bounded retry, a fallback response, or escalation to a human, so a single subagent timeout doesn't cascade into failing the entire chain. Correlate a request across every agent it touches with a shared trace ID propagated through the handoff payload, since diagnosing which agent in a chain caused a latency spike or a cost spike otherwise requires manually correlating logs across separate agent sessions.
Failed actions and failed child agent calls don't only affect reliability, because every retry may re-run the SOQL, DML, and CPU work already spent on the failed attempt, and in a multi-agent chain this cost compounds with the number of failed downstream agents. Under consumption-based pricing, the same failure compounds spend as well as compute: a retried action re-consumes credits under Flex Credits. Design retry logic to account for both reliability and cost. Distinguish transient failures, such as a callout timeout or lock contention, from logical failures, such as a validation error or a malformed input, before deciding how to respond, since a transient failure may be worth one bounded retry while a logical failure fails identically on repetition and only burns budget for a guaranteed repeat failure that should escalate immediately instead.
Cap retry attempts per action, at two or three attempts, and apply exponential backoff between them rather than immediate re-invocation, because an unbounded or tight-loop retry on a SOQL- or DML-heavy action can exhaust synchronous limits within a single transaction or burn through cumulative chain budget and cumulative credit spend across a multi-agent conversation. Design actions so a retried call produces the same end state as a single successful call, using an idempotency key such as a request ID or external ID with upsert logic instead of insert, so a retry updates the same record rather than creating a duplicate; an action lacking idempotency forces a retry to either double resource consumption through duplicate downstream records or double the billed actions or conversations for work that already happened once.
Track completion state per agent in a chain, as one agent's action can commit DML successfully before a downstream agent fails, and a failure handler that knows what already succeeded can compensate or resume from the failure point rather than restarting and re-billing the whole chain. Surface retry or in-progress status to the end user while a bounded retry is in flight, because a user who sees silence and repeats their request triggers an entirely new conversation and a new set of actions, compounding the resource and billing cost of the original attempt with a duplicate one.
The resource optimization patterns described throughout this document only help if an architect can see where an agent is actually spending SOQL queries, CPU time, DML rows, and tokens when it's running in production. Without per-action and per-session visibility, a limit breach or a latency regression shows up as a symptom with no way to trace it back to the action or agent in the chain that caused it. This concern is distinct from the spend visibility that Digital Wallet provides under Cost Monitoring and Financial Governance. Digital Wallet shows how many credits or conversations an agent consumed, while the tooling shows why they were consumed, at the level of the individual query, DML row, or action that drove that consumption. The right tool depends on what a given customer's org and support agreement actually grant, not on which tool is theoretically best, so match the recommendation to your license and access tier rather than defaulting to the most capable tool available.
Any architect can build Custom Platform Events that fire at the start and end of each action and subagent invocation. These events trace execution across a conversation using nothing but standard platform capabilities, paired with action-level logging to a custom object capturing SOQL query count, CPU time, DML row count, and heap usage when each action executes. Both events are queryable via reports or SOQL and give every org a baseline diagnostic capability regardless of edition or add-on licensing. Event Monitoring, introduced earlier for tracking API consumption during pilots, also surfaces aggregate resource-usage patterns across agent sessions org-wide for customers whose org includes that add-on, letting an architect identify which workflows are trending toward governor limits across many conversations rather than diagnosing one at a time. Scale Center offers deep tracing of transactions approaching governor limits, typically accessed through a Support engagement or available directly at account tiers that grant it.
Versioning agents independently makes controlled rollout, rollback, and comparison possible, and it protects the investment in a working agent while you improve it. Drive behavior through configuration wherever possible, using Custom Metadata Types and Prompt Builder so that administrators adjust prompt templates and action selection without a development cycle. Use the pilot A/B testing capability to route a small subset of users to an experimental version. Compare quality, satisfaction, and task completion before a full rollout. This comparison validates improvements with real usage and detects regressions while exposure is limited. Define clear interface contracts between components, specifying inputs, outputs, errors, and performance expectations, so that an implementation can be replaced without modifying the agents that depend on it.
Agent economics start with total cost of ownership measured against business value, but the consumption-based pricing of autonomous agents makes the cost side behave in a way traditional licensing doesn't. The pricing model you select is a foundational architectural decision, because it determines what you optimize for across the entire agent lifecycle. This section establishes the pricing models, the full TCO picture for an agent implementation, and the build-versus-buy decision for agent capabilities.
Agentforce offers two consumption-based pricing models, and an organization selects one of the two for a given agent deployment. Flex Credits price per agent action, which makes action efficiency the lever for cost control. Per-Conversation pricing charges a flat fee per conversation regardless of length or complexity, which makes conversation containment the lever. Per-User subscriptions provide unmetered agent usage as an employee-facing add-on rather than a third consumption model, and they shift the optimization focus from consumption efficiency to adoption, because value comes from licensed users actively engaging the agent rather than from minimizing each interaction. The two consumption models aren't mixed for the same org, but a Per-User add-on, offered per user per month for unmetered usage, can layer alongside a consumption model so that customer-facing agents run on Flex Credits or Per-Conversation while employees use unmetered licenses.
Under Flex Credits, action costs are fixed per action up to a defined token ceiling. Unlike token-based inference pricing, the credit cost doesn't vary with prompt length or model complexity, so a one-sentence answer and a multi-paragraph answer cost the same. A multi-action interaction consumes credits for each action, so an interaction that retrieves data, reasons, and updates a record consumes the credits of three actions, and retrieval-augmented generation adds further actions through vector search and document retrieval before reasoning. Understanding the average number of actions per business transaction is therefore the prerequisite for cost modeling under Flex Credits.
Under Per-Conversation pricing, a flat fee applies per conversation, and multiple turns within one session count as a single conversation, so cost control comes from resolving an issue within one conversation and defining clear session boundaries rather than from trimming individual actions. Data 360 grounding and MuleSoft integration consume their own capacity alongside the chosen model, since embedding generation and similarity search draw down data-processing capacity for every grounded query and each external action consumes API capacity in both the source and target systems.
Total cost of ownership (TCO) for an agent implementation spans six categories, and modeling all six turns a credit estimate into an informed investment decision. Development costs cover agent design, prompt engineering, integration development, and testing, and they range widely from a simple single-purpose agent to a multi-agent system with complex orchestration. Inference costs depend on the selected pricing model and require modeling expected action volumes under Flex Credits, conversation volumes under Per-Conversation, or licensed user counts under Per-User. For agents grounded in large knowledge bases, the Data 360 infrastructure that powers grounding can rival or exceed the inference cost. Infrastructure costs cover the Data 360 and MuleSoft licensing, additional sandboxes, and monitoring infrastructure, and they're predominantly fixed or step-function based on capacity tiers. Operational costs cover monitoring operations, prompt refinement, incident response, and user support, and for mature agent programs they commonly equal a meaningful fraction of development cost annually, consistent with general industry benchmarks for AI agents rather than a Salesforce-specific figure. Governance costs cover the safety review, human oversight, audit logging, and compliance validation that grow with agent autonomy and risk, and the Fairness pillar covers the essential program components. Change costs cover user training, business-process adaptation, and organizational change management, and they're the category teams most often underestimate.
Build spreadsheet TCO models that project 3–5-year costs. Document assumptions for interaction volumes, action counts, and growth. Run sensitivity analysis to identify the assumptions that most affect the total, then focus validation on those assumptions. Model all three cost structures, Flex Credits, Per-Conversation, and Per-User, against projected usage before committing, because the optimal structure depends on the usage pattern, and the wrong choice is expensive to unwind once an agent is in production.
The build-versus-buy decision for agents follows the same logic as for any Salesforce capability, weighing the immediate time to value of a ready-made solution against the precise fit of a custom build over a 3–5-year TCO horizon. Commodity workflows favor buying while the core capabilities that drive proprietary differentiation justify building. The Agentic Enterprise offers a spectrum of options rather than a binary choice. Pre-built Agentforce agents, such as a service agent or a sales development representative, provide proven functionality with rapid deployment and platform-maintained updates. They consume credits under the selected pricing model. Commercially available agents from the Salesforce Independent Software Vendor (ISV) community are offered through AgentExchange, where you can find a solution that already meets a requirement rather than building it. Custom agents built with Agent Builder provide precise fit and competitive differentiation at the cost of upfront development plus ongoing prompt refinement and maintenance. Customizing a pre-built agent through Prompt Builder and action configuration provides a middle ground that costs less than full custom development while still adapting the agent to your organization. Beyond cost, weigh time-to-value requirements, internal development capability, strategic differentiation, and vendor-dependency tolerance, and record the decision in an Architecture Decision Record so it can be reassessed as requirements change.
Implementing agents with a clear understanding of the underlying cost structure makes autonomous capability scale sustainably rather than deplete a budget pool. The optimization lever depends on the pricing model, because what you tune to control cost differs between paying per action, paying per conversation, and paying per user. The principle is constant across all three: tune consumption against the value actually delivered, so that a capable agent doesn't quietly burn its budget faster than it returns business outcome.
Under Flex Credits, optimization means minimizing the actions per business outcome while preserving quality. Resolve simple requests in a single action rather than a multi-step workflow, so that answering a FAQ or performing a routine lookup doesn't consume the credits of a three-action chain. Consolidate operations into a single action where it makes sense, combining retrieval, analysis, and response rather than paying for each separately when one action would serve. Cache responses for repeated requests so that frequently asked questions serve from cache rather than consuming fresh actions on every identical query, which is the single largest efficiency lever under this model when a meaningful share of queries repeat.
Under Per-Conversation pricing, optimization means resolving issues within a single conversation rather than across several. Design session boundaries and timeouts so that a conversation persists appropriately without terminating prematurely and forcing a new billable conversation. Focus agent capability on first-conversation resolution so that a task completes within the initial conversation rather than requiring a follow-up. Track the first-conversation resolution rate as a cost-efficiency metric, and discourage scope expansion where a user opens separate conversations for related issues that the existing conversation context could have handled.
Under Per-User subscriptions, optimization means maximizing the value each licensed user returns, because consumption is unmetered and the cost is fixed per seat. Focus on adoption so that licensed users actively engage the agent, track utilization to identify low-usage users for targeted training or license reallocation, and connect agent interactions to business outcomes by user population so that high-value use cases justify the investment while low-value usage signals a need for optimization or a different pricing model. Review user populations on a cadence so that licenses stay aligned with actual usage.
Regardless of the pricing model, architecture influences cost. Implement triage agents that handle initial routing with simple logic and direct users to a specialized agent only when complexity requires it, so that expensive complex invocations happen only when they're warranted. Fall back to traditional automation for deterministic scenarios where rules-based logic suffices, letting Flows handle the deterministic paths at lower cost while agents handle the ambiguous situations that genuinely need reasoning. Retrieve grounding data selectively, invoking vector search and document retrieval only when the agent's reasoning requires it rather than on every interaction, so that Data 360 consumption tracks real need. These patterns keep the reasoning-and-consumption cost of the architecture proportional to the difficulty of the work.
Cost monitoring for autonomous agents is harder than for traditional workloads, because agents don't follow a predictable request-response pattern. An agent can iterate through multi-step reasoning, adaptively invoke tools based on runtime conditions, and coordinate other agents, which produces highly variable credit consumption that's difficult to forecast. Without monitoring, an agent performing deep iterative work can consume a large volume of credits before anyone intervenes, and inefficient prompt design or redundant reasoning loops can quietly drain budgets across an entire agent fleet. Effective governance therefore requires real-time visibility into consumption per agent and per operation, automated alerting, and controls that prevent runaway cost while preserving the autonomy that makes agents useful. Financial governance for agents also needs clear ownership and tiered approval built for variable consumption rather than for static compute cost.
Salesforce Digital Wallet is the built-in tool for monitoring consumption-based products including Agentforce Flex Credits, and organizations using Flex Credits should establish it as the primary cost-monitoring mechanism rather than building custom dashboards to replicate what it provides. Digital Wallet delivers near-real-time consumption data with action-level usage insight, a per-agent breakdown showing which agents consume the most, proactive consumption alerts, and historical trends for pattern analysis and forecasting. Match the monitoring to the pricing model. Under Flex Credits, track consumption by agent, user population, time period, and action type, and supplement Digital Wallet with custom dashboards that connect credit consumption to business transactions. Under Per-Conversation pricing, monitor conversation volumes, average length, and completion rates. Under Per-User subscriptions, monitor utilization rather than consumption, tracking active users and business value per user so that the license investment is shown to deliver proportional value.
Per-interaction cost attribution connects consumption to business transactions and reveals the cost per resolved case, per qualified lead, or per processed order, which enables ROI calculation and cross-use-case comparison. Budget alerting triggers notification as consumption approaches defined thresholds, at thresholds such as 70% and 85% of the budget, so that optimization happens before a limit is reached. Configure alerts per agent and per use case rather than only org-wide to localize a problem to its source. Anomaly detection surfaces the sudden consumption spike that signals an unexpected usage pattern or a reasoning loop that needs investigation. Share cost dashboards with business stakeholders and technical teams so that transparency drives cost-aware agent usage.
Apply financial governance before committing spend to an agent architecture. Require a business case for an agent investment that covers projected TCO over 3–5 years under the selected pricing model, the expected business outcomes with a measurement method, a comparison against alternatives including manual processes and traditional automation, and a risk assessment covering quality, safety, and operational risk. Define approval thresholds that separate the investments a department can authorize from those that require executive approval, so that a high-investment or high-risk agent receives proportionate scrutiny. Mandate pilot deployments that validate assumptions before full production, because a pilot reveals the actual consumption, quality, and adoption that inform both the production investment decision and the pricing-model selection.
Manage the agent estate as a portfolio rather than agent by agent, because a portfolio view reveals optimization opportunities that a single-agent review misses. Review all agents together, comparing cost, usage, business value, and strategic alignment, and define sunsetting criteria that retire agents with low adoption, poor ROI, superseded functionality, or excessive cost, so that low-value agents don't accumulate and consume budget indefinitely. Reallocate investment from low-performing agents to high-value opportunities as a continuous practice that realigns spend with evolving priorities rather than a one-time cleanup.
Cost allocation creates accountability for agent consumption, and organizations implement it through the same two models that apply to the rest of the platform. Showback reports agent costs by business unit without an internal charge, which creates cost awareness and informs optimization discussion without the contention of internal billing. Chargeback allocates actual agent costs to the consuming business units, which drives stronger optimization behavior because the cost affects a departmental budget directly, but it requires an accurate allocation method to avoid disputes. A hybrid approach applies chargeback to high-volume production agents while using showback for experimental or low-volume agents, which balances accountability for major investment against flexibility for innovation.
Agent architectures introduce sustainability considerations of their own, because large-language-model inference is computationally intensive and some agents run continuously rather than only in discrete user-triggered transactions. Proactive, outbound, and scheduled agents operate without a user in the loop, conversational agents accumulate consumption across many turns, and vector search, context preparation, and action execution all add to infrastructure load. Sustainable agent design minimizes computational waste while keeping the experience responsive. As in the Resource and Cost Optimization pillar, the relationship between one solution and data center emissions is indirect. A single tenant's efficiency does not directly lower emissions. However, efficiency gains across all tenants help Salesforce run its infrastructure at higher utilization and defer capacity expansion, and the foundational sustainability practices from the Resource and Cost Optimization pillar apply to agents. The efficiency strategies that follow address what is specific to large-language-model-powered conversational systems. Each also lowers cost, which is why sustainability and value-per-cost are the same discipline measured against different outcomes.
Inference is the most resource-intensive component of an agentic architecture, so efficiency pays off with prompt length, context usage, and caching. Optimize prompts to convey intent in fewer tokens by removing verbose instructions and redundant examples, because a shorter prompt reduces the prefill compute proportionally even though it doesn't change the compute of generating the response. Manage the context window by summarizing conversation history after the first several turns and returning only essential fields from each action, so that the token budget carried into every inference stays bounded rather than growing with the conversation.
Vector search and unified-profile queries consume computational resources, so the same result-limit and filtering discipline that controls grounding cost also reduces the infrastructure load of grounding. Set top-k limits to return only the results the agent uses, because retrieving 50 when 5 informs the answer carries 45 unused results that consume grounding token budget for no benefit, and use metadata filters to narrow the search before similarity ranking. Query unified profiles to assemble complete context in one operation rather than issuing separate queries against several objects for every turn, and cache profiles for agents with high user affinity, such as a sales agent working a fixed set of accounts, so that repeated context assembly doesn't repeat the query.
Agent actions consume SOQL queries, DML operations, and CPU time, so the bulkification, caching, and asynchronous discipline of the Resource and Cost Optimization pillar applies directly to agent actions. Design actions to accept collections so that updating many records is one operation rather than many, use relationship queries to retrieve parent and child data in a single statement, cache reference data in Platform Cache, and batch DML across a collection rather than per record. Move operations that exceed synchronous limits into Queueable or Batch Apex, process non-urgent work such as bulk scoring or historical enrichment asynchronously, and schedule agent-triggered batch jobs for off-peak windows where possible so that load spreads across time rather than concentrating during business hours. Monitor asynchronous execution so that a queue backlog signals a capacity-planning need before it becomes a failure.
Agent consumption patterns evolve as usage grows, so sustainability requires ongoing monitoring rather than a one-time pass. Track the average tokens per inference through the available usage telemetry so that a rising prompt size surfaces an optimization opportunity, monitor conversation-length distribution so that unbounded conversations reveal a task-boundary problem, and analyze action execution frequency in Event Monitoring so that a high-frequency action becomes an optimization priority. Review Data 360 query patterns to find common queries worth caching or pre-computing, track the semantic-cache hit rate so that a low rate triggers threshold tuning, and measure latency percentiles so that tail latency exposes any bottlenecks. Review agent usage regularly for scope drift. For example, investigate an agent whose average conversation length grows from a handful of turns to many over several months. Refine the agent's boundaries so consumption returns to plan. Some of these monitoring surfaces expose usage in aggregate dashboards rather than as a discrete per-inference log, so confirm the exact telemetry available for your configuration when you design the monitoring.
Resource optimization determines whether agent architectures scale as populations grow and use cases expand, and cost optimization determines whether that scale returns proportional business value. These two decisions form a single mandate:
- Architectural efficiency: design actions with bulkification, budget SOQL across action chains, move heavy processing to async, optimize API consumption through composite and event-driven patterns, manage context windows through prioritization and summarization, and build composable architectures from reusable components.
- Financial guidance: select the pricing model deliberately, model complete TCO before committing, monitor consumption against business outcomes, and govern investment through tiered approval and portfolio review.
Organizations that master these patterns deliver responsive agent experiences within platform constraints while keeping spend aligned with the value the agents return.
The foundational resource and cost optimization guidance for all Salesforce solutions, including performance optimization, governor limits, TCO analysis, licensing discipline, and cost governance, lives in the Resource and Cost Optimization pillar. The agent governance, human oversight, and safety program components connect to the Trust and Fairness pillars. The detailed agent implementation guidance in this document, spanning resource efficiency, economics, action optimization, governance, and sustainability, are collected in the agentic pattern library.