Resource- en kostenoptimalisatie voor de Agentic Enterprise
Autonome agenten verbruiken Salesforce-resources anders dan deterministische automatisering. Agentwerkbelastingen zijn onvoorspelbaar en continu, in plaats van vast en transactiegebonden. De waarde-per-kosten stelling van de pijler Resource- en kostenoptimalisatie wordt rechtstreeks doorgevoerd in de Agentic Enterprise. Resource-efficiëntie betekent het gebruik van de capaciteit waarvoor u al betaalt, terwijl kostenoptimalisering betekent dat uitgaven bewust worden gericht op de autonome mogelijkheden die rendement opleveren. Agenten wijzigen de vorm van beide. Efficiënt agentontwerp houdt het verbruik onder controle, terwijl selectie van prijsmodellen, total cost of ownership (TCO)-modellering en financiële governance de uitgaven in lijn houden met de waarde. Dit document behandelt resource-efficiëntie en kostenoptimalisering als één beslissing, omdat agenten twee weergaven van hetzelfde doel hebben.
Agenten wijzigen de voorspelbaarheid van verbruik. Een traditioneel Apex proces werkt op een bekende recordset met bekende resourcekosten. Een agent voert gesprekken en één gesprek kan tientallen acties uitvoeren zoals de agent redeneert via een taak. Elke actie verbruikt beheerlimieten binnen de eigen transactie in plaats van deze in het gesprek te verzamelen. Contextvoorbereiding voor één beurt kan een query uitvoeren op 200 records of 20.000, afhankelijk van wat de gebruiker vraagt. API-verbruik versnelt omdat agenten autonoom kunnen handelen en proactieve, uitgaande en geplande agenten continu handelen in plaats van alleen tijdens een gebruikerstransactie. Deze onvoorspelbaarheid is de reden waarom resourcebeheer voor agenten defensief van opzet moet zijn in plaats van afgestemd nadat een consumptiepiek heeft plaatsgevonden.
De kostenzijde verandert evenzeer. Autonome agenten introduceren op verbruik gebaseerde prijzen die anders werken dan traditionele licenties per stoel. Agentforce biedt twee op verbruik gebaseerde prijsmodellen, Flex Credits en Per gesprek. Elke agentimplementatie selecteert een van deze modellen. Een organisatie gebruikt één verbruiksmodel tegelijk. , maar een uitbreiding per gebruiker, die per gebruiker per maand wordt aangeboden voor niet-gemeten gebruik, kan worden gelaagd naast een verbruiksmodel, zodat klantgerichte agenten Flexcredits of Per gesprek gebruiken terwijl werknemers licenties zonder meter gebruiken. Data 360 ondersteunt agentaarding door middel van vectorzoekopdrachten en -ophalen, en verbruikt gegevensverwerkingscapaciteit, terwijl MuleSoft agentintegraties mogelijk maakt die API-capaciteit verbruiken. Deze variabele kosten schalen mee met het gebruik van agenten, waardoor een investeringspatroon ontstaat dat financiële governance vereist die is gebaseerd op variabiliteit in plaats van op een vast jaarabonnement.
Oplossingen die zijn ontworpen voor bedrijfswaarde met geoptimaliseerde kosten in Agentic Enterprise, houden het verbruik van agenten efficiënt door acties die records in bulk verwerken, gedisciplineerde contextvensters en caching. Ze sturen uitgaven ook bewust door het juiste prijsmodel, complete TCO-modellering en continue kostenbewaking ten opzichte van bedrijfsresultaten. Zonder die uitlijning accumuleren agentimplementaties kosten zonder proportionele waarde aan te tonen, en kan een agent die in een onbeperkte lus redeneert, sneller kredieten verbranden dan menselijk toezicht kan ingrijpen. Hetzelfde efficiëntiewerk dat een agent binnen zijn beheerlimieten houdt, houdt het binnen zijn kredietbudget, wat de pijlerstelling is, uitgedrukt in agentische termen.
Dit document behandelt wat er verandert wanneer agenten in beeld zijn. Zie de pijler Resource- en kostenoptimalisering voor de fundamentele resource- en kostenoptimaliseringspatronen die van toepassing zijn op elke Salesforce-oplossing, inclusief prestatieoptimalisering, beheerlimieten, TCO-analyse en licentiediscipline. Agent-governance en menselijk toezicht sluiten aan op de pijlers Trust en Fairness, die de programmacomponenten bestrijken die autonoom gedrag veilig en verantwoordelijk houden.
Verbruik van agentresources volgt dezelfde platformmechanismen als Flow of Apex, maar de onvoorspelbare, door gesprekken gestuurde aanroep ervan maakt verbruik moeilijker te voorspellen en vereist daarom defensieve patronen. Uw optimaliseringsverantwoordelijkheden omvatten budgettering voor beheerlimieten binnen actieketens, API-verbruik, reactielatentie, Data 360-aardingsefficiëntie, contextvensterbeheer en het samenstelbare ontwerp waarmee agenten kunnen schalen zonder dupliceren. Elke verantwoordelijkheid is een beslissing op basis van waarde per kosten voordat deze technisch is, omdat agenten inefficiënties herhalen in elk gesprek.
Agenten roepen acties aan die Apex, stromen en integraties activeren. Eén gesprek kan tientallen acties uitvoeren zoals de agent redeneert door een complexe taak. De basisdiscipline is hetzelfde als voor elke Salesforce-oplossing, maar het onvoorspelbare aanroeppatroon verhoogt de inzet. Ontwerp acties om verzamelingen te accepteren zodat een agent die 50 cases bijwerkt, één actie aanroept in plaats van 50 afzonderlijke aanroepen. Eén actie die op een verzameling records wordt uitgevoerd, verbruikt veel minder Salesforce Object Query Language-query’s (SOQL) en DML-bewerkingen (Data Manipulation Language) voor hetzelfde werk. Beheer het SOQL-budget voor alle actieketens bewust, aangezien een werkstroom die 10 tot 15 acties aanroept, de synchrone limiet van 100 query’s kan benaderen of overschrijden wanneer elke actie meerdere eigen query’s uitvoert. Gebruik relatiequery’s om bovenliggende en onderliggende gegevens op te halen in één instructie en verwijs naar gegevens die in het cachegeheugen van Platform zijn opgeslagen voor acties binnen hetzelfde gesprek. Deze twee praktijken houden een keten van meerdere acties binnen het budget.
Verplaats agentbewerkingen die synchrone limieten overschrijden, naar Queueable of Batch Apex, waar de asynchrone context grofweg de SOQL- en CPU-ruimte verdubbelt die beschikbaar is voor het werk. Grote analytische bewerkingen, zoals het scoren van 1000 leads of het analyseren van gevoel over historische cases, behoren tot asynchrone verwerking in plaats van het blokkeren van een gesprek. De gevolgtrekking van een model met een grote taal zelf vindt plaats buiten Salesforce en verbruikt Flex Credits in plaats van Apex CPU-tijd, waardoor het CPU-budget dat u profileert, wordt verbruikt door de actielogica, gegevenstransformaties en de integraties die de agent activeert. Scheve scenario’s met gegevens waarin bovenliggende records zijn gekoppeld aan duizenden onderliggende records, verdienen speciale defensieve aandacht bij agenten. Deze kwetsbaarheid ontstaat omdat een agent “alle historie” kan opvragen voor een account met tienduizenden gerelateerde records op een manier die een deterministische query nooit zou doen. Ontwerp acties met harde onderliggende recordlimieten en paginering, en pas steekproeven toe wanneer volumes de drempelwaarde voor vertekende gegevens overschrijden. Deze limieten voorkomen dat een onvoorspelbaar verzoek een onbegrensde query wordt. Agentforce Sessietracering identificeert welke acties buitensporige query’s verbruiken op sessieniveau, en Scale Center bewaakt de algehele Apex transactieprestaties en de gezondheid van de organisatie.
Agentarchitecturen verbruiken API’s sneller dan door de gebruiker gestuurde werkstromen, omdat agenten autonoom en, voor proactieve of geplande agenten, continu werken. Hoe een agent zichtbaar wordt, bepaalt hoe deze API-capaciteit benut. Agenten die worden aangeroepen via de REST-API, verbruiken één gesprek per gespreksbeurt. Agenten die via standaardcomponenten zijn ingebed in Lightning pagina’s, verbruiken geen API-aanroep per interactie, hoewel hun kosten nog steeds worden gemeten in de credits of gesprekken van het gekozen prijsmodel. Aangepaste Lightning webcomponenten die directe REST-aanroepen doen, verbruiken API-capaciteit. Componenten die zijn gebouwd op Lightning Data Service-draadadapters, doen dat niet, omdat Lightning Data Service wordt bediend vanuit een gedeeld clientcachegeheugen in plaats van een API-aanroep uit te geven. Bewaak het verbruik in Event Monitoring tijdens een pilot, zodat u inzicht krijgt in het feitelijke gebruik voordat een volledige implementatie plaatsvindt.
Eventgestuurde patronen vormen de grootste hefboom voor het verspillen van API-gebruik door agenten. Het publiceren van een Platform-event wanneer een voorwaarde tussenkomst van een agent vereist, vermijdt de geplande polling die API-aanroepen verbruikt, ongeacht of er werk aan de winkel is, en een agent die zich abonneert op events voor Gegevensvastlegging wijzigen, behoudt de huidige context zonder de dagelijkse pollingaanroepen die een externe orchestrator anders zou doen. De logica van waarde per kosten is direct: Een opiniepeiling die geen werk vindt, is capaciteit die voor niets is uitgegeven, en een event dat alleen een echte verandering aanspoort, is capaciteit die alleen aan echt werk is besteed. Het genereren van gegevens met augmented generation voegt zijn eigen verbruik toe, omdat elke vectorzoekopdracht tegen Data 360 berekening verbruikt. Stel daarom ophaallimieten in om alleen de resultaten te retourneren die de agent daadwerkelijk gebruikt.
Latentie voor een agentbeurt is de som van de LLM-inferentietijd, de uitvoeringstijd van de actie, de Data 360-querytijd en de integratietijd wanneer die stappen op volgorde worden uitgevoerd. Wanneer dit niet het geval is, is dit de langste parallelle vertakking plus eventuele opeenvolgende stappen. Latentie is zowel een kostenprobleem als een ervaringsprobleem, omdat een langzame actie resources langer openhoudt en een gefrustreerde gebruiker meer gesprekken start dan een opgeloste. Kortere aanwijzingen genereren snellere reacties, dus verwijder uitgebreide instructies, overbodige voorbeelden en onnodige context. Selectieve context verbetert zowel de latentie als de antwoordkwaliteit, waarbij een uitputtende contextdump alleen maar ruis toevoegt. Houd acties snel door middel van selectieve SOQL voor geïndexeerde velden, bulkverwerking en verwijzingsgegevens in het cachegeheugen, omdat een actie van 3 seconden een bottleneck wordt, ongeacht hoe snel gevolgtrekking is. Valideer actiequery’s met de tool Queryplan om volledige tabelscans te identificeren die de actielatentie vergroten.
Agent Builder doeltreffende combinatie kan acties parallel uitvoeren wanneer er geen afhankelijkheden tussen bestaan, bijvoorbeeld het ophalen van accountdetails en gerelateerde opportunities tegelijkertijd duurt zo lang als de langzame van de twee in plaats van de som van beide. Voor gesprekken die zich verspreiden naar meerdere downstreamsystemen, koppelt u Agentforce aan een integratieplatform zoals MuleSoft. De agent roept één actie aan, MuleSoft ontvangt het verzoek en stuurt parallelle gesprekken naar back-endsystemen en retourneert vervolgens één geaggregeerde respons. Platformcachegeheugen verwijdert gevolgtrekkingen en querylatentie voor herhaalde verzoeken. Door niet-dringend werk asynchroon te verwerken, zoals een lange documentanalyse, kan de agent het verzoek onmiddellijk bevestigen en het resultaat retourneren wanneer het klaar is, in plaats van het gesprek open te houden.
Data 360 biedt de vectorzoekopdracht die responsen van agenten baseert in actuele gegevens in plaats van alleen in de trainingsgegevens van het model. De efficiëntie ervan bepaalt zowel de aardingskwaliteit als de berekening die u verbruikt om deze te bereiken. Chunking, selectie inbedden, filteren van metagegevens en resultaatlimieten zijn de meest waardevolle beslissingen. Splits Knowledge op in semantisch betekenisvolle segmenten, omdat blokken die te klein zijn, veel ophalingen voor één vraag afdwingen, terwijl blokken die te groot zijn, de relevantie verwateren met irrelevante context en het tokenbudget opblazen tot gevolgtrekking. Kies een inbeddingsmodel dat overeenkomt met de manier waarop uw agenten daadwerkelijk een query uitvoeren, aangezien de vraag-antwoordgelijksoortigheid anders werkt dan documentclassificatie, en valideer de keuze op basis van representatieve query’s. Combineer semantische gelijksoortigheid met metagegevensfilters zodat zakelijke beperkingen ongeacht gelijksoortigheid blijven bestaan, zoals het uitsluiten van stopgezette producten van een aanbeveling, ongeacht hoe dicht de overeenkomst is. Stel top-k-limieten in om alleen de resultaten te retourneren die de agent gebruikt. Als bijvoorbeeld 5 resultaten een antwoord geven, worden met het ophalen van 50 45 ongebruikte resultaten toegevoegd aan de aardingspayload en het tokenbudget.
Gecombineerde profielen zijn resource-efficiënt omdat een agent die een query uitvoert op één gecombineerd Data 360-profiel, de volledige klantcontext ophaalt in één bewerking, in plaats van afzonderlijke query’s op Account, Contactpersoon, Opportunity, Case en Campagne voor elke beurt te organiseren. Configureer Data 360-exemplaren in de regio’s die door wettelijke vereisten worden vereist, zodat agenten die gegevens verwerken voor een bepaald rechtsgebied, een query uitvoeren op het exemplaar dat persoonsgegevens daarin bewaart.
Contextvensters met een groot taalmodel bevatten een beperkt aantal tokens, en het beheer van dat budget houdt een lang gesprek coherent zonder capaciteit uit te putten of de kosten van elk gevolggesprek op te drijven. Prioriteer bewust in plaats van willekeurig af te kappen: recente gesprekshistorie heeft de hoogste prioriteit, kritieke bedrijfsgegevens zoals huidige recordstatus en machtigingen komen op de tweede plaats en oudere historie wordt alleen opgenomen wanneer de ruimte dit toestaat. Na de eerste paar beurten vat u eerdere gesprekken samen in een beknopt overzicht dat kritieke feiten bewaart zonder de volledige woordelijke geschiedenis te dragen. Deze samenvatting behoudt continuïteit zonder het tokenbudget te laten groeien. Sla uitgebreide context op in Data 360 of aangepaste objecten als extern geheugen waarop on-demand een query wordt uitgevoerd, in plaats van de volledige historie in elk gesprek opnieuw af te spelen, en retourneer alleen de essentiële velden van elke actie, omdat een respons die alle 50 velden van een record overdraagt wanneer de taak 8 nodig heeft, contextbudget beter besteedt aan gesprek of aarding.
Agenten bouwen op basis van herbruikbare componenten verlaagt de ontwikkeling- en onderhoudskosten. Een mogelijkheid die één maal is gebouwd en hergebruikt, is veel goedkoper dan dezelfde mogelijkheid die voor elke agent opnieuw wordt geïmplementeerd en afzonderlijk wordt onderhouden. Met gecentraliseerde actiebibliotheken met recordbewerkingen, goedkeuringen, kennisgevingen en validatie kunnen platformteams consistent gedrag, beveiliging en prestaties handhaven voor elke consumerende agent, en kunnen ze binnen enkele dagen een nieuwe agent samenstellen op basis van beproefde bouwstenen in plaats van deze te laten samenstellen op basis van aangepaste acties in weken. Gerichte gespecialiseerde agenten met duidelijke domeingrenzen behouden een smallere context en een duidelijker gedrag dan één universele agent die elk scenario probeert, en Agentsamensteller coördineert specialisten wanneer een taak domeinen overschrijdt. Gevalideerde aanwijzingssjablonen in Aanwijzingensamensteller leggen bewezen patronen vast voor aarding, redenering en responsopmaak, zodat de kwaliteit consistent blijft terwijl de ontwikkeling versnelt. Een gedeelde Knowledge base in Data 360 base base baseert veel agenten op één bron, waardoor een update elke consument tegelijk bereikt in plaats van dat elke agent moet worden gewijzigd.
Enterpriseteams stellen steeds vaker meerdere agenten samen in plaats van één monolithische agent samen, waarbij een doeltreffende agent een verzoek ontbindt en delegeert aan gespecialiseerde subagenten, of gespecialiseerde agenten aan elkaar overhandigt terwijl een gesprek tussen domeinen loopt. Deze samenstelling roept resource- en kostenvragen op die verder reiken dan wat één agent tegenkomt, omdat doeltreffende overhead, inter-agent Trust en staatshandling alle componenten binnen een keten leveren in plaats van beperkt te blijven tot één actie. Houd doeltreffende aanwijzingen smal, beperk u tot het classificeren van intent en routering, in plaats van de orchestrator te vragen om ook te redeneren over de onderliggende taak, aangezien die redenering thuishoort in de subagent met de relevante context, en sluit de ketendiepte af, tenzij een gebruikscase duidelijk dieper nesten vereist dan orchestrator-naar-subagent. Behandel elke subagentrespons als niet-vertrouwde invoer, zoals u een externe API-respons zou doen. Valideer de verwachte vorm en naleving van bedrijfsregels voordat u actie onderneemt. Dwing beveiliging op veldniveau en delen onafhankelijk af voor elke agentactie.
Geef alleen de status door die de ontvangende agent nodig heeft, met behulp van een gestructureerde payload voor overdrachten van record-ID’s, taaksamenvatting en relevante velden in plaats van ruwe gesprekshistorie door te sturen, zodat het tokenbudget binnen de keten onder controle blijft en de sessiestatus voor agenten behouden blijft in Data 360 of een aangepast object wanneer een overdracht moet overleven binnen afzonderlijke transacties. Beheerlimieten gelden per agent, niet eenmaal per gesprek, waardoor elke agent in een keten zijn eigen SOQL-, DML- en CPU-budget opmaakt. Een keten van een orchestrator en drie subagenten verbruikt elk van die limieten vier keer meer, en diepere ketens vermenigvuldigen het verbruik verder. Dezelfde vermenigvuldiging drijft de kosten op, waardoor een onbeperkte ketendiepte een kostenrisico is dat groter is dan een beheerlimiet.
Definieer wat de orchestrator doet wanneer een subagent mislukt, een time-out ondervindt of een resultaat met weinig vertrouwen retourneert, of dat nu een begrensde hernieuwde poging, een reservereactie of escalatie naar een mens is, zodat één time-out voor een subagent niet leidt tot een mislukking van de gehele keten. Correleer een aanvraag voor elke agent die deze aanraakt met een gedeelde tracerings-ID die wordt gepropageerd via de handoffpayload, aangezien het anders nodig is om logboeken handmatig te correleren voor afzonderlijke agentsessies om te bepalen welke agent in een keten een latentiepiek of kostenpiek heeft veroorzaakt.
Mislukte acties en mislukte onderliggende agentaanroepen hebben niet alleen invloed op de betrouwbaarheid, omdat elke nieuwe poging het SOQL-, DML- en CPU-werk dat al aan de mislukte poging is besteed, opnieuw kan uitvoeren, en in een keten met meerdere agenten lopen de kosten nog hoger op dan het aantal mislukte agenten verderop in de stroom. Bij op verbruik gebaseerde prijsstelling besteden en berekenen dezelfde foutcompounds: een opnieuw geprobeerde actie verbruikt kredieten onder Flexkredietpunten opnieuw. Ontwerp logica voor opnieuw proberen om rekening te houden met zowel betrouwbaarheid als kosten. Onderscheid tijdelijke mislukkingen, zoals een time-out van een aanroep of vergrendelingsbetwisting, van logische mislukkingen, zoals een validatiefout of een verkeerd gevormde invoer, voordat u beslist hoe u gaat reageren, aangezien een tijdelijke mislukking het waard kan zijn om één keer opnieuw te proberen, terwijl een logische mislukking identiek mislukt bij herhaling en alleen budget verbrandt voor een gegarandeerde herhalingsfout die in plaats daarvan onmiddellijk zou moeten escaleren.
Leg nieuwe pogingen per actie vast, bij twee of drie pogingen, en pas daartussen exponentiële backoff toe in plaats van onmiddellijke hernieuwde aanroep, omdat een onbeperkte of strakke hernieuwde poging op een SOQL- of DML-zware actie synchrone limieten binnen één transactie kan uitputten of cumulatieve ketenbudgetten en cumulatieve kredietuitgaven kan opbranden in een gesprek met meerdere agenten. Ontwerp acties zo dat een opnieuw geprobeerd gesprek dezelfde eindstatus produceert als één succesvol gesprek, met behulp van een idempotentiesleutel zoals een verzoek-ID of externe ID met upsert-logica in plaats van invoegen, waardoor een nieuwe poging dezelfde record bijwerkt in plaats van een duplicaat te maken. Een actie zonder idempotentie dwingt een nieuwe poging af om ofwel het resourceverbruik te verdubbelen via duplicaatrecords verderop in de stroom, ofwel het aantal gefactureerde acties of gesprekken te verdubbelen voor werk dat al eens is gebeurd.
Houd de voltooiingsstatus per agent in een keten bij, aangezien de actie van één agent DML met succes kan uitvoeren voordat een agent verderop in de stroom mislukt, en een fouthandler die weet wat al is gelukt, kan compenseren of hervatten vanaf het foutpunt in plaats van de hele keten opnieuw te starten en opnieuw te factureren. De status van een nieuwe poging aan de oppervlakte of in uitvoering voor de eindgebruiker terwijl een begrensde nieuwe poging in uitvoering is, omdat een gebruiker die stilte ziet en zijn verzoek herhaalt, een volledig nieuw gesprek en een nieuwe set acties activeert, waarbij de resource- en factureringskosten van de oorspronkelijke poging worden gecombineerd met een duplicaat.
De resourceoptimaliseringspatronen die in dit document worden beschreven, helpen alleen als een architect kan zien waar een agent daadwerkelijk SOQL-query’s, CPU-tijd, DML-rijen en tokens uitgeeft wanneer deze in productie is. Zonder zichtbaarheid per actie en per sessie wordt een limietinbreuk of een latentieregressie weergegeven als een symptoom zonder een manier om het te traceren naar de actie of agent in de keten die het heeft veroorzaakt. Deze zorg verschilt van de zichtbaarheid van uitgaven die Digital Wallet biedt onder Kostenbewaking en Financiële governance. Digital Wallet toont hoeveel kredieten of gesprekken een agent heeft verbruikt, terwijl de tooling toont waarom ze zijn verbruikt, op het niveau van de afzonderlijke query, DML-rij of actie die dat verbruik heeft aangestuurd. De juiste tool is afhankelijk van wat de organisatie en de ondersteuningsovereenkomst van een bepaalde klant daadwerkelijk verlenen, niet van welke tool theoretisch het beste is. Stem de aanbeveling dus af op uw licentie en toegangslaag, in plaats van standaard de meest geschikte tool te kiezen die beschikbaar is.
Elke architect kan aangepaste platformevents samenstellen die aan het begin en einde van elke actie en subagentaanroep worden geactiveerd. Deze events traceren de uitvoering van een gesprek met behulp van niets anders dan standaard platformmogelijkheden, in combinatie met vastleggen op actieniveau naar een aangepast object dat de SOQL-querytelling, CPU-tijd, DML-rijtelling en heapgebruik vastlegt wanneer elke actie wordt uitgevoerd. Beide events kunnen worden opgevraagd via rapporten of SOQL en geven elke organisatie een baseline diagnostische mogelijkheid, ongeacht edition of uitbreidingslicentie. Event Monitoring, dat eerder is geïntroduceerd voor het bijhouden van API-verbruik tijdens pilots, maakt ook geaggregeerde patronen voor resourcegebruik binnen agentsessies organisatiebreed zichtbaar voor klanten wier organisatie die uitbreiding bevat, waardoor een architect kan bepalen welke werkstromen trenden naar beheerlimieten voor veel gesprekken in plaats van een diagnose per gesprek te stellen. Scale Center biedt diepgaande tracering van transacties die beheerlimieten benaderen, doorgaans toegankelijk via een ondersteuningsbetrokkenheid of rechtstreeks beschikbaar op accountlagen die deze verlenen.
Met versiebeheeragenten kunt u gecontroleerd implementeren, terugdraaien en vergelijken, en het beschermt de investering in een werkende agent terwijl u deze verbetert. Bevorder waar mogelijk de werking door configuratie met behulp van Typen aangepaste metagegevens en Aanwijzingensamensteller zodat beheerders aanwijzingssjablonen en actieselectie kunnen aanpassen zonder een ontwikkelingscyclus. Gebruik de mogelijkheid voor proef-A/B-tests om een kleine subset van gebruikers naar een experimentele versie te routeren. Vergelijk kwaliteit, tevredenheid en taakvoltooiing vóór een volledige implementatie. Deze vergelijking valideert verbeteringen met echt gebruik en detecteert regressies terwijl de blootstelling beperkt is. Definieer duidelijke interfacecontracten tussen componenten en geef invoer, uitvoer, fouten en prestatieverwachtingen op, zodat een implementatie kan worden vervangen zonder de agenten te wijzigen die ervan afhankelijk zijn.
Agenteconomie begint met totale eigendomskosten gemeten aan de bedrijfswaarde, maar de op verbruik gebaseerde prijsstelling van autonome agenten zorgt ervoor dat de kostenzijde zich gedraagt op een manier die traditionele licenties niet doen. Het prijsmodel dat u selecteert, is een fundamentele architectonische beslissing, omdat het bepaalt waarvoor u optimaliseert gedurende de gehele levenscyclus van agenten. In deze sectie worden de prijsmodellen, het volledige TCO-beeld voor een agentimplementatie en de beslissing tussen samenstellen en kopen voor agentmogelijkheden vastgesteld.
Agentforce biedt twee op verbruik gebaseerde prijsmodellen en een organisatie selecteert een van de twee modellen voor een bepaalde agentimplementatie. Flex Credits-prijs per agentactie, waardoor actie-efficiëntie de hefboom is voor kostenbeheersing. Prijsstelling per gesprek brengt een vast bedrag per gesprek in rekening, ongeacht de lengte of complexiteit, waardoor gespreksbeheersing de hefboom is. Abonnementen per gebruiker bieden onbeperkt agentgebruik als een uitbreiding voor werknemers in plaats van een derde consumptiemodel, en ze verleggen de focus van optimalisering van verbruiksefficiëntie naar acceptatie, omdat waarde ontstaat door gelicentieerde gebruikers die actief betrokken zijn bij de agent, in plaats van elke interactie te minimaliseren. De twee verbruiksmodellen worden niet gemengd voor dezelfde organisatie, maar een uitbreiding per gebruiker, die per gebruiker per maand wordt aangeboden voor niet-gemeten gebruik, kan worden gelaagd naast een verbruiksmodel, zodat klantgerichte agenten Flexkredietpunten of Per gesprek gebruiken terwijl werknemers licenties zonder meter gebruiken.
Bij Flexkredietpunten worden actiekosten per actie vastgesteld tot een gedefinieerd tokenplafond. In tegenstelling tot op tokens gebaseerde gevolgtrekkingenprijzen variëren de kredietkosten niet naargelang de lengte van de aanwijzing of de complexiteit van het model, waardoor een antwoord van één zin en een antwoord van meerdere alinea’s hetzelfde kosten. Een interactie met meerdere acties verbruikt kredieten voor elke actie, dus een interactie die gegevens en redenen ophaalt en een record bijwerkt, verbruikt kredieten van drie acties, terwijl genereren met ophalen door middel van een augmented generatie verdere acties toevoegt door middel van vectorzoekopdrachten en het ophalen van documenten vóór redeneren. Inzicht in het gemiddelde aantal acties per bedrijfstransactie is daarom een vereiste voor kostenmodellering onder Flexkredietpunten.
Bij prijsstelling per gesprek gelden vaste kosten per gesprek en tellen meerdere beurten binnen één sessie als één gesprek. Kostenbeheersing komt dus voort uit het oplossen van een probleem binnen één gesprek en het definiëren van duidelijke sessiegrenzen in plaats van het afkappen van afzonderlijke acties. Data 360-aarding en MuleSoft-integratie verbruiken hun eigen capaciteit naast het gekozen model, aangezien het inbedden van genereren en zoeken naar gelijksoortigheid gegevensverwerkingscapaciteit verbruikt voor elke geaarde query en elke externe actie API-capaciteit verbruikt in zowel het bron- als het doelsysteem.
Total Cost of Ownership (TCO) voor de implementatie van een agent omvat zes categorieën, en het modelleren van alle zes maakt van een kredietschatting een weloverwogen investeringsbeslissing. Ontwikkelingskosten omvatten agentontwerp, prompt engineering, integratieontwikkeling en testen, en variëren sterk van een eenvoudige agent voor één doel tot een multi-agentsysteem met complexe doeltreffende combinatie. Interferentiekosten zijn afhankelijk van het geselecteerde prijsmodel en vereisen modellering van verwachte actievolumes onder Flexkredietpunten, gespreksvolumes onder Gesprek of gelicentieerde gebruikerstellingen onder Gebruiker. Voor agenten die zijn gegrondvest in grote Knowledge bases, kan de Data 360-infrastructuur die aarding aandrijft, concurreren met of de gevolgkosten overtreffen. De infrastructuurkosten dekken de Data 360- en MuleSoft-licenties, extra sandboxen en bewakingsinfrastructuur, en ze zijn overwegend vast of stapsgewijs op basis van capaciteitslagen. Operationele kosten omvatten bewakingsactiviteiten, snelle verfijning, incidentrespons en gebruikersondersteuning, en voor volwassen agentprogramma’s bedragen ze doorgaans een aanzienlijk deel van de ontwikkelingskosten per jaar, in overeenstemming met algemene benchmarks voor de sector voor AI-agenten in plaats van een Salesforce-specifiek cijfer. De governancekosten dekken de veiligheidsbeoordeling, het menselijk toezicht, het vastleggen van audits en de nalevingsvalidatie die groeien met de autonomie en het risico van agenten, terwijl de pijler Eerlijkheid de essentiële programmacomponenten bestrijkt. Veranderingskosten dekken gebruikerstraining, aanpassing van bedrijfsprocessen en organisatorisch veranderingsbeheer, en zijn de categorieteams die het vaakst worden onderschat.
Stel spreadsheet-TCO-modellen samen die kosten van 3 tot 5 jaar voorspellen. Documenteer aannames voor interactievolumes, actietellingen en groei. Voer een gevoeligheidsanalyse uit om de aannames te identificeren die het meest van invloed zijn op het totaal en richt de validatie vervolgens op die aannames. Maak een model van alle drie de kostenstructuren, Flex Credits, Per-gesprek en Per-gebruiker, op basis van geprojecteerd gebruik voordat u doorvoert, omdat de optimale structuur afhankelijk is van het gebruikspatroon en de verkeerde keuze duur is om af te bouwen zodra een agent in productie is.
De beslissing tussen samenstellen en kopen voor agenten volgt dezelfde logica als voor alle andere Salesforce-mogelijkheden, waarbij de onmiddellijke tijd tot waarde van een kant-en-klare oplossing wordt afgewogen tegen de precieze pasvorm van een aangepaste samenstelling over een TCO-horizon van 3 tot 5 jaar. Grondstoffenwerkstromen geven de voorkeur aan kopen, terwijl de kernmogelijkheden die eigen differentiatie stimuleren, bouwen rechtvaardigen. De Agentic Enterprise biedt een spectrum aan opties in plaats van een binaire keuze. Vooraf samengestelde Agentforce agenten, zoals een serviceagent of een Sales Development Representative, bieden bewezen functionaliteit met snelle implementatie en platform-onderhouden updates. Ze verbruiken kredieten volgens het geselecteerde prijsmodel. Commercieel beschikbare agenten uit de Salesforce Independent Software Vendor-community (ISV) worden aangeboden via AgentExchange, waar u een oplossing kunt vinden die al aan een vereiste voldoet, in plaats van deze te bouwen. Aangepaste agenten die zijn samengesteld met Agentsamensteller, bieden nauwkeurige pasvorm en concurrentiedifferentiatie tegen de kosten van ontwikkeling vooraf plus voortdurende snelle verfijning en onderhoud. Het aanpassen van een vooraf samengestelde agent door middel van Aanwijzingensamensteller en actieconfiguratie biedt een middenweg die minder kost dan volledige aangepaste ontwikkeling, terwijl de agent toch wordt aangepast aan uw organisatie. Weeg naast de kosten ook de tijd-naar-waardevereisten, interne ontwikkelingsmogelijkheden, strategische differentiatie en leveranciersafhankelijkheidstolerantie af en leg de beslissing vast in een Architectuurbeslissingsrecord zodat deze opnieuw kan worden beoordeeld wanneer de vereisten veranderen.
Implementerende agenten met een duidelijk inzicht in de onderliggende kostenstructuur maken autonome capaciteiten duurzaam schaalbaar in plaats van een budgetpool uit te putten. De optimaliseringshefboom is afhankelijk van het prijsmodel, omdat wat u afstemt om de kosten te beheersen, verschilt tussen betalen per actie, betalen per gesprek en betalen per gebruiker. Het principe is constant voor alle drie: stem het verbruik af op de daadwerkelijk geleverde waarde, zodat een capabele agent niet stilletjes zijn budget sneller verbrandt dan het bedrijfsresultaat oplevert.
Onder Flex Credits betekent optimalisering het minimaliseren van de acties per bedrijfsresultaat met behoud van kwaliteit. Los eenvoudige verzoeken op in één actie in plaats van een werkstroom met meerdere stappen, zodat het beantwoorden van een veelgestelde vraag of het uitvoeren van een routinezoekopdracht niet de credits van een keten van drie acties verbruikt. Consolideer bewerkingen in één actie waar dat zinvol is, door ophalen, analyse en respons te combineren in plaats van voor elke actie afzonderlijk te betalen wanneer één actie zou dienen. Cacheresponsen voor herhaalde verzoeken zodat veelgestelde vragen worden weergegeven vanuit het cachegeheugen in plaats van nieuwe acties te verbruiken voor elke identieke query. Dit is de grootste efficiëntiehefboom onder dit model wanneer een betekenisvol deel van de query’s wordt herhaald.
Bij prijsstelling per gesprek betekent optimalisering dat problemen worden opgelost binnen één gesprek in plaats van binnen meerdere gesprekken. Ontwerp sessiegrenzen en time-outs zodat een gesprek op de juiste manier wordt voortgezet zonder voortijdig te worden beëindigd en een nieuw factureerbaar gesprek af te dwingen. Richt de mogelijkheden van agenten op de oplossing van het eerste gesprek, zodat een taak wordt voltooid binnen het eerste gesprek in plaats van dat er een vervolg nodig is. Houd de oplossingsscore voor het eerste gesprek bij als een kostenefficiëntiemeetgegeven en ontmoedig bereikuitbreiding waarbij een gebruiker afzonderlijke gesprekken opent voor gerelateerde problemen die de bestaande gesprekscontext had kunnen afhandelen.
Bij abonnementen per gebruiker betekent optimalisering het maximaliseren van de waarde die elke gelicentieerde gebruiker retourneert, omdat het verbruik niet wordt gemeten en de kosten per seat vastliggen. Richt u op acceptatie zodat gelicentieerde gebruikers de agent actief betrekken, houd de inzet bij om gebruikers met weinig gebruik te identificeren voor gerichte training of het opnieuw toewijzen van licenties, en verbind interacties van agenten met bedrijfsresultaten op gebruikerspopulatie, zodat gebruikscases met een hoge waarde de investering rechtvaardigen, terwijl gebruik met een lage waarde een behoefte aan optimalisering of een ander prijsmodel aangeeft. Bekijk gebruikerspopulaties op een cadans zodat licenties afgestemd blijven op het feitelijke gebruik.
Ongeacht het prijsmodel heeft de architectuur invloed op de kosten. Implementeer triageagenten die de initiële routering met eenvoudige logica afhandelen en gebruikers alleen naar een gespecialiseerde agent leiden wanneer de complexiteit dit vereist, zodat dure complexe aanroepen alleen plaatsvinden wanneer ze gerechtvaardigd zijn. Maak gebruik van traditionele automatisering voor deterministische scenario’s waarin op regels gebaseerde logica volstaat, zodat stromen de deterministische trajecten tegen lagere kosten kunnen afhandelen, terwijl agenten de ambigue situaties afhandelen die echt redenering vereisen. Haal aardingsgegevens selectief op, waarbij vectorzoekopdrachten en het ophalen van documenten alleen worden aangeroepen wanneer de redenering van de agent dit vereist, in plaats van bij elke interactie, zodat het verbruik van Data 360 de werkelijke behoefte bijhoudt. Deze patronen houden de redenering- en consumptiekosten van de architectuur in verhouding tot de moeilijkheidsgraad van het werk.
Kostenbewaking voor autonome agenten is moeilijker dan voor traditionele werkbelasting, omdat agenten geen voorspelbaar verzoek-reactiepatroon volgen. Een agent kan redeneren in meerdere stappen, tools adaptief aanroepen op basis van run-time voorwaarden en andere agenten coördineren, wat leidt tot een sterk variabel kredietverbruik dat moeilijk te voorspellen is. Zonder bewaking kan een agent die diep herhalend werk uitvoert, een groot volume kredieten verbruiken voordat iemand ingrijpt, terwijl inefficiënt promptontwerp of redundante redeneringslussen stilletjes budgetten kunnen verspillen voor een heel agentenpark. Effectieve governance vereist daarom realtime inzicht in het verbruik per agent en per bewerking, geautomatiseerde waarschuwingen en controles die op hol geslagen kosten voorkomen en tegelijkertijd de autonomie behouden die agenten nuttig maakt. Financiële governance voor agenten heeft ook duidelijk eigendom en gelaagde goedkeuring nodig, die zijn gebaseerd op variabel verbruik en niet op statische berekeningskosten.
Salesforce Digital Wallet is de ingebouwde tool voor het bewaken van op verbruik gebaseerde producten, waaronder Agentforce Flex Credits, en organisaties die Flex Credits gebruiken, moeten dit instellen als het primaire kostenbewakingsmechanisme in plaats van aangepaste dashboards te maken om te repliceren wat het biedt. Digital Wallet biedt vrijwel realtime verbruiksgegevens met inzicht in gebruik op actieniveau, een analyse per agent die toont welke agenten het meeste verbruiken, proactieve verbruikswaarschuwingen en historische trends voor patroonanalyse en prognoses. Koppel de bewaking aan het prijsmodel. Houd onder Flexkredieten verbruik bij op agent, gebruikerspopulatie, tijdsbestek en actietype, en vul Digital Wallet aan met aangepaste dashboards die kredietverbruik koppelen aan zakelijke transacties. Bewaak onder Prijzen per gesprek gesprek gespreksvolumes, gemiddelde lengte en voltooiingsscores. Bewaak onder abonnementen per gebruiker de inzet in plaats van het verbruik, waarbij u actieve gebruikers en bedrijfswaarde per gebruiker bijhoudt, zodat de licentie-investering proportionele waarde oplevert.
Kostentoekenning per interactie koppelt verbruik aan zakelijke transacties en toont de kosten per opgeloste case, per gekwalificeerde lead of per verwerkte order, wat een ROI-berekening en vergelijking tussen cases mogelijk maakt. Budgetwaarschuwingen activeren een kennisgeving wanneer het verbruik gedefinieerde drempelwaarden nadert, bij drempelwaarden zoals 70% en 85% van het budget, zodat optimalisering plaatsvindt voordat een limiet wordt bereikt. Configureer waarschuwingen per agent en per gebruikscase in plaats van alleen voor de hele organisatie om een probleem naar de bron te lokaliseren. Anomaliedetectie brengt de plotselinge verbruikspiek aan het licht die een onverwacht gebruikspatroon of een redeneringslus signaleert die onderzoek vereist. Deel kostendashboards met zakelijke belanghebbenden en technische teams zodat transparantie het kostenbewuste gebruik van agenten stimuleert.
Pas financiële governance toe voordat u uitgaven doet voor een agentarchitectuur. Vereist een bedrijfscase voor een agentinvestering die de geprojecteerde TCO over 3-5 jaar dekt volgens het geselecteerde prijsmodel, de verwachte bedrijfsresultaten met een meetmethode, een vergelijking met alternatieven, waaronder handmatige processen en traditionele automatisering, en een risicobeoordeling voor kwaliteit, veiligheid en operationeel risico. Definieer goedkeuringsdrempels die de investeringen die een afdeling kan autoriseren, scheiden van die welke goedkeuring van de uitvoerende macht vereisen, zodat een agent met een hoge investering of een agent met een hoog risico proportioneel wordt gecontroleerd. Verplicht proefimplementaties die aannames valideren vóór volledige productie, omdat een proef het feitelijke verbruik, de kwaliteit en de acceptatie aan het licht brengt, die zowel de beslissing over de productie-investering als de selectie van het prijsmodel bepalen.
Beheer de nalatenschap van agenten als een portfolio in plaats van agent per agent, omdat een portfolioweergave optimaliseringsopportunities onthult die een beoordeling door één agent mist. Controleer alle agenten samen, vergelijk kosten, gebruik, bedrijfswaarde en strategische afstemming, en definieer criteria voor “sunsetting” (het opnieuw instellen van de status) die agenten met een laag acceptatiepercentage, slecht investeringsrendement, achterhaalde functionaliteit of buitensporige kosten met pensioen sturen, zodat agenten met een lage waarde niet voor onbepaalde tijd budgetten verzamelen en verbruiken. Wijs investeringen van slecht presterende agenten toe aan opportunities met een hoge waarde als een continue praktijk die uitgaven opnieuw afstemt op veranderende prioriteiten in plaats van een eenmalige schoonmaak.
Kostentoewijzing creëert verantwoordelijkheid voor het verbruik van agenten en organisaties implementeren dit via dezelfde twee modellen die van toepassing zijn op de rest van het platform. Showback rapporteert agentkosten per bedrijfseenheid zonder interne kosten, wat kostenbewustzijn creëert en optimaliseringsdiscussies mogelijk maakt zonder de discussie over interne facturering. Chargeback wijst feitelijke agentkosten toe aan de verbruikende bedrijfseenheden, wat een sterker optimaliseringsgedrag bevordert omdat de kosten rechtstreeks van invloed zijn op een afdelingsbudget, maar het vereist een nauwkeurige toewijzingsmethode om geschillen te voorkomen. Een hybride benadering past chargeback toe op productieagenten met groot volume, terwijl showback wordt gebruikt voor experimentele agenten of agenten met klein volume, waardoor een balans wordt gevonden tussen verantwoording voor grote investeringen en flexibiliteit voor innovatie.
Agentarchitecturen introduceren zelf duurzaamheidsoverwegingen, omdat gevolgtrekkingen voor grote-taalmodellen rekenintensief zijn en sommige agenten continu worden uitgevoerd in plaats van alleen in afzonderlijke door gebruikers geactiveerde transacties. Proactieve, uitgaande en geplande agenten werken zonder een gebruiker in de lus, gespreksagenten accumuleren verbruik over vele beurten en vectorzoekopdrachten, contextvoorbereiding en actie-uitvoering dragen allemaal bij aan de belasting van de infrastructuur. Duurzaam agentontwerp minimaliseert verspilling van berekeningen en houdt de ervaring responsief. Net als in de pijler Resource- en kostenoptimalisatie is de relatie tussen één oplossing en emissies van datacenters indirect. De efficiëntie van één belanghebbende verlaagt niet direct de emissies. Efficiëntieverbeteringen voor alle belanghebbenden helpen Salesforce echter om zijn infrastructuur beter in te zetten en capaciteitsuitbreiding uit te stellen. De fundamentele duurzaamheidspraktijken van de pijler Resource- en kostenoptimalisering zijn van toepassing op agenten en de efficiëntiestrategieën die volgen, hebben beide betrekking op wat specifiek is voor gesprekssystemen met een model met grote taal. Beide verlagen ook de kosten, waardoor duurzaamheid en value-per-cost dezelfde discipline zijn, gemeten aan de hand van verschillende uitkomsten.
Inferentie is de meest resource-intensieve component van een agentische architectuur, dus efficiëntie loont met promptlengte, contextgebruik en caching. Optimaliseer aanwijzingen om intent over te brengen in minder tokens door uitgebreide instructies en redundante voorbeelden te verwijderen, omdat een kortere aanwijzing de berekening van vooraf invullen proportioneel reduceert, ook al verandert deze de berekening van het genereren van de respons niet. Beheer het contextvenster door de gesprekshistorie na de eerste paar beurten samen te vatten en alleen essentiële velden uit elke actie te retourneren, zodat het tokenbudget dat in elke gevolgtrekking wordt uitgevoerd, beperkt blijft in plaats van met het gesprek mee te groeien.
Vectorzoekopdrachten en query’s met gecombineerd profiel verbruiken berekeningsresources, waardoor dezelfde resultaatlimiet en filterdiscipline die de aardingskosten bepaalt, ook de belasting van de infrastructuur door aarding vermindert. Stel top-k-limieten in om alleen de resultaten te retourneren die de agent gebruikt, omdat het ophalen van 50 wanneer 5 informeert over het antwoord, 45 ongebruikte resultaten oplevert die budget voor aardingstokens zonder voordeel verbruiken, en gebruik metagegevensfilters om de zoekopdracht te verfijnen vóór de rangschikking van overeenkomsten. Voer een query uit op gecombineerde profielen om volledige context in één bewerking te verzamelen in plaats van afzonderlijke query’s uit te voeren op verschillende objecten voor elke beurt, en cacheprofielen voor agenten met grote gebruikersaffiniteit, zoals een verkoopagent die een vaste set accounts bewerkt, zodat herhaalde contextassemblage de query niet herhaalt.
Agentacties verbruiken SOQL-query’s, DML-bewerkingen en CPU-tijd, waardoor de bulkverwerking, caching en asynchrone discipline van de pijler Resource- en kostenoptimalisatie rechtstreeks van toepassing zijn op agentacties. Ontwerp acties om verzamelingen te accepteren zodat het bijwerken van veel records één bewerking is in plaats van veel, gebruik relatiequery’s om bovenliggende en onderliggende gegevens op te halen in één instructie, verwijsgegevens in het cachegeheugen op te slaan in Platformcachegeheugen en batch-DML over een verzameling in plaats van per record. Verplaats bewerkingen die synchrone limieten overschrijden naar Queueable of Batch Apex, verwerk niet-urgent werk zoals bulkscores of historische verrijking asynchroon en plan door agenten geactiveerde batchtaken waar mogelijk voor daluren zodat de belasting over de tijd wordt gespreid in plaats van zich tijdens kantooruren te concentreren. Bewaak asynchrone uitvoering zodat een wachtrijachterstand een behoefte aan capaciteitsplanning aangeeft voordat deze mislukt.
Verbruikspatronen van agenten evolueren naarmate het gebruik groeit, waardoor duurzaamheid doorlopende bewaking vereist in plaats van een eenmalige doorgifte. Houd de gemiddelde tokens per gevolgtrekking bij via de beschikbare gebruikstelemetrie, zodat een toenemende aanwijzingsgrootte een optimaliseringsopportunity zichtbaar maakt, bewaak de gespreksduurverdeling, zodat onbegrensde gesprekken een probleem met de taakgrens aan het licht brengen, en analyseer de uitvoeringsfrequentie van acties in Event Monitoring, zodat een actie met hoge frequentie een optimaliseringsprioriteit wordt. Bekijk Data 360-querypatronen om veelvoorkomende query’s te vinden die de moeite waard zijn om in het cachegeheugen te plaatsen of vooraf te berekenen, houd het aantal treffers in het semantische cachegeheugen bij zodat een laag percentage drempelwaarden activeert en meet latentiepercentielen zodat eventuele bottlenecks zichtbaar worden. Controleer het agentgebruik regelmatig op afwijking van bereik. Onderzoek bijvoorbeeld een agent wiens gemiddelde gespreksduur in de loop van meerdere maanden is gegroeid van een handvol beurten tot vele. Verfijn de grenzen van de agent zodat het verbruik weer volgens plan verloopt. Sommige van deze bewakingsoppervlakken tonen het gebruik in geaggregeerde dashboards in plaats van als een afzonderlijk logboek per gevolgtrekking. Controleer daarom de exacte telemetrie die beschikbaar is voor uw configuratie wanneer u de bewaking ontwerpt.
Resourceoptimalisering bepaalt of agentarchitecturen worden geschaald naarmate de populatie groeit en gebruikscases zich uitbreiden, terwijl kostenoptimalisering bepaalt of die schaal proportionele bedrijfswaarde oplevert. Deze twee besluiten vormen één mandaat:
- Architectonische efficiëntie: ontwerp acties met bulkverwerking, budget-SOQL over actieketens, verplaats zware verwerking naar asynchrone verwerking, optimaliseer API-verbruik door samengestelde en eventgestuurde patronen, beheer contextvensters door prioritering en overzicht, en stel samen uit herbruikbare componenten.
- Financiële leidraad: selecteer bewust het prijsmodel, modelleer de volledige TCO voordat u zich inlegt, bewaak het verbruik ten opzichte van bedrijfsresultaten en beheer investeringen door middel van gefaseerde goedkeuring en beoordeling van de portefeuille.
Organisaties die deze patronen beheersen, bieden responsieve agentervaringen binnen platformbeperkingen en houden de uitgaven afgestemd op de waarde die agenten retourneren.
De basisrichtlijn voor resource- en kostenoptimalisering voor alle Salesforce-oplossingen, inclusief prestatieoptimalisering, beheerlimieten, TCO-analyse, licentiediscipline en kostenbeheer, bevindt zich in de pijler Resource- en kostenoptimalisering. De programmacomponenten Agent-governance, Human Oversight en Veiligheid zijn verbonden met de pijlers Trust en Fairness. De gedetailleerde richtlijnen voor de implementatie van agenten in dit document, die betrekking hebben op resource-efficiëntie, economie, actieoptimalisering, governance en duurzaamheid, worden verzameld in de bibliotheek met agentische patronen.