Resource and Cost Optimization - Agentic Patterns
Learn more about Well-Architected Resource and Cost Optimization → Agentic Enterprise Resource and Cost Optimization
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Action | ✅ Design Actions accepting collections. Agent processing 50 case updates invokes single Action with collection of case IDs, not 50 separate invocations |
| Agentforce | Action | ✅ Use relationship queries retrieving parent and child data in single SOQL statements to manage SOQL budget across Action chains |
| Platform | Platform Cache | ✅ Cache reference data in Platform Cache eliminating repeated queries across Actions within same conversation |
| Platform | Apex | ✅ Move agent operations exceeding synchronous limits to Queueable or Batch Apex. |
| Platform | Apex | ✅ Profile Actions under load with Apex execution logs. Move compute-heavy processing to async context when approaching synchronous limit |
| Agentforce | Action | ✅ Design Actions with hard child-record limits and pagination for data skew scenarios |
| Agentforce | Action | ✅ Implement sampling when volumes exceed thresholds for agents that may request “all history” unpredictably |
| Platform | Scale Center | ✅ Use Scale Center transaction traces to identify which Actions consume excessive queries |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Action | ⚠️ Invoking separate Actions for each record (e.g., 50 separate calls for 50 case updates) instead of accepting collections |
| Platform | Apex | ⚠️ Running 5-10 SOQL queries per Action in complex workflows of 10-15 Actions, approaching the 100 synchronous SOQL limit |
| Platform | Apex | ⚠️ Running large processing synchronously in an Action instead of in an async context (e.g., scoring 1,000+ leads in synchronous Apex) |
| Agentforce | Action | ⚠️ Allowing agents to retrieve unlimited child records from accounts with 15,000 opportunities or cases with 5,000 activities without defensive coding |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Event Monitoring | ✅ Monitor API consumption in Event Monitoring during pilot phase to understand actual usage before full rollout |
| Data 360 | Configuration | ✅ Set top-k limits on vector search to retrieve only the number of results actually used |
| Data 360 | Analytics | ✅ Monitor vector search result utilization in Data 360 Analytics for tuning of top-k parameters |
| Platform | Platform Events | ✅ Publish Platform Events when conditions require agent intervention rather than scheduled polling consuming API calls regardless of work existence |
| Integration | Action | ✅ Use composite patterns: create a single MuleSoft experience API to aggregate multiple system checks (inventory, pricing, credit) in parallel, agent invokes 1 external Action consuming 1 callout |
| Integration | Action | ✅ Design single MuleSoft flows that execute all downstream updates rather than multiple sequential flows per agent interaction |
| Agentforce | Agent Configuration | ✅ Embed agents in Lightning pages using standard components to avoid consuming API calls per interaction |
| Business | Planning | ✅ Evaluate MuleSoft licensing models (transaction-based vs platform licensing) against projected agent transaction volumes to determine best economics |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Data 360 | Configuration | ⚠️ Retrieving top 50 vector search results when using only top 5, wasting 90% of compute and context budget |
| Platform | Scheduled Jobs | ⚠️ Scheduled polling consuming API calls regardless of work existence (e.g., checking every 5 minutes finding no work 80% of time) |
| Integration | Named Credentials | ⚠️ Using 3 separate Actions consuming 3 callouts instead of a single composite API aggregating multiple system calls |
| Platform | Apex | ⚠️ Custom LWCs making explicit API requests consuming API calls when standard Lightning components could avoid this |
| Integration | External Systems | ⚠️ External systems polling Salesforce for state changes consuming hundreds of daily API calls instead of subscribing to CDC events |
| Integration | Action | ⚠️ Making sequential API calls for each step (query customer, query products, check inventory, create order, update inventory, notify shipping) consuming 12+ calls per transaction when composite patterns would reduce consumption 75% |
| Integration | Agent Configuration | ⚠️ Orchestrating agent actions across many systems without evaluating whether each system interaction is necessary, multiplying API consumption with each added system |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Prompt Template | ✅ Minimize prompt length: remove verbose instructions, redundant examples, unnecessary context. Selective context improves both latency and quality |
| Platform | Apex | ✅ Use selective SOQL with indexed filters. Leverage Query Plan Tool identifying missing indexes causing full table scans |
| Agentforce | Agent Configuration | ✅ Use parallel Action execution when no dependencies exist. Retrieving account details and opportunities simultaneously halves latency versus sequential retrieval |
| Platform | Platform Cache | ✅ Cache frequently accessed reference data (product catalogs, territory mappings, pricing rules) eliminating repeated SOQL |
| Platform | Platform Cache | ✅ Implement semantic caching matching similar queries to serve repeated requests without new inference |
| Platform | Apex | ✅ Process non-urgent requests asynchronously (status updates, batch processing, report generation) using generous async governor limits |
| Platform | Apex | ✅ Profile Actions under realistic data volumes. An Action taking 3s becomes bottleneck regardless of fast LLM inference |
| Agentforce | Action | ✅ Implement bulkification in Actions to minimize execution time per operation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Prompt Template | ⚠️ Including exhaustive context that adds noise instead of selective context that improves both latency and quality |
| Agentforce | Agent Configuration | ⚠️ Executing Actions sequentially when no dependencies exist (e.g., account query 2s + opportunities query 2s = 4s sequential instead of 2s parallel) |
| Platform | Apex | ⚠️ Running full table scans due to missing indexes instead of using selective SOQL with indexed filters |
| Platform | Platform Cache | ⚠️ Querying Data 360 repeatedly (1.5s per call) for common data that could be cached (50ms from Platform Cache) |
| Agentforce | Agent Configuration | ⚠️ Requiring synchronous completion for non-urgent operations (status updates, batch processing, report generation) |
Patterns
| Where to look | What good looks like |
|---|---|
| Data 360 | Configuration | ✅ Chunk knowledge articles, product docs, case history into semantically meaningful 250-750 word segments |
| Data 360 | Configuration | ✅ Validate chunk size against agent query patterns. Balance precision (smaller chunks) versus context completeness (larger chunks) |
| Data 360 | Configuration | ✅ Use embeddings matching agent query patterns. Validate selection against representative queries measuring retrieval precision and recall |
| Data 360 | Configuration | ✅ Enhance vector similarity with metadata filters ensuring business constraints (e.g., filter to active products excluding discontinued items regardless of semantic similarity) |
| Data 360 | Configuration | ✅ Use unified profiles aggregating customer data from multiple sources into single view. Access complete context (attributes, insights, engagement, predictions) in single query |
| Data 360 | Configuration | ✅ Enable Identity Resolution providing accurate cross-system customer matching |
| Data 360 | Configuration | ✅ Configure Data 360 instances in regions matching regulatory requirements for data residency compliance |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Data 360 | Configuration | ⚠️ Using overly large chunks that include irrelevant information diluting relevance in vector search results |
| Data 360 | Configuration | ⚠️ Relying solely on semantic similarity without metadata filters, returning discontinued or low-quality results |
| Data 360 | Configuration | ⚠️ Orchestrating multiple separate source queries instead of using Data 360 unified profiles for complete customer context |
| Data 360 | Configuration | ⚠️ Using embedding models that don’t match agent query patterns (e.g., document classification embeddings for question-answer similarity) |
| Data 360 | Configuration | ⚠️ Processing European customer data on non-European Data 360 instances, violating data residency requirements |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Agent Configuration | ✅ Prioritize context explicitly: recent conversation history (highest), critical business data/record state/permissions (second), historical context (lowest, only when space allows) |
| Agentforce | Agent Configuration | ✅ After 10-15 turns, summarize early conversation into concise overview maintaining critical facts without full verbatim history |
| Data 360 | Configuration | ✅ Store extended context in Data 360 or custom objects rather than full history in every LLM call. Query on demand keeping prompts focused on current needs |
| Agentforce | Action | ✅ Return only essential fields from Action responses. Account retrieval returns fields relevant to current task, not all 50 fields |
| Agentforce | Agent Configuration | ✅ Design explicit prioritization logic versus arbitrary truncation for context window allocation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Agent Configuration | ⚠️ Arbitrary truncation of context without explicit prioritization logic |
| Agentforce | Agent Configuration | ⚠️ Maintaining full verbatim conversation history beyond 10-15 turns, exhausting context budget |
| Agentforce | Agent Configuration | ⚠️ Including full history in every LLM call instead of storing extended context externally and querying on demand |
| Agentforce | Action | ⚠️ Returning all 50 fields from account retrieval when only a subset is relevant to the current task, consuming context budget |
| Agentforce | Agent Configuration | ⚠️ Allocating context budget without reserving sufficient space for response generation |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Action | ✅ Develop centralized Action libraries covering record CRUD, approvals, notifications, reporting, validation. Platform teams maintain ensuring consistent behavior, security, performance |
| Agentforce | Agent Configuration | ✅ Create focused specialist agents with deep domain expertise (service agent for case management, sales agent for opportunity guidance) maintaining narrower context and clearer boundaries |
| Agentforce | Agent Configuration | ✅ Use Agent Builder orchestration coordinating specialist agents for cross-domain needs |
| Agentforce | Prompt Template | ✅ Maintain validated prompt patterns in Prompt Builder. Templates capture proven approaches for RAG query formation, multi-step reasoning, response formatting |
| Agentforce | Prompt Template | ✅ Version prompt templates enabling A/B testing of improvements |
| Data 360 | Configuration | ✅ Maintain shared knowledge bases in Data 360 serving multiple agents. Single product knowledge base grounds sales, service, and partner portal agents |
| Agentforce | Agent Configuration | ✅ Compose new agents from proven building blocks: define purpose, select Actions, configure prompts (days versus weeks for custom builds) |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Prompt Template | ⚠️ Creating ad-hoc prompts for each agent instead of reusing validated prompt template libraries |
| Agentforce | Action | ⚠️ Reimplementing Actions for each agent instead of using centralized reusable Action libraries |
| Agentforce | Agent Configuration | ⚠️ Building universal agents attempting all scenarios instead of focused specialist agents with deep domain expertise |
| Data 360 | Configuration | ⚠️ Duplicating knowledge bases per agent instead of sharing a single knowledge base that grounds multiple agents |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Custom Metadata Types | ✅ Use Custom Metadata Types and Prompt Builder controlling behavior without code changes. Admins modify prompt templates and reasoning parameters without development cycles |
| Agentforce | Agent Configuration | ✅ Route subsets to experimental versions comparing quality metrics, satisfaction, task completion before full rollout (e.g., 10% to v2, 90% on v1) |
| Agentforce | Agent Configuration | ✅ Monitor validation period and maintain rollback capability if issues discovered during A/B testing |
| Agentforce | Action | ✅ Define clear interface contracts between components: Actions specify inputs, outputs, errors, performance expectations |
| Agentforce | Agent Configuration | ✅ Gradually expand successful versions (10% to 25% to 50% to 100%) over multi-week rollout periods |
| Agentforce | Action | ✅ Replace Action implementations without agent modifications when interface contracts are preserved |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Apex | ⚠️ Requiring code changes to modify agent behavior instead of using configuration-driven approaches (Custom Metadata Types, Prompt Builder) |
| Agentforce | Agent Configuration | ⚠️ Full rollout of new agent versions without A/B testing on a subset comparing quality metrics and satisfaction |
| Agentforce | Action | ⚠️ Agents depending on Action implementation details rather than interface contracts, breaking when implementations change |
| Agentforce | Agent Configuration | ⚠️ Deploying new versions to 100% of users immediately without graduated rollout |
| Agentforce | Agent Configuration | ⚠️ Operating without rollback capability during experimental version testing |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Agent Configuration | ✅ Resolve each request in as few agent actions as possible — Flex Credits are consumed per action, so consolidating multi-step logic into a single action lowers cost directly |
| Agentforce | Agent Configuration | ✅ Model monthly cost projections based on documented Flex Credit consumption rates and expected interaction volumes enabling budget planning |
| Einstein | Monitoring | ✅ Monitor Flex Credit consumption by agent, use case, and user population to identify high-consumption patterns requiring optimization |
| Einstein | Monitoring | ✅ Compare actual consumption against projections to inform future planning and identify optimization opportunities |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Agent Configuration | ⚠️ Chaining many small actions where one consolidated action would resolve the request, multiplying Flex Credit consumption per interaction |
| Business | Planning | ⚠️ Discovering Flex Credit consumption exceeds projections only after production deployment because no per-interaction cost modeling was performed |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Agent Configuration | ✅ Design session boundaries and timeouts so a conversation persists appropriately without terminating prematurely and forcing a new billable conversation |
| Agentforce | Agent Configuration | ✅ Focus agent capability on first-conversation resolution so a task completes within the initial conversation rather than requiring a billable follow-up |
| Einstein | Monitoring | ✅ Track first-conversation resolution rate as the cost-efficiency metric under Per-Conversation pricing |
| Agentforce | Agent Configuration | ✅ Handle related issues within the existing conversation context rather than opening separate conversations that each incur a flat fee |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Agent Configuration | ⚠️ Terminating conversations prematurely through short session timeouts, forcing users to start new billable conversations to finish a single task |
| Einstein | Monitoring | ⚠️ Monitoring only total conversation volume without tracking first-conversation resolution rate, missing the primary cost lever under Per-Conversation pricing |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Drive adoption so licensed users actively engage the agent, since under unmetered Per-User pricing value comes from usage rather than from minimizing each interaction |
| Einstein | Monitoring | ✅ Track utilization to identify low-usage licensed users for targeted training or license reallocation |
| Business | Documentation | ✅ Connect agent interactions to business outcomes by user population so high-value use cases justify the per-seat investment |
| Business | Planning | ✅ Review user populations on a cadence so licenses stay aligned with actual usage rather than drifting into over-licensing |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Provisioning Per-User licenses without an adoption plan, paying fixed per-seat cost for users who rarely engage the agent |
| Einstein | Monitoring | ⚠️ Never reviewing utilization by user population, letting licenses drift into the same over-licensing that wastes traditional seats |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Agent Configuration | ✅ Implement triage agents that handle initial routing with simple logic, directing users to a specialized agent only when complexity requires it |
| Platform | Flow | ✅ Fall back to Flow automation for deterministic scenarios where rules-based logic suffices, reserving agent reasoning for the ambiguous situations that genuinely need it |
| Data 360 | Agent Configuration | ✅ Retrieve grounding data selectively, invoking vector search and document retrieval only when the agent’s reasoning requires it rather than on every interaction |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Agent Configuration | ⚠️ Routing every request straight to a specialized agent, incurring expensive complex invocations for requests that simple triage logic could have handled |
| Platform | Flow | ⚠️ Using agent reasoning for deterministic rules-based workflows that a Flow would execute at lower cost without variable consumption |
| Data 360 | Agent Configuration | ⚠️ Retrieving grounding data on every interaction regardless of whether reasoning requires it, driving Data 360 consumption that doesn’t track real need |
Patterns
| Where to look | What good looks like |
|---|---|
| Data 360 | Agent Configuration | ✅ Cache product catalog embeddings with defined refresh cadence (e.g., 24-hour), retrieving from cache for routine questions and querying Data 360 only for new or customer-specific data |
| Data 360 | Agent Configuration | ✅ Implement caching strategies to reduce repeated queries for common requests, balancing cost optimization against data freshness requirements |
| Data 360 | Org | ✅ Model upfront data ingestion and processing costs (harmonization, identity resolution, embedding generation) separately from incremental growth costs |
| Data 360 | Agent Configuration | ✅ Evaluate whether RAG overhead justifies quality improvements for specific use cases before adding retrieval-augmented generation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Data 360 | Agent Configuration | ⚠️ No caching implemented despite the majority of queries being identical common questions, consuming Flex Credits for repeated identical responses |
| Data 360 | Org | ⚠️ Implementing aggressive caching without considering data freshness requirements, serving stale information to users |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Org | ✅ Use Partial Copy sandbox with targeted customer data sample for agent development, reserving Full Copy sandbox exclusively for pre-production validation |
| Platform | Org | ✅ Plan for development infrastructure costs upfront including Data 360 capacity, Flex Credits for prompt testing, and integration connectivity |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Org | ⚠️ Every developer provisioning Full Copy sandboxes for agent development, multiplying sandbox costs 5x |
| Platform | Org | ⚠️ Relying on ad-hoc manual testing providing insufficient coverage, discovering quality issues only in production |
| Business | Planning | ⚠️ Making development infrastructure costs invisible during planning, resulting in significant unexpected costs during implementation |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Build comprehensive TCO model covering all six cost categories: development, inference (Flex Credits), infrastructure (Data 360 + MuleSoft), operations, governance, and change management |
| Business | Documentation | ✅ Create spreadsheet TCO models projecting 3-5 year costs with documented assumptions for interaction volumes, credit consumption rates, and growth trajectories |
| Business | Documentation | ✅ Perform sensitivity analysis revealing which assumptions most affect total investment, enabling focused validation efforts |
| Business | Documentation | ✅ Model ongoing operational costs as a meaningful recurring fraction of development costs annually for mature agents, drawn from general AI-agent industry benchmarks rather than a fixed Salesforce figure |
| Business | Planning | ✅ Include change management costs (user training, business process adaptation, organizational change) which are frequently underestimated |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Including only development cost in agent business case without modeling ongoing consumption (Flex Credits, Data 360, operations), discovering significant unplanned annual costs after deployment |
| Business | Planning | ⚠️ Omitting governance overhead (safety reviews, human oversight infrastructure, audit logging, compliance validation) which grows with agent autonomy and risk level |
| Business | Planning | ⚠️ Underestimating change costs especially for agents creating significant workflow shifts, leading to budget shortfalls |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Evaluate pre-built Agentforce agents versus custom development through comprehensive 3-year TCO comparison including maintenance costs |
| Business | Documentation | ✅ Document build vs buy decisions in Architecture Decision Records enabling future reassessment as costs and capabilities change |
| Agentforce | Agent Configuration | ✅ Consider customization of pre-built agents through Prompt Builder and action configuration as middle ground between out-of-box and fully custom |
| Business | Planning | ✅ Factor decision criteria beyond cost: time-to-value, organizational development capability, strategic differentiation value, and vendor dependency tolerance |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Building custom agent because “we want control” without modeling 3-year TCO showing pre-built option may be significantly cheaper |
| Business | Planning | ⚠️ Choosing build or buy based solely on first-year costs without projecting ongoing maintenance, credit consumption, and vendor update benefits over multi-year horizon |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Compare agent TCO against traditional automation alternatives (Flow, Apex, manual processes) before deployment, validating investment justification |
| Business | Documentation | ✅ Establish manual process baseline including fully-loaded employee costs, error rates, processing time, and throughput capacity to reveal potential savings |
| Agentforce | Agent Configuration | ✅ Deploy agents for tasks requiring natural language understanding, adaptive reasoning, or handling high scenario variability where traditional automation cannot match capability |
| Platform | Flow | ✅ Use Flow automation for deterministic workflows with clear rules, providing equivalent outcomes at lower cost without variable inference consumption |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Agent Configuration | ⚠️ Deploying agent for simple deterministic routing task consuming $15K annual credits when Flow would provide equivalent functionality with no variable costs |
| Business | Planning | ⚠️ Defaulting to agent approach for all automation without evaluating whether traditional automation provides equivalent outcomes at lower total cost |
Patterns
| Where to look | What good looks like |
|---|---|
| Einstein | Monitoring | ✅ Build Flex Credit consumption dashboards showing consumption by agent, user population, time period, and interaction type for rapid identification of consumption spikes |
| Einstein | Monitoring | ✅ Implement per-interaction cost attribution connecting credit consumption to business transactions (cost per resolved case, cost per qualified lead, cost per processed order) |
| Einstein | Monitoring | ✅ Configure budget alerting at example thresholds such as 70% and 85% by agent and use case (not only organization-wide) enabling proactive intervention before overruns |
| Einstein | Monitoring | ✅ Implement anomaly detection identifying unusual consumption patterns (sudden spikes indicating prompt inefficiencies, unexpected usage patterns, or abuse) |
| Business | Documentation | ✅ Share cost dashboards with business stakeholders and technical teams creating transparency enabling cost-aware agent usage |
| Business | Documentation | ✅ Conduct quarterly budget reviews comparing actual consumption against projections, evaluating business outcomes, and adjusting allocations based on demonstrated value |
| Business | Planning | ✅ Reserve 10-15% of credit budget for experimentation and unexpected consumption growth, preventing innovation bottlenecks |
| Business | Planning | ✅ Create multi-year projections based on agent adoption trends, new deployments, and expanding use cases enabling capacity planning and vendor negotiations |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Einstein | Monitoring | ⚠️ Monitoring credit consumption only through monthly invoice review, discovering budget overruns 6 weeks into quarter without time to optimize before renewal |
| Einstein | Monitoring | ⚠️ Configuring budget alerts only at the organization level, missing per-agent and per-use-case consumption spikes that indicate optimization opportunities |
| Business | Planning | ⚠️ Requiring emergency budget increases because consumption monitoring was not implemented early enough to identify and address overruns proactively |
| Business | Planning | ⚠️ Setting an annual budget once at fiscal year start without reviews, starving high-value agents for credits while low-ROI agents consume the allocation |
| Business | Planning | ⚠️ Allocating zero budget reserve for experimentation, forcing teams to justify every new use case through lengthy approval before any exploration |
Patterns
| Where to look | What good looks like |
|---|---|
| Einstein | Monitoring | ✅ Track consumption by agent instance enabling comparison across agent types and use cases, revealing which agents deliver best ROI |
| Business | Documentation | ✅ Connect consumption to business processes (lead qualification, case resolution, order processing) enabling business leaders to evaluate strategic alignment |
| Einstein | Monitoring | ✅ Track consumption by department, role, or user segment revealing where agent adoption is highest and where costs concentrate |
| Business | Planning | ✅ Use quarterly cost reviews to compare agent ROI across portfolio and reallocate investment from low-ROI to high-ROI agents based on demonstrated value |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Allocating all agent costs to IT budget without business unit attribution, preventing business leaders from evaluating whether spending aligns with priorities |
| Business | Planning | ⚠️ Treating agent consumption as undifferentiated cost without connecting consumption to business outcomes, making ROI calculation impossible |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Implement showback reporting providing consumption visibility by business unit, creating cost awareness enabling informed usage decisions without contentious chargeback disputes |
| Business | Documentation | ✅ Use hybrid allocation with chargeback for high-volume production agents and showback for experimental or low-volume agents, balancing accountability with innovation flexibility |
| Business | Documentation | ✅ Conduct quarterly reviews discussing whether consumption aligns with value delivered, leading to optimization commitments |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Implementing full chargeback for experimental agents, discouraging innovation and exploration by immediately imposing budget accountability on nascent use cases |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Prompt Template | ✅ Eliminate unnecessary verbosity in system prompts recognizing every extra token adds prefill compute and latency across all interactions — trim system prompts to what the agent actually uses |
| Agentforce | Prompt Template | ✅ Include only relevant information through selective context retrieval with relevance ranking ensuring highest-value information fits within context limits |
| Agentforce | Prompt Template | ✅ Specify concise response formatting for routine interactions, minimizing completion tokens by avoiding requests for elaborate formatting or extensive explanations |
| Agentforce | Prompt Template | ✅ Reuse standardized prompt templates across similar agents, amortizing prompt optimization investment while creating consistency and efficiency |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Prompt Template | ⚠️ Writing prompts conversationally without optimization consuming 2K+ tokens per interaction including verbose instructions and extensive examples that agents rarely reference |
| Agentforce | Prompt Template | ⚠️ Retrieving all potentially-related data for context rather than selectively including only relevant information, inflating prompt token consumption |
| Agentforce | Prompt Template | ⚠️ Creating unique prompt templates for every agent rather than standardizing patterns, multiplying prompt engineering effort without proportional quality benefit |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Agent Configuration | ✅ Cache common agent responses for frequently-asked questions serving directly from cache for duplicate queries (cache hit rates above 30% indicate significant optimization opportunity) |
| Data 360 | Agent Configuration | ✅ Cache stable knowledge context (product catalogs, policy documents, reference materials) reducing retrieval overhead for every interaction referencing common information |
| Agentforce | Agent Configuration | ✅ Implement conversation caching within user sessions maintaining context across turns without re-sending full history, reducing token consumption in multi-turn interactions |
| Agentforce | Agent Configuration | ✅ Define cache invalidation strategies based on content volatility (product information caches for hours/days, real-time data should not cache) |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Agent Configuration | ⚠️ No caching implemented despite 60% of queries being identical common questions, unnecessarily consuming Flex Credits for repeated identical responses |
| Agentforce | Agent Configuration | ⚠️ Caching real-time data (inventory levels, pricing, availability) that requires freshness, serving stale information that leads to incorrect agent responses |
| Agentforce | Agent Configuration | ⚠️ Never refreshing cached responses leading to outdated answers as products, policies, or processes change |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Require business case including projected 3-year TCO, expected business outcomes with measurement methodology, comparison against alternatives, and risk assessment |
| Business | Documentation | ✅ Define approval thresholds that separate investments a department can authorize from those requiring executive approval, so higher-investment or higher-risk agents receive proportionate executive scrutiny |
| Business | Documentation | ✅ Mandate pilot deployments validating assumptions (consumption, quality, adoption) before full production investment |
| Business | Documentation | ✅ Include ROI calculation in agent proposals (e.g., 4:1 return demonstrated through cases resolved and manual handling cost savings) |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Deploying agents without business case, discovering 3x projected credit consumption while delivering unclear business value, creating unplanned annual consumption without documented ROI |
| Business | Planning | ⚠️ Skipping pilot deployment and going directly to full production, missing opportunity to validate consumption assumptions before committing full budget |
| Business | Planning | ⚠️ Approving agent investments without comparison against alternative approaches (manual processes, traditional automation) that may deliver equivalent value at lower cost |
Patterns
| Where to look | What good looks like |
|---|---|
| Business | Documentation | ✅ Conduct annual portfolio review evaluating all agents comparing cost, usage, business value, and strategic alignment to reveal optimization opportunities missed by agent-by-agent review |
| Business | Documentation | ✅ Define sunsetting criteria (low adoption, poor ROI, superseded functionality, excessive cost) preventing accumulation of low-value agents consuming budget |
| Business | Planning | ✅ Practice continuous investment reallocation shifting resources from low-performing agents to high-value opportunities aligned with evolving business priorities |
| Business | Documentation | ✅ Categorize agents by ROI tier (e.g., top 2 deliver 70% value at 50% cost = excellent; middle 4 deliver 25% value at 35% cost = acceptable; bottom 2 deliver 5% value at 15% cost = sunset candidates) |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Business | Planning | ⚠️ Agents deployed remaining in production indefinitely without utilization or value review, accumulating low-value agents consuming budget that could fund higher-value opportunities |
| Business | Planning | ⚠️ Evaluating agents only individually without portfolio perspective, missing the insight that a few agents deliver most value while many consume disproportionate resources |