Paradigmen for software skifter fra direkte manipulation til målorienteret uddelegering. I forgrunden af denne transformation er AI-agenter – autonome, intelligente enheder, der er i stand til at forstå, begrunde og reagere på vegne af brugere. Dette whitepaper indeholder en teknisk udforskning af de primære typer af AI-agenter: Samtale, Proaktiv, Ambient, Autonomous og Samarbejd. Den definerer hver type, præsenterer specifikke CRM-anvendelsessituationer (Customer Relationship Management) og giver en arkitektonisk plan for opbygning af disse agenter på Salesforce Agentforce Platform, komplet med tekniske eksempler, der anvender forløb, Apex, Data 360, Agent2Agent-kommunikation (A2A) og modelkontekstprotokol (MCP) interoperabilitet.

En AI-agent er et system, der opfatter dets miljø og foretager handlinger for at nå specifikke mål. Selvom konceptet ikke er nyt, har fremkomsten af effektive store sprogmodeller (LLM'er) overbelastet deres funktioner. Vi kan kategorisere agenter baseret på deres primære handlingstilstand og interaktion.

Definition: Samtaleagenter er den mest kendte type agent. De fungerer på en reaktiv, anmodnings-svar-måde, primært gennem naturlige sproggrænseflader (tekst eller stemme). Deres kernefunktion er at forstå brugerens hensigt og give et relevant svar, uanset om det besvarer et spørgsmål, henter oplysninger eller eksekverer en enkel kommando.

Værdi: Samtaleagenter er de digitale indgangsdøre til en organisation. De klarer sig godt ved at håndtere veldefinerede, gentagne opgaver og frigør dermed menneskelige ressourcer. Deres effektivitet måles efter deres evne til at løse brugerhensigter hurtigt og nøjagtigt og til at udføre handlinger på vegne af brugere.

Definition: I modsætning til konverserende agenter, der venter på en meddelelse, fungerer proaktive agenter som vigtige observatører. De udløses af specifikke begivenheder, dataændringer eller foruddefinerede betingelser i et system. Når de udløses, udfører de en opgave eller starter et arbejdsflow uden at kræve direkte brugerinteraktion.

Værdi: Proaktive agenter omdanner et system fra et passivt datalager til en aktiv deltager i forretningsprocesser. De identificerer salgsmuligheder og risici, efterhånden som de vises, og gør det muligt for virksomheder at reagere på vigtige signaler i realtid.

Definition: Ambient agenter er en specifik type proaktive agenter, der arbejder kontinuerligt i baggrunden af en brugers arbejdsflow uden at kræve eksplicitte kommandoer. Brugere drager ofte fordel af deres handlinger uden bevidst at være klar over deres drift, fordi de er designet til at udvide menneskelige funktioner, mens de bevarer en lav profil.

Værdi: Målet med en miljøagent er at reducere den kognitive belastning på brugere ved at automatisere det almindelige "arbejde om arbejde". De gør processer mere effektive ved problemfrit at integrere dem i de værktøjer, som medarbejdere bruger hver dag, og registrerer og strukturerer oplysninger automatisk.

Definition: Autonome agenter repræsenterer et væsentligt spring i kompleksiteten. De får et mål på højt niveau og er i stand til uafhængigt at planlægge og udføre en række trin for at nå dette mål. De kan begrunde, træffe beslutninger og endda lære af deres handlinger for at forbedre ydeevnen over tid.

Værdi: Dette er det tætteste, vi kommer tæt på en ægte digital medarbejder. Autonome agenter kan uddelegeres til en kompleks målgruppe med flere trin, f.eks. "Generer 50 nye kvalificerede emner i manufacturing-sektoren i dette kvartal", og de kan have tillid til at formulere og eksekvere en plan for at nå den.

Definition: Samarbejdsagenter, ofte kaldet "agentudbredelser", er en samling af specialiserede agenter, der samarbejder om at løse et problem, der er for komplekst for enhver enkelt agent at håndtere. En "orkestrator" eller "overordnet" agent nedbryder ofte en stor opgave, uddelegerer underopgaver til de relevante specialiserede agenter og syntetiserer derefter deres output. En robust Agent2Agent-kommunikationsprotokol (A2A) opnår dette.

Værdi: Denne tilgang afspejler et personteam. Ved at nedbryde et komplekst problem kan hver specialiseret agent udnytte sine unikke færdigheder: en er specialiseret i dataanalyse, en anden i kundekommunikation og en tredje i systemintegration, hvilket fører til en mere robust og omfattende løsning.

Efter at have udforsket taksonomien for AI-agenter, forbliver et vigtigt spørgsmål: Hvordan kombinerer vi disse elementer for at løse forretningsproblemer i den virkelige verden effektivt og pålideligt? Dette kapitel besvarer dette spørgsmål ved at levere et lager over almindelige agentdesignmønstre. Hvert mønster er en gennemprøvet løsning på en tilbagevendende udfordring og tilbyder en udarbejdelse af alt fra enkle enkeltformålsagenter til komplekse samarbejdsagentudbredelser.

Samtaleagenter er ofte indgangen til en organisations AI-funktioner. De er defineret af deres mulighed for at engagere sig i en statlig replik med flere drejninger, der fungerer som den primære grænseflade, hvorigennem brugere udfører opgaver og henter oplysninger ved brug af naturligt sprog. Dette afsnit præsenterer to vigtige opskrifter til opbygning af samtaleagenter, der hver er skræddersyet til en bestemt kanal: en til hurtige, interaktive udvekslinger af meddelelsesklienter og en anden til den strukturerede, asynkrone karakter af mail.

En samtaleagent er afledt af dens mulighed for at få adgang til og overveje de rigtige data på det rigtige tidspunkt. Dette mønster er baseret på et sofistikeret dataunderlag, der opretter forbindelse til kunderegistreringer, Knowledge og forretningsanalyser. De komplette genanvendelige opskrifter til disse integrationer findes i kapitel 4: Integrationsmønstre.

Problem

Kunder engagerer sig på tværs af mange digitale kanaler og forventer øjeblikkelige, kontekstbaserede og intelligente svar. Traditionelle chatbots er enten scriptede eller data-blinde, hvilket fører til dårlig personliggørelse, tidlige eskaleringer til mennesker og høje serviceomkostninger.

Kontekst

• Din organisation har digitalt engagement med flere kanaler (WhatsApp, SMS, Slack og Salesforce Experience Cloud).
• Din organisations kunder interagerer med din organisation på flere sprog.
• Din organisation har brug for at udvide service- og salgsarbejdsflows med agenter, der:
  • Hent fra pålidelige kundedata i realtid
  • Respekter guardrails og compliancekrav
  • Eskaler kun til menneskelige agenter, når det er nødvendigt

Nøglekomponenter

• Kanalabstraktion: Service Cloud-forbedret chat (tidligere Meddelelser for app og web) gør det muligt for agenten at kommunikere på tværs af flere kanaler gennem en enkelt oplevelse.
• Agentforce Serviceagent: Agentens adfærd og formål er defineret af følgende komponenter.
  • Emner og instruktioner: Definerer agentens persona og samtaleformål for direkte brugerinteraktion. Dette inkluderer dens kernemission (f.eks. "Du er ekspert i at løse kundesupportproblemer"), instruktioner om at vedligeholde en empatisk og professionel tone og tydelige vagter om omfanget af forespørgsler, den er godkendt til at håndtere.
  • Handlinger: Serviceorienterede handlinger, der er værktøjer, som agenten bruger til at diagnosticere og løse kundeproblemer i realtid. Disse værktøjer er designet til at udføre opgaver som kontrol af en bestillings status, søgning i en Knowledge efter løsninger eller oprettelse af en ny supportsag direkte fra den samtalegrænseflade.
  • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
  • Meddelelsesskabeloner: Genanvendelige skabeloner, der dynamisk udfyldes med live CRM-data via flettefelter eller semantiske data fra Data 360 RAG Retrievers. Disse skabeloner giver agenter mulighed for at generere kontekstbaseret indhold, mens Einstein Trust Layer sikkert maskerer følsomme oplysninger, før instruktionerne sendes til LLM.
• Data 360
  • Data 360-komponenter, herunder DLO'er, DMO'er, vektorlager og RAG retrievers, giver agenten en forenet visning af alle relevante virksomhedsdata, fra strukturerede kunderegistreringer til ustrukturerede Knowledge, hvilket sikrer, at svar er nøjagtige og kontekstbaserede.
• Service Cloud
  • CRM-data: Tilslutter agenten til den komplette sagshistorik, hvilket giver vigtig kontekst på kontodetaljer, kontaktregistreringer og berettigelser
  • Live Agent-kø: Understøttelse af eskalering og distribution til en servicemedarbejder med den fulde samtalekontekst injekteret

Interaktioner

1. Din organisations kunde starter samtale via en kanal.
2. Meddelelsen distribueres til Agentforce, som bestemmer omfanget (emner) og anvender guardrails.
3. AI opretter svar ved brug af meddelelsesskabeloner, mens forløb eller Apex kan udløse backend-logik.
4. Kontekst hentes fra Data 360-objekter, vektorlager og CRM via RAG retriever.
5. AI returnerer et kontekstsvar.
6. Hvis AI ikke kan løse problemet, eskaleres samtalen til Service Cloud Live-agenten.

Trade-Offs

Relaterede mønstre

Greater mønster: Et enkelt og nemt at implementere mønster, der bruger naturligt sprog til at forstå brugerhensigt og derefter distribuerer brugeren til den relevante servicemedarbejder

Operatormønster: Bygger på Greeter for at distribuere anmodninger til den relevante specialist-AI-agent eller den menneskelige servicemedarbejder og forhandle hensigt, hvis det er nødvendigt

Orchestrator mønster: Administrerer en AI-agent-swarm. Den modtager en brugeranmodning, bestemmer hensigten, opretter en plan, overfører de nødvendige data til en eller flere specialagenter og aggregerer derefter svarene for brugeren. I modsætning til operatoren forbliver det første kontaktpunkt.

Problem

Dine kunder bruger hovedsageligt mailbaserede asynkrone samtaler, og dette er stadig den bedste måde at kontakte dem på. Din organisation har brug for at kontakte disse kunder via mail, men dine salgsudviklingsrepræsentanter kan ikke besvare indgående mails i SLA'en, hvilket fører til tab af emner. Endvidere bruger din arbejdsstyrke tid på ukvalificerede emner.

Kontekst

• Din organisation har mail som en primær emneengagementskanal.
• Din SDR har begrænset kapacitet til at kvalificere emner på skala.
• Din salgsproces har pleje af multi-touch-emner, før de mødes med SDR'er eller BDR'er (business development representatives).
• Din organisation har brug for at forøge service og salg med agenter, der:
  • Træk fra aktivering af salg i realtid og salgsprodukt og marketingdata
  • Respekter guardrails og compliance
  • Planlæg møder baseret på emnekvalifikationskriterier

Nøglekomponenter

• Mail kanal: Håndterer registrering af indgående meddelelser, parser deres indhold og vedhæftninger og vedligeholder trådkontinuitet for at aktivere asynkrone samtaler.
• Agentforce SDR Agent: Agentens adfærd og formål er defineret af følgende komponenter.
  • Emner og instruktioner: Definerer agentens mission til at engagere og kvalificere indgående emner gennem samtale. Dette inkluderer instruktioner til at forstå kundeemnets behov, indsamle nøglekvalifikationsdata (f.eks. budget, autoritet og tidslinje) og dirigere samtalen mod et tydeligt næste trin, f.eks. planlægning af et møde med en kontoansvarlig.
  • Handlinger: Specialiserede salgshandlinger, der gør det muligt for agenten at administrere emnelivscyklussen. Disse værktøjer er designet til at udføre SDR-kerneopgaver, f.eks. berigelse af emnedata, afsendelse af skabelonbaserede opfølgningsmails eller integration med kalendersystemer til at reservere opdagelsesopkald.
  • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
  • Meddelelsesskabeloner: Genanvendelige skabeloner, der dynamisk udfyldes med live CRM-data via flettefelter eller semantiske data fra Data 360 RAG Retrievers. Disse skabeloner giver agenter mulighed for at generere kontekstbaseret indhold, mens Einstein Trust Layer sikkert maskerer følsomme oplysninger, før instruktionerne sendes til LLM.
• Data 360
  • Data 360-komponenter, herunder DLO'er, DMO'er, vektorlager og RAG retrievers, giver agenten en forenet visning af alle relevante virksomhedsdata, fra strukturerede kunderegistreringer til ustrukturerede Knowledge, hvilket sikrer, at svar er nøjagtige og kontekstbaserede.
• Sales Cloud
  • CRM-data: Tilslutter agenten til den komplette sagshistorik, hvilket giver vigtig kontekst på kontodetaljer, kontaktregistreringer og berettigelser
  • Planlægge møde mellem kunde og SDR: SDR Live Agent-håndtering kan konfigureres til at opsætte et live-møde ved brug af Opgave og Mødeplanlægning (Næste handlinger).
  • Aktivitetslogføring: Registrer begivenheder, opgaver og mailaktiviteter, og relater dem til emner, konti og salgsmuligheder som et resultat af SDR-agentinteraktioner.

Interaktioner

1. Kunden sender og modtager e-mail via kanalen, som distribuerer til Agentforce.
2. Agentforce anvender emner, handlinger og guardrails til at parse hensigter.
3. Agentforce udarbejder kontekstbaserede svar ved brug af meddelelsesskabeloner beriget med CRM og Data 360-kontekst.
4. En mailsamtale med flere vagter fortsætter, indtil løsningen eller politikretningslinjerne.
5. For kvalificerede emner planlægger Agentforce et møde og opdaterer CRM.
6. Hvis hensigten overskrider AI-omfanget, eskalerer Agentforce til Sales Cloud SDR for et svar fra en servicemedarbejder.

Trade-Offs

Relaterede mønstre

Svarbotmønster: Et effektivt mønster for selvbetjening, der bruger generativ AI til at forstå naturligt sprog til Knowledge hentning, og ikke kun søgeord

Mens de konverserende agenter i det foregående afsnit klarer sig godt ved at reagere på brugerkommandoer, repræsenterer proaktive agenter et paradigmeskift: de reagerer uden at blive bedt om det. Dette afsnit indeholder de arkitektoniske mønstre for at opbygge agenter, der automatisk overvåger data og begivenheder, der stammer både uden for og i Salesforce.

Problem

Din organisation genererer vigtige forretningsbegivenheder i og uden for Salesforce. Det er vanskeligt at oversætte dem til rettidige konteksthandlinger, da de er spredt på tværs af applikationer og afdelinger.

Kontekst

• Dine forretningsprocesser strækker sig over flere systemer for CRM, betalingsbehandling, forsendelse, marketingautomatisering, telemetri og CDP.
• Dine organisationsbegivenheder forekommer 24/7, men din tilgængelighed af arbejdsstyrke er begrænset uden for arbejdstiden. Systemer er altid aktiveret, men mennesker er ikke.
• Begivenhederne mangler kontekstvidenskab – de mangler kundekontekst, der er tilgængelig i Salesforce, hvilket tvinger sammenføjning af oplysninger i flere trin. I dag findes implementering enten som særskilt kompleks automatisering eller udføres manuelt.
• Mennesker fungerer som en kompilator til at indsamle data (i forskellige formater) og reagere intelligent på opdelte begivenheder.
• Dine målhandlinger anvendes på flere systemer.

Nøglekomponenter

• Begivenhedskilde
  • Datahandling udløste begivenheder, efter eksterne data er blevet overført til Data 360
  • Tredjeparts- eller Salesforce Heroku MCP-servere, der kan sende begivenheder til Salesforce via Salesforce Pub/Sub API
  • Ekstern applikation, der kan sende begivenhedsadviseringer via Salesforce Pub/Sub API
• Valgfrit mellemvare: MuleSoft eller Data 360 til transformationer
• Agentforce Agent: Agentens adfærd og formål er defineret af følgende komponenter.
  • Emner og instruktioner: Angiver agentens kernemission og dens udløsere, herunder definition af dens primære målsætning (f.eks. "Overvåg alle sager med høj prioritet og forhindr SLA-overtrædelser"). Indeholder de specifikke begivenheder eller databetingelser, som agenten skal lytte til for at starte sine opgaver
  • Handlinger: Begivenhedsudløste og planlagte handlinger, der er designet til at reagere på eksterne begivenheder. Mens disse handlinger kører autonomt for rutinemæssige opgaver, inkluderer de ofte muligheden for at orkestrere arbejdsflows, der involverer menneskelig intervention, eskalering til brugere til gennemgang, godkendelse eller håndtering af scenarier, der kræver menneskelig vurdering.
  • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
  • Meddelelsesskabeloner: Genanvendelige skabeloner, der dynamisk udfyldes med live CRM-data via flettefelter eller semantiske data fra Data 360 RAG Retrievers. Disse skabeloner giver agenter mulighed for at generere kontekstbaseret indhold, mens Einstein Trust Layer sikkert maskerer følsomme oplysninger, før instruktionerne sendes til LLM.
• Data 360
  • Data 360-komponenter, herunder DLO'er og DMO'er, der lagrer begivenhedsdata, der genereres af eksterne systemer og sendes til salesforce, og som transformerer og opbygger streaming- eller realtidsindsigter
  • Beregnede, streaming- og realtidsindsigter giver agenter øjeblikkelige, relevante data om kunder. Dette aktiverer forebyggende problemløsning og reducerer eskalering. Datadiagrammer viser proaktivt relationer og indsigter fra uensartede datakilder, hvilket muliggør tidlig registrering af mønstre eller afvigelser, der er relevante for kundeengagement, aktivitet og profil.
  • Data 360-vektorlager og RAG retrievers giver agenten en samlet visning af alle relevante virksomhedsdata og ustrukturerede Knowledge-artikler, der sikrer, at svarene er nøjagtige og kontekstbaserede.
• Eventmål
  • Adviser medarbejdere proaktivt eller kontakt kunder
  • Kan udvides til agenter (se Ambient Agent og Autonomous Agent mønstre)

Interaktioner

1. Der sker en bemærkelsesværdig ændring i det eksterne system.
2. Det eksterne system udsender en begivenhed og udgiver den til Salesforce-begivenhedsbussen via API (opretter en platformsbegivenhed) eller Pub/Sub API, eller begivenhedsdata streames til Data 360.
3. Abonnenter af begivenheden udløses. Et forløb udløses.
4. Forløbet kalder agenthandling med begivenhedsdataene. Agenten bestemmer den rigtige handlingsforløb og udfører den.
5. Resultatet er en advisering eller et arbejdsflow, der udløses. Adviseringer leveres til en bruger i et samarbejdsværktøj (f.eks. Slack). Opgaver eller begivenheder genereres også. Endvidere kan handlinger kalde eksterne systemer. Begivenhederne går derfor ikke tabt, men udføres proaktivt, signaleres og handles på, hvilket fjerner overhead eller kompleks automatisering for at finde dem.

Trade-Offs

Relaterede mønstre

Dommer & Jury mønster: Kan bruges sammen med dette mønster til at sikre nøjagtigheden og pålideligheden af AI-drevne beslutninger ved at bruge flere "juror"-agenter og en "judge"-agent til kongruencevurdering

Model af modeller mønster: Dette mønster omfatter forskellige synspunkter fra flere ekspertagenter for at generere mere avancerede indsigter, som kan supplere den proaktive AI's intelligente svar.

Problem

Din organisations Salesforce-økosystem genererer en konstant stream af signaler, men har problemer med at oversætte dem til rettidig kontekstmæssig handling, da de kræver forretningslogik, styring og mennesker til at sortere og reagere. Mange gange går signalerne tabt uden nogen handling, der fører til tabt salgsmulighed.

Kontekst

• Din organisation bruger en eller flere Salesforce-clouds: Salg, Service, Marketing, Commerce, Sundhed, Produktion og andre.
• Du har brug for intelligent sortering udover simpel distribution eller regelbaseret sortering. Din organisation vedligeholder hundredvis af komplekse forretningsregler.
• Du skal have et svar i realtid eller næsten i realtid på begivenheder.
• Nogle gange bliver dine mest berettigede administratorer det svageste link i kæden for ikke at se signalerne.

Nøglekomponenter

• Begivenhedskildelag
  • CRM-data, platformsbegivenheder, CDC-data (Change Dataregistrering) og RTEM-data (Real-Time Event Monitoring) fra platformsaktivitet på lavt niveau
• Data 360
  • Data 360-komponenter, herunder DLO'er og DMO'er, der lagrer begivenhedsdata, der genereres af CRM- eller platformsbegivenheder, og som transformerer og opbygger streaming- eller realtidsindsigter
  • Beregnede, streaming- og realtidsindsigter giver agenter øjeblikkelige, relevante data om ændringer af kunden, medarbejderaktivitet eller metadata i systemet. Dette aktiverer forebyggende problemløsning og reducerer eskalering. Denne realtidssituationsbevidsthed sætter agenter i stand til at levere rettidige interventioner for styring og overholdelse af driftsmæssig gennemsnit.
  • Datadiagrammer viser proaktivt relationer og indsigter fra uensartede datakilder, hvilket muliggør tidlig registrering af mønstre eller afvigelser, der er relevante for kundeengagement, aktivitet og profil.
  • Data 360-vektorlager og RAG retrievers giver agenten en samlet visning af alle relevante virksomhedsdata og ustrukturerede Knowledge-artikler, der sikrer, at svarene er nøjagtige og kontekstbaserede.
• Agentforce Agent: Agentens adfærd og formål er defineret af følgende komponenter.
  • Emner og instruktioner: Angiver agentens mission til at håndhæve forretningsregler og automatisere processer baseret på dataændringer i Salesforce. Den definerer agentens målsætning (f.eks. "Sørg for, at alle salgsmuligheder opdateres med en primær kontakt, før du når fasen for forhandling") og de specifikke registreringsoprettelser, feltopdateringer osv. som udløser agenten.
  • Handlinger: Begivenhedsudløste og planlagte handlinger, der er designet til at reagere på interne Salesforce-begivenheder. Mens disse handlinger kører autonomt for rutinemæssige opgaver, inkluderer de ofte muligheden for at orkestrere arbejdsflows, der involverer menneskelig intervention, eskalering til brugere til gennemgang, godkendelse eller håndtering af scenarier, der kræver menneskelig vurdering.
  • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
  • Meddelelsesskabeloner: Genanvendelige skabeloner, der dynamisk udfyldes med live CRM-data via flettefelter eller semantiske data fra Data 360 RAG Retrievers. Disse skabeloner giver agenter mulighed for at generere kontekstbaseret indhold, mens Einstein Trust Layer sikkert maskerer følsomme oplysninger, før instruktionerne sendes til LLM.
• Eventmål
  • Adviser medarbejdere proaktivt eller kontakt kunder.
  • Kan udvides til at kalde andre agenter (se miljø-AI og autonom AI-mønstre)

Interaktioner

1. Der forekommer en bemærkelsesværdig ændring i det interne system, f.eks. en opdatering af en CRM-registrering, en metadataændring eller en datahandling, der er udløst fra Data 360.
2. Det interne system udsender en begivenhed og udgiver den til Salesforce-begivenhedsbussen via API (opretter en platformsbegivenhed) eller Pub/Sub API, eller begivenhedsdata streames til Data 360.
3. Abonnenter af begivenheden udløses og aktiverer et forløb eller Apex.
4. Det aktiverede forløb eller Apex kalder Agenthandling.
5. Resultatet er en advisering eller et arbejdsflow, der udløses. Adviseringer leveres til en bruger i et samarbejdsværktøj (f.eks. Slack). Opgaver eller begivenheder genereres også. Endvidere kan handlinger kalde eksterne systemer.
6. Begivenhederne går derfor ikke tabt, men udføres proaktivt, signaleres og handles på, hvilket fjerner overhead eller kompleks automatisering for at finde dem.

Trade-Offs

Relaterede mønstre

Listener/Feed-mønster: Kan kombineres med lyttermønsteret for at udløse proaktive handlinger baseret på interne Salesforce-begivenheder

Dataforvaltermønster: Proaktiv AI kan bruge dataforvaltere til at sikre datakvalitet og ensartethed, når de reagerer på interne begivenheder

Zen Data Gardener mønster: For planlagt, proaktiv dataklargøring og standardisering udløst af interne begivenheder eller med regelmæssige intervaller

Vi startede med agenter, der svarede interaktivt i en samtalekanal og fortsatte derefter til agenter, der reagerede på specifikke begivenheder. Flytter ud over den begivenhedsstyrede model for proaktive agenter, repræsenterer miljøagenter et paradigmeskift fra direkte interaktion til proaktiv baggrundshjælp. Disse er headless-agenter, der observerer det digitale miljø i baggrunden. De fungerer som "øjne og ører" for systemet, opfatter kontekst fra brugeraktivitet eller datastreams og koordinerer derefter med andre agenter eller mennesker for at fuldføre opgaver, vise indsigter eller give vejledning.

Problem

Din organisations forretningsaktiviteter genererer kontinuerlige streams af værdifulde oplysninger (opkald, møder, chats, sensordata med mere), men disse data forsvinder i realtid uden registrering eller analyse. Når mennesker manuelt dokumenterer disse interaktioner, går kritiske indsigter tabt, og tidspunktet for rettidig intervention er forbi. Organisationer mangler størstedelen af den intelligens, der kan handles på, som er nødvendig i realtid og begravet i forbigående strømninger, hvilket fører til huller, tabte coachingmuligheder og beslutninger, der træffes uden fuldstændig kontekst.

Kontekst

• Dine forretningsaktiviteter genererer kontinuerlige streams fra forskellige kilder, herunder voice- og video-møder, live chats, sensortelemetrie, skærmaktivitet og transaktionsdata.
• Du skal have indsigter i realtid eller næsten i realtid (inden for sekunder eller minutter og ikke timer eller dage) for effektivt at reagere på og reagere på disse streams.
• Manuel dokumentationsprocesser mislykkes, hvilket er kendetegnet ved lave overholdelses- og opdateringsfrekvenser, høj kognitiv byrde på medarbejdere og ufuldstændig registrering af vigtige oplysninger.
• Du skal bruge multimodal forståelse, der kombinerer data fra lyd, video, skærmdeling, chat og andre metadata for at oprette en komplet og nøjagtig kontekst af interaktioner og begivenheder.
• Du kræver både øjeblikkelige analyser for coaching og advarsler i realtid og historiske analyser for efterinteraktionssammendrag og identificering af langsigtede tendenser.
• Tidlig kontekst (episodehukommelse) er afgørende for din analyse, herunder forståelse af sekvensen, timing, overgange og mønstre på tværs af forskellige tidsvinduer i dine datastreams.

Nøglekomponenter

• Streamkilde
  • Voice og video: Video-konferenceværktøjer (f.eks. Slack Huddle, Zoom, Google Meet og Microsoft Teams) og telefonsystemer
  • Samarbejdsværktøjer: Slack, teams og andre
• Stream-registreringsforbindelser
  • Oprindelig SDK: Leverandørangivet SDK, der hjælper med at hente afskrifter eller meddelelser, der understøtter streamsegmenter eller afskrifter i realtid
• (Valgfrit) Stream behandling lag
  • For lydstreams, hvis afskrifter ikke er tilgængelige i realtid, en tal-til-tekst-funktion, der oversætter lyd til tekst. Du kan også bruge en administreret udbyder som Amazon Transcribe.
  • For andre datastreams kan du vælge et streambehandlingssystem som Data 360 eller Apache Flink
• Data 360
  • Data 360-komponenter, herunder DLO'er og DMO'er, der lagrer begivenhedsdata, transformerer og opbygger streaming- eller realtidsindsigter
  • Beregnede, streaming- og realtidsindsigter giver agenter øjeblikkelige, relevante data om kunder, deres aktivitet og kritiske indsigter. Dette aktiverer forebyggende problemløsning og reducerer eskalering. Denne situationsbevidsthed i realtid sætter agenter i stand til at levere rettidige interventioner og personlig support til medarbejdere og dermed optimere kundetilfredshed og driftsmæssig gennemsnit.
  • Data 360-komponenter, herunder DLO'er og DMO'er, der lagrer kundedata, transformerer og opbygger indsigter i realtid
  • Data 360-vektorlager og RAG retrievers giver agenten en samlet visning af alle relevante virksomhedsdata og ustrukturerede Knowledge-artikler, der sikrer, at svarene er nøjagtige og kontekstbaserede.
• Agenter fra Agentforce. Dette mønster fokuserer på en miljøagent, der observerer en kontinuerlig datastream, f.eks. en live-opkaldsafskrift eller et videofeed. Den fungerer som en lytter i realtid og fortolker ustrukturerede data, når de sker. En agent, der lytter til et liveopkald, kan f.eks. kalde en Data Discovery-agent for at berige et emnes registrering baseret på ny kontekst, der deles i samtalen. Her er et eksempel på en sådan headless-agent:
  • Feedback agent. Agentens adfærd og formål er defineret af følgende komponenter.
    • Emner og instruktioner: Definerer agentens primære mission til at analysere samtalestrømme og udtrække struktureret feedback og ydeevnemetrikker. Dette inkluderer instruktioner til at overvåge kundesentiment, identificere omtaler af nøgleprodukter eller konkurrenter og vurdere, om den menneskelige agent overholder bedste fremgangsmåder for firmaet eller en salgsoversigt.
    • Handlinger: Handlinger til at omdanne ustrukturerede samtaledata til forretningsdata, der kan handles på. Disse handlinger gør det muligt for agenten at oprette en "feedbackoversigt"-registrering, logføre produktegenskabsanmodninger, markere opkald med negativ sentiment for managergennemgang og opdatere et dashboard for at spore den generelle agentydeevne op mod nøglemetrikker.
    • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
    • Meddelelsesskabeloner: Strukturerede, skabelonbaserede LLM-instruktioner, der kan modtage input og levere et LLM-genereret output
• Miljømål
  • Adviser brugere på det sted, hvor agenten og brugeren er, f.eks. i et videoopkald eller en desktopapplikation

Interaktioner

1. Når en stream er aktiveret (f.eks. når en bruger tilslutter sig videoopkaldet), vedhæfter agenten sig selv som en observatør.
2. Agenten begynder at modtage streamdata, registrerer trinvist hensigter, træffer beslutninger og kalder handlinger.
3. Agenten kontekstualiserer baseret på hensigt og henter yderligere data (struktureret eller ustruktureret).
4. Agenten leverer svar direkte i realtid uden brugermeddelelser: den kan registrere en indsigelse i et salgsopkald og levere vigtige oplysninger til at håndtere indsigelsen.
5. Agenter kan kompilere et konsolideret sammendrag og handlinger og dele dem med andre agenter og brugere.

Trade-Offs

Relaterede mønstre

Listener/Feed-mønster: Kan kombineres med lyttermønsteret til at behandle streams i realtid af samtaledata og brugerinteraktionsdata og vise relevant kontekst og indsigter

Forespørgselsmønster: Kan bruges sammen med dette mønster til at samle kontekst fra flere kilder i streamen og besvare spørgsmål

Problem

Dine medarbejdere udfører hundredvis af forretningskritiske aktiviteter dagligt på tværs af mail, kalender, opkald og applikationer, men disse aktiviteter forbliver usynlige for organisationssystemer, før de er registreret manuelt – hvilket sjældent sker. Denne aktivitetsblænding betyder, at CRM-data er ufuldstændige, AI-modeller mangler de signaler, der er nødvendige for intelligente anbefalinger, og managers har ingen synlighed i realtid i kundeengagement. Manuel aktivitetsregistrering opretter en produktivitetsskatt, mens du stadig mangler det meste af det faktiske arbejde.

Kontekst

Ligesom streamobservatøren er dette en data- og indholdsobservatør, der leverer opgaver, der kan handles på, eller som udfører handlinger på vegne af brugeren.

Nøglekomponenter

• Datalag
  • CRM-data: Kundedata, der er tilgængelige i CRM, der giver kontekst til agenten (f.eks. når brugeren er på en salgsmulighedsside, kan agenten hente oplysninger om salgsmuligheden og den tilknyttede konto fra CRM).
  • Data 360-komponenter, herunder DLO'er og DMO'er, der lagrer relevante kundedata, der overføres fra forskellige kilder
  • Beregnede, streaming- og realtidsindsigter giver agenter øjeblikkelige, relevante data om kunder, deres aktivitet og kritiske indsigter. Dette aktiverer forebyggende problemløsning og reducerer eskalering.
  • Data 360-vektorlager og RAG retrievers giver agenten en samlet visning af alle relevante virksomhedsdata og ustruktureret Knowledge.
• Agentforce Agent: Dette mønster fokuserer på en miljøagent, der observerer en brugers handlinger direkte i brugergrænsefladen. Den fungerer som en assistent i realtid og forstår konteksten af brugerens arbejdsflow for at give vejledning. En agent kan f.eks. overvåge en servicerepræsentant, der udfylder en sagsregistrering og proaktivt vise en relevant Knowledge Her er et eksempel på en sådan headless-agent:
  • Feedback agent. Agentens adfærd og formål er defineret af følgende komponenter.
    • Emner og instruktioner: Definerer agentens mission til at overvåge en brugers handlinger i brugergrænsefladen og give kontekstbaseret hjælp. Dette inkluderer dens målsætning (f.eks. "Guide en servicemedarbejder gennem sagsløsningsprocessen") og de specifikke brugergrænsefladebegivenheder eller dataindtastningsmønstre, den skal overvåge for proaktivt at tilbyde hjælp.
    • Handlinger: Handlinger, der er bygget ved brug af Apex eller Forløb, til at vise relevante oplysninger og næste bedste handlinger direkte i brugerens arbejdsflow. Disse handlinger gør det muligt for agenten at hente og vise en relevant Knowledge, foreslå et gyldigt næste trin i en proces eller markere et dataindtastningsfelt, der kan overtræde en forretningsregel, alt sammen som reaktion på brugerens aktivitet i realtid.
    • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
    • Meddelelsesskabeloner: Genanvendelige skabeloner, der dynamisk udfyldes med live CRM-data via flettefelter eller semantiske data fra Data 360 RAG Retrievers. Disse skabeloner giver agenter mulighed for at generere kontekstbaseret indhold, mens Einstein Trust Layer sikkert maskerer følsomme oplysninger, før instruktionerne sendes til LLM.
• Miljømål
  • Adviser brugere på det sted, hvor agenten og brugeren er, f.eks. på en webside eller en administratorside

Interaktioner

1. Når en bruger besøger en side eller app, vedhæfter agenten sig selv som en observatør.
2. Agenten begynder at undersøge data og handlinger, trinvist registrerer hensigter, træffer beslutninger og kalder handlinger.
3. Agenten kontekstualiserer baseret på hensigt og henter yderligere data (struktureret eller ustruktureret).
4. Agenten leverer svar direkte i realtid uden brugermeddelelser og kan foreslå de næste bedste handlinger eller tilbud om at udføre dem på vegne af brugeren.
5. Agenter kan nemt dele dette med andre agenter og brugere.

Trade-Offs

Relaterede mønstre

Listener/Feed-mønster: Kan kombineres med lyttermønsteret for at udløse proaktive handlinger baseret på observeret aktivitet

Dataforvaltermønster: Aktivitetsregistrerings-AI kan bruge dataforvaltere til at sikre datakvalitet og ensartethed ved registrering af registrerede aktiviteter.

Generatormønster: Kan bruges til automatisk at generere aktivitetssammendrag eller opfølgningsopgaver baseret på registrerede aktiviteter

Dette afsnit viser mønstre for samarbejdsagenter, hvor en eller flere agenter samarbejder med en bruger for at nå et fælles mål. Disse opskrifter fokuserer på at oprette et problemfrit partnerskab: agenter håndterer kompleks datasamling og opgaveudførelse, mens de holder den menneskelige person opdateret for beslutninger, godkendelser og strategisk vejledning.

I denne model håndterer agenter de automatiserbare dele af et arbejdsflow. Processen bliver en dynamisk feedbackløbe.

• En person kan starte en opgave gennem en samtaleagent, hvilket udløser en proaktiv agent til at administrere backendtrinene.
• Samtidig kan en miljøagent observere deres handlinger for at give vejledning i realtid.

Denne proces skaber en problemfri fusion af menneskelig og digitalt arbejde. Dette mønster viser, hvordan Agentforce gør det muligt for et system med flere agenter at håndtere komplekse opgaver, som ingen enkelt agent – eller menneske – kan klare alene.

Problem

Dine forretningsprocesser kræver samarbejde mellem medarbejdere fra forskellige organisationer – både interne og eksterne – hver med forskellige job, der skal udføres, der involverer forskellige færdigheder og prioriteter. Procesflaskehalse kan forekomme når som helst og hvor som helst på grund af ressourcekapacitet, færdighedsbegrænsninger eller på grund af mængden af udvekslede oplysninger.

Kontekst

• Processer strækker sig over teams og kræver, at flere teammedlemmer samarbejder om et vellykket resultat.
• Agentassistenter hjælper allerede din arbejdsstyrke i et-til-et-scenarier som konverserende, proaktive og miljøagenter.
• Processer bruger agenter i relevante segmenter af dine forretningsprocesser. Men processer kræver også samarbejde mellem mennesker og agenter. Dette samarbejde kan involvere menneske-til-menneske med hjælp fra agenter eller menneske-agent-menneskesamarbejde.
• Færdighedsmangel udfyldes af agenter.
• Agenter hjælper med at forbedre samarbejdet ved at reducere den menneskelige indsats i opgaver som opfølgninger og udveksling af vigtige oplysninger for at hjælpe med beslutningstagning.
• Agenter kan også samarbejde og uddelegere baseret på politikker og retningslinjer.

Nøglekomponenter

• Samarbejdsområde
  Agentmæssigt samarbejde kræver et fælles område, hvor alle deltagere, både mennesker og agenter, kan interagere. Disse samarbejdsfelter er ikke længere statiske miljøer, der kun bruger mennesker. I stedet er de kanaler, hvor agenter kan inviteres til at deltage, bidrage og endda starte samtaler, hvilket fundamentalt ændrer karakteren af teamarbejde. En agent kan f.eks. oprette og starte en sagsudbredelse i Slack ved at invitere eksperter og andre agenter til at samarbejde om sagen.

• Agentforce Agents
  Dette mønster flytter sig ud over individuelle agentmønstre for at demonstrere, hvordan de konvergerer i en Samarbejdsagentmodel og orkestrerer komplekse processer, der intelligent forøger menneskelige funktioner. De foregående mønstre – Konverserende (2.1), Proaktiv (2.2) og Omgivende (2.3) – definerer Agentforce Agent components.c-retningen. En samtaleagent fungerer som den primære grænseflade, der arbejder sammen med mennesket og fungerer som grænseflade mellem mennesker og alle agenter, der er involveret i samarbejdet. Når en opgave er for multifacet, starter den konverserende agent en samarbejdssession og samler de menneskelige brugere og de nødvendige headless-agenter for at arbejde på problemet samtidigt. Processen bliver en dynamisk feedback løkke, hvor et menneske kan starte en opgave, som derefter udløser en proaktiv agent til at administrere backend trin, mens en ambient agent kan observere for at give vejledning i realtid, hvilket skaber en problemfri fusion af menneskelig og digital arbejde.

• Datalag
  I samarbejdsagentmodellen tjener datalaget en mere dynamisk rolle end blot at levere oplysninger. Det bliver den vedvarende hukommelse og det delte arbejdsområde for hele teamet mellem mennesker og agenter. Mens hver agent, der er involveret, har sine egne specifikke databehov som defineret i deres respektive mønster, afhænger deres samarbejde om en kompleks opgave af et delt dataunderlag, der sporer tilstanden af det generelle job.

  Denne delte tilstand er vigtig. Når en opgave videregives fra en samtaleagent til en proaktiv agent og derefter til en person til godkendelse, skal datalaget spore status, kontekst og foretagede beslutninger ved hvert trin. Dette sikrer, at hver deltager har en ensartet og opdateret visning af episoden.

Interaktioner

1. Mennesker starter en samarbejdssession med andre mennesker og agenter.
2. Kontekst, mål, job og resultater er defineret.
3. Agenten beriger konteksten ved at hente yderligere oplysninger og proaktivt planlægger de trin, der kræves for at fuldføre jobbet, sammen med ejere, der er mennesker eller agenter.
4. Forløbet observeres, konteksten opdateres, og handlinger udføres.
5. Hvor agenter udfører jobbet, leverer agenten detaljerede oplysninger til at hjælpe menneskelige interessenter med at forstå argumentation, give feedback og tillade optagelser.
6. Agenter fuldfører arbejdet med fuld gennemsigtighed og overensstemmelse.

Trade-Offs

Relaterede mønstre

Operatormønster: Samarbejdsagenter fungerer ofte som operatorer, distribuerer anmodninger til de relevante specialiserede AI-agenter eller servicemedarbejdere og forhandlerhensigt.

Orchestrator mønster: I scenarier, der involverer samarbejde, administrerer en orkestreringsagent en udbredelse af AI-agenter og aggregerer deres svar for at opnå en problemfri brugeroplevelse.

Arbejdsområde (Radar O'Reilly) mønster: Samarbejdsagenter bruger dette mønster til at administrere et responsivt enkeltrude-brillebrugergrænseflade og opdatere relevant indhold i realtid i et samtaleforløb.

I modsætning til samarbejdsmønstre, der hjælper en bruger, er autonome agenter designet til fuld uddelegering. Dette afsnit indeholder de arkitektoniske planer for agenter, der uafhængigt kan planlægge og udføre komplekse, flertrinsopgaver for at nå et mål på højt niveau uden at kræve menneskelig intervention. Fokus her er på at skabe et system, du kan opgave med et mål og Trust til at udføre det fra start til slut.

Problem

Din organisation realiserer værdi gennem et meget komplekst sæt af processer, der hver har særskilte politikstyrede job, pluklister og specifikke færdigheder, der er nødvendige for kørsel. Dette er ofte programmer, der kræver væsentlig investering af tid og ressourcer.

Opsætning af et nyt program har meget overhead og kan tage måneder at realisere værdien. Implementering af feedback og forbedringer kræver ofte ekstra tid og indsats. Kompleksitet er primært drevet af din organisations struktur, hvor distribuerede applikationer og processer kan forårsage afhængigheder, der kræver, at mennesker administrerer programmet.

Kontekst

• Agenter kan fungere uafhængigt fra start til slut. Agenter er designet og konfigureret, så mål, plan og strategi er foruddefineret.
• Agenter kan træffe alle beslutninger uden at søge menneskelig godkendelse. Agenter leveres med politik- og overensstemmelsesretningslinjer.
• Agenter kan få adgang til den nødvendige kontekst og de data, de har brug for, og de kan udføre de nødvendige handlinger uden at skulle bruge mennesker.
• Mennesker adviseres, men er ikke "i gang".

Nøglekomponenter

• Definitionslag for mål og strategi
  • Procespluklister: Detaljerede beskrivelser af autonom kørsel med deterministiske regler, som agenter skal følge
  • Autonome beslutningskriterier: Regler, der gør det muligt for agenter at træffe beslutninger uden at kræve menneskelig godkendelse
  • Fallback regler: Foruddefinerede handlinger til håndtering af standard- eller undtagelsesscenarier, når en agents primære proces mislykkes
  • Skærme: Tydelige grænser, der skitserer, hvad agenter kan og kan ikke gøre, herunder hvordan situationer uden for omfang skal håndteres
  • Succeskriterier og definition af udført: De metrikker og betingelser, der bestemmer, hvornår en agents opgave fuldføres korrekt
• Agentforce Agents
  • Agentorkestrator eller koreograf: Den grundlæggende agent, der ejer målet, årsagerne og planlægningen af kørsel
    • Emner og instruktioner: Når et mål er defineret, tager orkestrator- eller koreografagenten ledelsen i at opdele denne overordnede målsætning i mindre, administrerbare job eller underopgaver. Den designer en omfattende plan, der skitserer sekvensen af job og identificerer de specifikke agenter eller værktøjer, der er påkrævet for hvert trin. Endelig sikrer orkestreringsagenten problemfri kørsel af planen, overvågning af status, administration af afhængigheder og foretagelse af justeringer efter behov for at nå målet effektivt og effektivt. I tilfælde af en koreografagent overfører den konteksten og tilstanden til downstream-agenterne for at gennemføre jobbet til fuldførelse.
    • Handlinger: Handlinger kalder værktøjer til at udføre en funktion, hente data eller uddelegere til andre headless-agenter, hvilket aktiverer en bredere række af funktioner og mere komplekse arbejdsflows.
    • Guardrails: Guardrails fungerer som et sæt konfigurerbare regler og kørselskontroller, der begrænser agentens adfærd. Handler som et sikkerhedslag, der kan opfange meddelelser, validere agentens foreslåede handlinger og filtrere dets endelige svar for at forhindre skadeligt indhold, håndhæve forretningsregler og sikre, at agenten fungerer inden for dets udpegede omfang.
• Datalag
  • CRM Data: Kundedata, der er tilgængelige i CRM, der giver kontekst til en eller flere agenter
  • Data 360-komponenter, herunder DLO'er og DMO'er, der lagrer relevante kundedata, der overføres fra forskellige kilder
  • Beregnede, streaming- og realtidsindsigter giver agenter øjeblikkelige, relevante data om kunder, deres aktivitet og kritiske indsigter. Dette aktiverer forebyggende problemløsning (f.eks. håndtering af mailafvisninger), der reducerer eskalering.
  • Data 360-vektorlager og RAG retrievers giver agenten en samlet visning af alle relevante virksomhedsdata og ustruktureret Knowledge
  • Slack-kanalmeddelelse eller samtaledata, f.eks. sagshistorik og samtaleagenthistorik, der giver samtalekontekst
• Overvågning og tilsyn
  • Agentmålstatusovervågning: Sporer statussen for autonome agentsessioner for at måle resultater og sikre justering med målsætninger
  • Overvågning af agenters drift: Sporer statussen for autonome agenter i realtid til intervention og fejlfinding, så du sikrer problemfri drift
  • Overvågning af agentstyring: Sporer sporings- og revisionslogfiler for at sikre, at autonome agenter overholder foruddefinerede mål, mål og etiske retningslinjer

Interaktioner

1. Jobbet er defineret med tydelige resultater.
2. Jobbet startes via en af følgende metoder:
   • En agent får en opgave.
   • En agent vælger proaktivt jobbet baseret på kvalifikationer.
   • En agent udfører jobbet i baggrunden.
3. Agenten etablerer tydeligt forventninger og informerer mennesker og detaljerer mål, plan og strategi. Planen viser trinvise processer, anvendte agenter, anvendte data, omfang, agentevalueringsplan og kontrolpunkter for mennesker til at overvåge status, drift og styring.
4. Agenten begynder kørsel. Ved hver milepæl opdaterer den tilstanden og statussen. Mennesker har mulighed for at give feedback eller fange agenter efter behov.
5. Agenten udfører jobbet. Resultatet og resultaterne er tilgængelige i overvågningsdashboardet.

Trade-Offs

Relaterede mønstre

Project Manager-mønster: Autonome agenter integrerer ofte dette mønster og overvåger langvarige, flertrinsprocesser fra initiering til fuldførelse med minimal menneskelig intervention.

Konfigurationsmønster: Autonome agenter kan bruge dette mønster til automatisk at generere og validere konfigurationer baseret på naturlige sprogkrav eller foruddefinerede politikker og sikre overensstemmelse og nøjagtighed uden manuel oversigt.

Zen Data Gardener mønster: Dette mønster kan bruges af autonome agenter til planlagt, baggrundsdataforbedring og standardisering, hvilket sikrer datakvalitet og ensartethed over tid for at understøtte nøjagtig agentbeslutningstagning.

Nu vil vi bringe agentets taksonomi og agentmønstre til live ved at udforske, hvordan de implementeres på Salesforce Platform. For dem, der ikke er bekendt med Agentforces kernekomponenter, indeholder tillægget en nyttig opdatering af de nøgleteknologier, der henvises til i dette og det næste kapitel.

Dette afsnit tager taxonomien af agenter og illustrerer hver med en almindelig anvendelsessituation for at vise, hvordan de bruges i applikationer i den virkelige verden.

En kunde, Jane, besøger et firmas website for at kontrollere statussen på hendes seneste bestilling.

• Interaktion: Jane åbner chatvinduet (Agentforce Chat-klienten).
• Agenthandling: Den samtaleagenter hilser hende velkommen og spørger, hvordan det kan hjælpe. Jane spørger "Hvor er min seneste bestilling?"
• Proces:
  1. Agenten, der er baseret på Jane's kundeoplysninger fra Salesforce, identificerer hendes seneste bestilling.
  2. Den forespørger på forsendelsessystemet (via en MuleSoft-forbindelse) for de seneste sporingsoplysninger og giver Jane en opdatering i realtid og et sporingslink.
  3. Den slår derefter politikken op og opgraderer automatisk til hurtig forsendelse.
  4. Når Jane stiller et komplekst spørgsmål, som agenten ikke kan håndtere, eskalerer det problemfrit samtalen til en human serviceagent og giver den fulde afskrift for konteksten.

Opskrift

Anvendte mønstre: Konverserende AI-mønster, Integrering af transaktionsdata til agenter

Designtid

1. Opsæt en samtaleagent.

   Opsæt Forbedret chat	→	Opret Serviceagent	→	Definer supportbestillingsemne	→	Opret Hent bestilling-handling
   						↓
   Tilføj udgående eskalerings Omni-Channel-forløb	←	Opret Eskaler emne	←	Føj handlinger til emner	←	Opret Hent status-handling
   ↓
   Udgiv agenten

2. Opsæt Forbedret chat som Jane's chatindgangspunkt, så hun kan åbne Agentforce-vinduet på websiden.
3. Aktiver Agentforce og opret en serviceagent i Agentforce-konstruktør til at håndtere samtaler og udløse tilpassede handlinger.
4. Definer et Supportordrer-emne med en beskrivelse og instruktioner, så agenten naturligt kan genkende "Hvor er min seneste ordre?".
   1. Opret tilpassede agenthandlinger:
      1. Handlingen Hent seneste bestilling for kontakt for at hente Jane's seneste bestilling
      2. Få forsendelsesstatus efter ordre-id-handling for at hente sporingsoplysninger via MuleSoft
      3. Du kan også orkestrere begge handlinger i forløbet – hente den seneste bestilling og kalde MuleSoft – ved brug af eksterne tjenestehandlinger.
      4. Føj begge handlinger til serviceagenten i konstruktøren, link dem til emnet Bestillinger og sporing og udgiv dem.
5. Definer et eskaleringsemne med en beskrivelse, der skal eskaleres til en servicemedarbejder.
   • Opret og aktiver et udgående Omni-Channel-forløb.
   • Føj den til fanen Forbindelser i konstruktøren til eskalering med en eskaleringsmeddelelse.
6. Opsæt Omni-Channel.

   Konfigurer Omni-Channel

   →

   Definer eskaleringsregler i instruktioner

   →

   Angiv prioriteter og kapacitet

   →

   Test og valider

7. Aktiver problemfri eskalering til menneskelige serviceagenter, når AI-agenten ikke kan løse forespørgslen. Konfigurer Omni-Channel-distribution for at tildele chats til servicemedarbejdere og overføre den fulde afskrift for kontekst.
8. Integrer eskaleringslogik i Agentforce og en eskaleringshandling, så agenten ved, hvornår der skal overføres komplekse sager. Administrer distributionsprioriteter og kapacitet gennem Omni Supervisor.
9. Test den fulde oplevelse: Jane åbner chatten, og agenten hilser hende velkommen, identificerer hendes ordre, henter forsendelsesdata og eskalerer problemfrit, når der kræves menneskelig indgriben (se også Aktiver forbedrede begivenhedslogfiler).
10. Opsæt dataintegration.

    Tilknyt kontekstdata

    →

    Opret MuleSoft API-legitimationsoplysninger

    →

    Registrer ekstern MuleSoft-tjeneste

11. Juster agenten med Jane's Salesforce-kontekst ved at tilknytte hendes kontakt- og bestillingsregistreringer gennem godkendte chat- eller før chat-formularer.
12. Tilslut Salesforce sikkert til MuleSoft Shipping API ved brug af eksterne legitimationsoplysninger og navngivne legitimationsoplysninger til godkendelse.
13. Hvis MuleSoft viser en OpenAPI-specifikation, skal du registrere den som en ekstern tjeneste, så Flow og agenten kan kalde den deklarativt.
14. Opsæt ustruktureret dataintegration.
    1. Opret et nyt databibliotek fra Opsætning. Navngiv den "Bestillings- og forsendelsespolitik".
    2. Tilføj PDF'er for policedokumenter, der indeholder undtagelser fra forsendelsespolitikken.
    3. Dokumenterne segmenteres, indekseres og gøres automatisk klar til brug i baggrunden.

Agentkørselsprocesforløb

Når agenten er opsat og implementeret, forekommer følgende række trin på kørselstidspunktet.

1. Chat-start: Jane åbner Agentforce (integreret service). Session og kontaktkontekst indlæses, når Jane er logget ind.

2. Hilsen og hensigt: Agenten hilser på Jane. Jane beder om status for en bestilling, og hensigtsregistrering tilknytter "seneste bestilling" til emnet Bestillinger og sporing.

3. CRM opslag: Agenten udløser handlingen Hent seneste bestilling og forespørger på Salesforce (bestillingssammendrag/bestillinger) for Jane's seneste registrering.

4. Forsendelsesanmodning: Agenten kalder MuleSoft API via en navngivet legitimationsoplysning, og /shipping/status/{orderId} returnerer en status i realtid og en sporings-URL.

5. Svarssammensætning: Agentforce fletter resultaterne og opretter et svar: "Din bestilling [OrderID] blev sendt via [Carrier], og den ankommer i morgen – [Spor her]".

6. Fallbacks: Hvis der ikke er nogen match eller en API-fejl, undskylder agenten og tilbyder at prøve igen for at løse eventuelle dataproblemer.

7. Escalation: Komplekse eller følelsesmæssige forespørgsler overføres automatisk til en person via Omni-Channel og videregiver den fulde chat og kontekst.

8. Logning: Alle hensigter, handlinger og resultater lagres i interaktionslogfiler. API-ventetid overvåges i Anypoint Monitoring.

9. Konstant forbedring: Eskaleringer giver Agentforce nyt træning. Almindelige forløb justeres i den efterfølgende version.

En kunde af høj værdi, John, har tilføjet over $1.000 værd af produkter til sin online indkøbsvogn, men fuldfører ikke købet inden for 60 minutter.

• Udløser: En Salesforce Platform-begivenhed, Cart_Abandoned__e, udløses fra e-handelssystemet, der indeholder Johns kontakt-id og værdien for indkøbsvognen.
• Agenthandling: En proaktiv agent, der abonnerer på denne begivenhed, starter straks i handling.
• Proces:
  1. Agenten kontrollerer Johns registrering i Salesforce og ser, at han er VIP-kunde.
  2. Den opretter en opgave med høj prioritet for Johns kontomanager, Sarah, med alle detaljerne i den afbrudte indkøbsvogn.
  3. Den sender en advisering til Sarah via Slack og beder hende om at følge op.
  4. Samtidig tilmelder det John i en målrettet Marketing Cloud-rejse, der sender en påmindelsesmail med en rabatkode på 10 % for en begrænset tid for at opmuntre ham til at fuldføre købet.

Opskrift

Denne opskrift viser implementeringen af en proaktiv AI-agent på Salesforce Platform for at håndtere afbrud af indkøbsvogn af høj værdi fra VIP-kunder. Løsningen bruger Salesforce Platform Events, Data 360 til Knowledge hentning og Agentforce til at orkestrere rettidige og intelligente opfølgningshandlinger og dermed omdanne passive data til aktivt forretningsengagement.

Designtid

1. Opsæt en begivenhed for en afbrudt indkøbsvogn for at udløse, når John, en VIP-kunde, efterlader indkøbsvognen afbrudt.

   Opret tilpasset kontaktfelt

   →

   Definer ny platformsbegivenhed

   1. Opret en Cart_Announced__e platformsbegivenhed med felterne Kontakt-id, Indkøbsvognværdi, Indkøbsvogn senest opdateret DateTime og Indkøbsvogndetaljer.
   2. Konfigurer afvisningsbegivenheden: Brug Commerce Cloud til at oprette en platformsbegivenhed til Checkout-begivenhedsadviseringer. Annullering registreres, når tilstanden for indkøbsvognens Checkout er i en mellemliggende tilstand, og sessionen udløber efter en tærskel. Hvis din e-handel er et eksternt system, kan du også udgive begivenheden til Salesforce ved brug af en af disse metoder: Forløb, Apex, Salesforce-API'er eller Pub/Sub API.
   3. I objektet Kontakt skal du oprette et nyt felt, Customer_Tier__c, med pluklisteværdierne Standard, Premium og VIP.
2. Opsæt ustruktureret dataoverførsel i Data 360: Tilføj et rabatpolitikdokument, der er hentet fra et dokumentlager, til Data 360 via Amazon S3.

   Opret AWS S3-legitimationsoplysninger	→	Opret ny S3-datastream	→	Konfigurer og implementer stream	→	Opret søgeindeks
   						↓
   				Test hentningsfunktion	←	Konfigurer og implementer indeks

   1. Opret eksterne legitimationsoplysninger for at få adgang til S3: Opret et nyt sæt adgangsnøgler og hemmeligheder for en IAM-bruger eller IAM Amazon-ressourcenavn (ARN) for en IdP.
   2. Opret en ny S3-datastream: På fanen Datastreams skal du oprette datastreamen Politikdokumenters stream, vælge S3-kilden, vælge PDF-filtypen, angive opdateringsfrekvensen, tilknytte metadatafelterne (filnavn og størrelse) og derefter implementere.
   3. Når datastreamen er færdig, skal du oprette et søgeindeks: Brug passageudtrækning til segmentering, E5-large-v2-integrationsmodellen og hybridsøgetypen, og implementer derefter indekset.
   4. Test den oprettede hentningsfunktion.
3. Opsæt VIP Cart Recovery-agenten.

   Opret agent fra skabelon	→	Tilføj Genopret VIP-indkøbsvogn-emne	→	Tilføj emneinstruktioner	→	Opret Slack-advarselshandling
   						↓
   Føj handlinger til emne	←	Opret rejsetilmeldingshandling	←	Opret handlingen Rabat tilbud	←	Opret gendannelsesopgave for indkøbsvogn

   1. Opret en agent fra Agentforce-medarbejderagentskabelonen.
   2. Tilføj et nyt emne, Gendan VIP-indkøbsvogn, med beskrivelsen af, at denne agent håndterer afbrud af indkøbsvogn af høj værdi for VIP-kunder.
   3. Tilføj emneinstruktioner for at validere VIP-status, kvalificere indkøbsvognen, give kontomanageren besked i Slack, anbefale et rabattilbud og tilmelde kunden i gendannelsesmailrejsen for indkøbsvognen.
   4. Opret handlinger og en opgave.
      • Handlingen Advar kontomanager: Sender en proaktiv Slack-advisering
      • Gendan afbrudt indkøbsvogn-opgave, tildelt til manageren med indkøbsvognsdetaljer
      • Handlingen Hent rabattilbud: Analyserer politik og tidligere købshistorik. Opret en meddelelsesskabelon med grounding, henvis til hentningsfunktionen i meddelelsesskabelonen, og brug dataene.
      • Tilmeld dig handlingen Gendannelsesrejse: Tilmelder sig Marketing Cloud-gendannelsesrejsen via API'en og tager alle abonnentdata og den rabatterede tilbudsmail, der genereres fra agenten.
   5. Føj handlingerne til emnet.
   6. Opret en VIP kundevognsgendannelsesrejse ved brug af skabeloner i Marketing Cloud, eller opret en ny rejse.
4. Viderestil en platformsbegivenhed for at ringe til agenten.

   Opret begivenhedsudløst forløb

   →

   Abonner på platformsbegivenhed

   →

   Tilføj agenthandling, der kan kaldes

   →

   Videregiv begivenhedsdata til agent

   1. Opret et nyt platformsbegivenhedsudløst forløb, VIP Cart Abandonment Recovery.
   2. Vælg den Annulleret indkøbsvogn-begivenhed, som forløbet skal abonnere på.
   3. Opsæt en tilpasset agent handling, der kan kaldes i Flow Builder, og vælg VIP Indkøbsvogn Recovery agent. Send anmodningen om at starte en VIP-gendannelse af den afbrudte indkøbsvogn for kunden, og send platformsbegivenhedsdataene.

Agentkørselsprocesforløb

Når agenten er opsat og implementeret, forekommer følgende række trin på kørselstidspunktet.

1. Vognsforsinkelsesregistrering: John tilføjer $1.200 til sin kurv, og ingen Checkout eller faseforløb efter 60 minutter udløser forladelse.
2. Platformsbegivenhedspublikation: Commerce Cloud udgiver begivenheden Cart_Abandoned__e med Johns kontakt-id, indkøbsvogn værdi på $1.200, indkøbsvogn ændret dato og andre detaljer.
3. Forløbsinitialisering: Platformsbegivenheden udløser forløbet Tilbagetrækning af VIP-indkøbsvogn.
4. Aktivering af medarbejderagent: Når forløbet kører, bliver VIP Cart Recovery-agenten kaldt.
5. Emnekørsel: Agenten fortsætter til emnet Gendan VIP-indkøbsvogn og udfører instruktionerne.
6. Oprettelse af meddelelse: Agenten advarer Johns kontomanager Sarah i Slack.
7. Opgaveoprettelse: Agenten opretter en opgave for Sarah og rådgiver hende om de opfølgninger, den vil udføre.
8. Rabatanalyse: Agenten kører rabatanalysen ved at kalde Data 360 retriever-funktionen for at bede om "maks. tilladte rabatter" baseret på værdien af indkøbsvognen, kundeliv og købshistorik. I denne situation anbefaler funktionen et rabattilbud på 10 %.
9. Email forberedelse og rejse tilmelding: Agenten forbereder en rabattilbudsmail og tilmelder John i Marketing Cloud-rejsen VIP Customer Cart Recovery med den nye indkøbsvognpris.
10. Logning og tilskrivning: John indløser tilbuddet, hvilket opretter en logattribut og konverteringsmetrikker.
11. Feedback-analyse: Resultatet analyseres for yderligere at bestemme tilbud, tid til gendannelse og andre optimeringsfaktorer.

En salgsrepræsentant, David, er engageret i et opdagelsesopkald med et nyt kundeemne. En intelligent agent overvåger aktivt opkaldet i realtid og giver øjeblikkelig support til David ved at besvare kundeemnets spørgsmål.

Eksempel: Hvis kundeemnet spørger om en specifik produktspecifikation, henter agenten automatisk de relevante detaljer og leverer dem til David via Slack eller en privat meddelelse.

• Udløser: Et kundeemne stiller et spørgsmål, der kræver specifikke produktoplysninger under et opdagelsesopkald med en salgsrepræsentant (David).
• Agenthandling: Miljøagenten analyserer kontinuerligt opkaldslogfiler og meddelelser og identificerer og henter påkrævede oplysninger på en intelligent måde.
• Proces:
  1. Agenten parser opkaldsafskriften i realtid.
  2. Den identificerer automatisk vigtige handlingselementer og henter relevante oplysninger.
  3. I denne situation henter agenten produktoplysninger direkte fra Salesforce.
  4. Den præsenterer derefter automatisk de hentede oplysninger for David via Slack eller en privat meddelelse.

Opskrift

Der er forudsætninger i denne opskrift, der kræver tal-til-tekst-funktioner i realtid, og vi antager, at de er tilgængelige gennem din kommunikationsudbyder. Her er f.eks. en opskrift til at integrere Zoom-opkald.

Forudsætning: Eksempel på realtidsafskrift af et Zoom-opkald:

• Opret en Zoom-app i Zoom Developer Platform med påkrævede omfang til læsning af optagelser, webhook-send og mødestream. Aktiver påkrævede produktfunktioner, f.eks. RTMS (Realtime Media Streams).
• Opsæt en mellemliggende signaleringsserver (Zoom RTMS-eksempel), der modtager lydstreamen, videresender den til Amazon Transcribe-tjenesten og henter den afskrifterede tekst tilbage. Afskrifterne udgives derefter til Salesforce som en platformsbegivenhed.

Designtid

1. Opsæt en Sales Call Realtime Response-agent.

   Opret agent fra skabelon	→	Tilføj emnet Assist-opkald	→	Tilføj emneinstruktioner	→	Opret afskriftsanalysehandling
   						↓
   		Føj handlinger til emne	←	Opret handlingen Slack-indsigter	←	Opret produktspecifikationshandling

   1. Opret en agent fra Agentforce-medarbejderagentskabelonen.
   2. Tilføj et nyt emne, Hjælp opkald med beskrivelsen af, at denne agent lytter til live-afskrifter, forstår hensigten og hjælper med produktdata.
   3. Tilføj emneinstruktioner for at parse afskrifter, hente produktspecifikationer og sende Slack-meddelelser.
   4. Opret handlinger.
      • Analyser opkaldsafskriftshandling: Analyserer opkaldsafskriftsdata, der modtages i realtid, og udtrækker vigtige spørgsmål eller handlinger
      • Handlingen Hent produktspecifikation: Knowledge på vidensartikler for produkter
      • Send Slack-indsigter til den "interne" bruger
   5. Føj handlingerne til emnet.
2. Opsæt et Product Knowledge

   Opret nyt databibliotek

   →

   Tilføj Knowledge

   →

   Systemkodestykker og indekser

   →

   Landebibliotek i aktion

   1. Opret et nyt databibliotek fra Opsætning. Kald det "Product Knowledge".
   2. Tilføj de Knowledge, der indeholder produktoplysningerne.
   3. Dokumenterne segmenteres, indekseres og gøres automatisk klar til brug i baggrunden.
   4. Brug grounding i handlingen Hent produktspecifikation.
3. Udgiv afskriften i realtid til Salesforce via Pub/Sub API.

   Server modtager lydafskrift

   →

   Server udgiver platformsbegivenhed

   1. Opret en platformsbegivenhed, Transcript_Segment__e, med felterne opkalds-id, sekvens, højttalere, segmentstarttidspunkt, segmentsluttidspunkt, varighed og afskriftsdata.
   2. I din signalserver (se forudsætningssektionen), når du har modtaget den afskriftte tekst fra lyd, udgiv straks dataene via begivenheden Transcript_Segment__e. Du kan udgive begivenheden til Salesforce ved brug af en af disse metoder: Forløb, Apex, Salesforce-API'er eller Pub/Sub API.
4. Wire Flow til at abonnere på den udgivne Transcript_Segment__e-begivenhed.

   Opret begivenhedsudløst forløb	→	Abonner på afskriftsbegivenhed	→	Tilføj agenthandling, der kan kaldes	→	Send data til agent
   						↓
   						Agent sender Slack DM

   1. Opret et nyt platformsbegivenhedsudløst forløb, Discovery-opkaldsindsigter.
   2. Vælg den Transcript_Segment__e-begivenhed, som forløbet skal abonnere på.
   3. Opsæt en tilpasset agenthandling, der kan kaldes i Flow Builder, og vælg agenten Salgsopkaldssvar i realtid. Send begivenhedsdataene for at distribuere dem til emnet Hjælp opkald. Når spørgsmålet er afledt fra emnet, sendes spørgsmålet til handlingen Hent produktspecifikation for at få et svar.
   4. Det endelige svar kompileres og sendes straks til brugeren via en Slack-DM.

Agentkørselsprocesforløb

Når agenten er opsat og implementeret, forekommer følgende række trin på kørselstidspunktet.

1. Opkaldsstart: David starter et Discovery-opkald med et kundeemne i et Zoom-opkald. Zoom RTMS streamer live-lyden til signaleringsserverens afskriftsslutpunkt.
2. Oversigt i realtid: Signaliseringsserveren modtager lyd, afskriver lyd til tekst og udgiver en afskriftssegmentplatformsbegivenhed i Salesforce Platform.
3. Agentlytning og kontekstklassificering: Salesforce modtager platformsbegivenheden og udløser forløbet Discovery-opkaldsindsigter.
4. Forløbet starter den salgsopkaldssvar i realtid-agent, der modtager segmentet, identificerer spørgsmål (f.eks. "Integrerer Toaster 2XP med mobilenheder?"), og klassificerer dem under emnet Hjælp opkald.
5. Withdrawal of Knowledge: Agenten udløser handlingen Hent produktspecifikation og forespørger på Knowledge for at matche svar.
6. Send privat Slack DM: Agenten eksekverer Send Slack-indsigt, opretter indlæg på Davids Slack-DM: "Produkt Toaster 2XP kan integreres med Apple- og Android-enheder og kan tilsluttes via Bluetooth. Når appen er installeret, skal du blot oprette forbindelse via Bluetooth og betjene brødristeren. Her er linket til manualen."
7. Fortsættelse i realtid: Agenten fortsætter med at modtage afskriftstekst. Hvis der vises flere indsigter, trådes kontekstbaserede Slack-svar uden at afbryde opkaldsforløbet.
8. Sammendrag efter opkald: Ved afslutningen af sessionen kompilerer agenten automatisk et sammendrag: nøglespørgsmål, udførte handlinger og refererede produkter.
9. Konstant forbedring: Agentforce Analytics evaluerer afskrifts-svarforsinkelse, nøjagtighed af produktmatch og salgsresultater for at justere emneinstruktioner over tid.

En salgschef, Bob, opgiver en selvstændig agent med et mål: "Forøg vores salgspipeline i den californiske manufacturing-sektor med $5 millioner inden for de næste 60 dage."

• Udløser: Manageren tildeler målet gennem en kommando i Slack.
• Agenthandling: Den autonome agent begynder sin planlægnings- og kørselsløkke.
• Proces:
  1. Udforskning: Agenten forespørger på Salesforce Data 360 og eksterne datakilder (via MuleSoft) for at identificere firmaer i Californiens manufacturing-sektor, der ikke er aktuelle kunder.
  2. Qualify: Den analyserer disse firmaer og søger efter købssignaler som seneste finansieringsrunder, nye ansættelser af ledere eller relevante jobindlæg. Den scorer og prioriterer top 20-kundeemner.
  3. Identificer kontakter: Den finder nøglekontakter (f.eks. vicedirektører for drift og anlægsmanagers) i disse firmaer.
  4. Outreach: Den kladder personlige opsøgende mails for hver kontakt og henviser til specifikke firmanyheder eller smertepunkter. Den planlægger disse mails til at blive sendt i løbet af den næste uge.
  5. Opfølgning: Den sporer mailåbninger og svar. Et positivt svar fra et kundeemne udløser en analyse af deres kalender for at foreslå mødetider, der automatisk genererer en Salesforce-begivenhed og en ny salgsmulighed ved bekræftelse.
  6. Rapport: Den leverer ugentlige Forløbsrapporter til salgschefen i Slack.

Opskrift

Dette er et multiagent-scenarie, hvor hver agent udfører en specifik opgave og overfører konteksten, data og kontrol til den næste agent. Vi vil bruge nogle få tilpassede headless-agenter til forskning og kvalifikation og den indbyggede SDR-agent til kundeemneoplysninger og overvågning. Vi antager også, at Bobs firma bruger ZoomInfo til markedsundersøgelser. Firmaet modtager også leverandørnetværksdata, der er bevaret i en database og indeholder værdifulde oplysninger om de firmaer, som de er partner med.

Designtid

1. Opsæt multiagentarkitektur.

   Forskningsagent indsamler data

   →

   Emner for kvalifikationsagentresultater

   →

   SDR-agent starter opsøgende

   1. Undersøgelsesagent: Forespørger på Data 360 og eksterne kilder via MuleSoft
   2. Kvalificeringsagent: Prioriterer, scorer og beriger emner
   3. SDR-agent: Henter emnetildelinger, udfører opsøgende, følger op og planlægger møder. Overvåg SDR-agentaktivitet og status med Agentforce Analytics for SDR-agent.
2. Udforsk og overfør nye firmadata.

   Opret nyt dataområde

   →

   Overfør Salesforce CRM-data

   →

   Overfør ZoomInfo-data

   →

   Overfør leverandørdatabasedata

   1. Opsæt et nyt dataområde ved navn Salg og Marketing. Dette nye dataområde vil indeholde alle de data, der er nødvendige for autonome agenter.
   2. Brug Salesforce-forbindelser til at forløbe Emne-, Konto-, Kontakt- og Salgsmuligheds CRM-data i dataområdet.
   3. Konfigurer en Data 360-forbindelse for ZoomInfo. Forløb dataene i Data 360 Sales and Marketing Data Space.
   4. Konfigurer Anypoint Salesforce Data 360-forbindelsen til at oprette forbindelse til leverandørdatabasen og overføre dataene til Data 360.
3. Opsæt en platformsbegivenhed for at starte den headless-undersøgelses- og kvalificeringsagent.

   Opret ny platformsbegivenhed

   1. Opret en ny AgentGoal__e platformsbegivenhed med feltet mål, der registrerer den menneskelige brugers mål på højt niveau.
4. Opsæt en Goal Orchestrator-agent, en samtale-AI-agent, der modtager brugerens mål og orkestrerer det til andre agenter.

   Opret agent fra skabelon	→	Tilføj Parse-målemne	→	Tilføj emneinstruktioner	→	Opret handlingen Målbegivenhed
   						↓
   						Føj handling til emne

   1. Opret en agent fra Agentforce-medarbejderagentskabelonen.
   2. Tilføj et nyt emne, Parse Goal (Løs mål) med en beskrivelse af, at denne agent forstår målhensigten og kan kalde yderligere agenter efter behov.
      • Tilføj emneinstruktioner for at parse målet og udløse begivenheder for andre agenter.
   3. Opret en målbegivenhed, AgentGoal__e.
5. Opsæt en emneundersøgelses- og kvalificeringsagent, som udløses af en orkestreringsagent.

   Opret undersøgelsesemne	→	Opret handlingen Deduplikering	→	Opret emnebehandling	→	Opret emnescoringshandling
   						↓
   				Føj handlinger til emne	←	Opret emnekvalifikationshandling

   1. Opret et kundeemneundersøgelse med beskrivelsen "Udforsk nye emner i et område eller en stat".
   2. Opret handlinger.
      • Apex: Kontroller og valider nye emner op mod eksisterende kunder
      • Enrich Lead Apex, der bruger en meddelelsesskabelon: Slår ind i de ustrukturerede marketingindsigter og leverandørdatabasedata for at berige emnedata
      • Scor emne-handling: Scor et emne proaktivt med opdaterede emnedata
      • Kvalificer emne for agent-handling: Baseret på scoren skal du tildele parametre, der kvalificerer emnet til en SDR-agent
6. Opsæt en Agentforce SDR-agent til at udføre opsøgende, emneopdragende og mødeplanlægning.

   Opret SDR-agent fra skabelon	→	Konfigurer agent Knowledge-base	→	Konfigurer agentmailindstillinger	→	Angiv emnetildelingsregler
   						↓
   						Definer kvalificerende emnekriterier

   1. Opret en ny SDR-agent fra opsætningssiden ved brug af den prækonfigurerede emneopdragelsesagentskabelon. Konfigurer mailindstillingerne og emnetildelingsreglerne ved at vælge emneobjektet eller kontaktobjektet og definere kvalificerende kriterier (tærskelsemnescore og nyt emne) for tildelingsregler.
   2. Opsæt Agentforce Lead Nurturing ved at konfigurere agenten, tildele tilladelser og opsætte kadence- og tildelingsregler.
   3. Konfigurer den nødvendige Knowledge for SDR-agenten til at besvare spørgsmål.
7. Opsæt et nyt forløb for at abonnere på den udgivne AgentGoal__e begivenhed.

   Opret begivenhedsudløst forløb

   →

   Abonner på begivenheden Agentmål

   →

   Tilføj agenthandling, der kan kaldes

   1. Opret et nyt platformsbegivenhedsudløst forløb ved navn Distribuer mål til agenter.
   2. Vælg den agentmålbegivenhed, som forløbet skal abonnere på.
   3. Opsæt en tilpasset agenthandling, der kan kaldes i Flow Builder, og vælg derefter emneundersøgelses- og kvalificeringsagenten.

Agentkørselsprocesforløb

Når agenten er opsat og implementeret, forekommer følgende række trin på kørselstidspunktet.

• Målopgave: Bob udpeger en selvstændig agent til at "øge pipelinen i Californien Manufacturing med $5 millioner på 60 dage".
• Mål orkestrering: Den autonome Goal Orchestrator-agent modtager målet, parser hensigten og opretter en platformsbegivenhed, AgentGoal__e. Goal Orchestrator-agenten er designet til kontinuerligt at udvide dens funktioner til at håndtere flere mål. Du kan udvide den for at tilføje yderligere orkestreringsfunktioner eller bede brugeren om en præcisering for bedre at forstå hensigten og starte målet.
• Rute: Forløbsdistributionsmål til agenter udløses og kalder emneundersøgelses- og kvalificeringsagenten.
• Udforskning: Emneundersøgelses- og kvalificeringsagenten forespørger på Data 360 for nye emneoplysninger, fjerner dubletter mod eksisterende kunder, henter yderligere markedsundersøgelsesdata fra Data 360 og beriger emnet. Det scorer yderligere emnet, identificerer nøglekontakter og kvalificerer emnet.
• Outreach: Når emnet er kvalificeret, bliver emnet berettiget til SDR-agenten via emnetildelingsreglerne. SDR-agenten foretager den indledende opsøgning og vedligeholder samtaler med kontakten ved at besvare spørgsmål, der er relateret til produktet.
• Opfølgning: Ved afslutningen af kadensen eller på anmodning fra emnet bliver agenten bedt om en mødeplan, hvis emnet er kvalificeret til servicemedarbejderengagement. Den planlægger derefter mødet og afslutter forløbet.
• Agent Analytics: Dashboardet SDR Agent Analytics giver indsigt i agentens effektivitet.

En langvarig kunde oplever et mangefacetteret problem: vedkommende blev overbelastet, den erstatningsdel, de modtog, var ukorrekt, og deres service er nu afbrudt.

• Udløser: Kunden starter en chat, og den indledende samtaleagent genkender hurtigt kompleksiteten og eskalerer til en agentudbredelse.
• Agenthandling: En orkestreringsagent tager ansvaret.
• Proces:
  1. Orchestrator: Vedligeholder samtalen med kunden og leverer opdateringer
  2. Orchestrator Delegater: Ved at bruge A2A-protokolimplementeringen finder orkestratoren "relaterede agenter" (fakturering, logistik og provisionering) med de krævede funktioner og udsender opgaver.
     • Til faktureringsagent: "Undersøg fakturaen #INV-7890 for kunde X. Er der uoverensstemmelser?"
     • Til Logistikagent: "Kontroller sporingsnummer #TN-12345 for kunde X. Bekræft det afsendte delnummer og det aktuelle lager for den korrekte del."
     • Til provisioneringsagent: "Kontroller servicestatus for konto #ACC-5678. Hvis forbindelsen er afbrudt, hvad er årsagskoden?"
  3. Specialiserede agenter udfører: Hver agent modtager A2A-anmodningen, forespørger på dens respektive system og formulerer et svar.
  4. Syntes: Agenterne rapporterer deres resultater tilbage til orkestrator via A2A-svar. Orkestrator syntetiserer oplysningerne: "Kunden blev faktisk overregnet med $50. Den forkerte del blev sendt på grund af en lagerfejl. Tjenesten blev automatisk afbrudt på grund af faktureringsproblemet."
  5. Bekræftelse: Orkestrator informerer kunden om problemet og tilbyder at eskalere problemet til en servicemedarbejder med tydelig vejledning i de næste trin.
  6. Løsning: Den foreslår derefter en komplet løsning til servicemedarbejderen til godkendelse. Servicemedarbejderen tilslutter sig samtalen. Servicemedarbejderen ser hurtigt på alle data, der er relevante for problemet, herunder agentens anbefalede løsning: "Opret en ny forsendelsesbestilling for den højre del med hurtig forsendelse. Start en returnering for den forkerte del. Godkend 10 % rabat på den nye bestilling, og opsalg delen med den seneste forbedrede version. Opdater betalingsoplysninger og tilbud for at opsætte en tilbagevendende faktureringsarrangement."

Opskrift

Denne opskrift skitserer implementeringen af et samarbejdsagentsystem, der er designet til at håndtere komplekse kundeserviceproblemer, der involverer flere facetter. Ved at bruge en orkestreringsagent til at uddelegere opgaver til specialiserede agenter (fakturering, logistik og klargøring) via en A2A-protokol og derefter at syntetisere deres resultater, leverer systemet omfattende løsninger og integrerer problemfrit servicemedarbejdere til endelig godkendelse og kundeinteraktion.

Designtid

1. Opsæt Forbedret chat som kundens chatindgangspunkt, så de kan åbne Agentforce-vinduet på websiden.
2. Opsæt en Agentforce Billing Agent, en headless specialiseret agent, der kan tage en ordre eller faktura og udføre en faktureringsforespørgsel.

   Opret agent fra skabelon

   →

   Definer emne for faktureringsforespørgsel

   →

   Opret tilpasset forløbshandling

   →

   Føj handling til emne

   1. Aktiver Agentforce, og opret en medarbejderagent fra Agentforce-medarbejderagentskabelonen.
   2. Definer et emne, Faktureringsforespørgsel, med beskrivelsen "Undersøg fakturauoverensstemmelser, betalingsproblemer og faktureringsfejl".
      1. Tilføj en tilpasset forløbshandling, Kontroller fakturauoverensstemmelse, med et input af fakturanummer, kunde-id og datointerval og et output af uoverensstemmelsesbeløb, rodårsag og påvirkede transaktioner.
3. Opsæt en Agentforce Logistics Agent, en headless specialiseret agent, der kan bekræfte forsendelser, spore forsendelser og kontrollere lager.

   Opret agent fra skabelon

   →

   Definer forsendelsesbekræftelsesemne

   →

   Opret tilpasset forløbshandling

   →

   Føj handling til emne

   1. Aktiver Agentforce, og opret en medarbejderagent fra Agentforce-medarbejderagentskabelonen.
   2. Definer et emne: Forsendelsesbekræftelse med en beskrivelse til at bekræfte forsendelse for faktura.
      1. Tilføj en tilpasset forløbshandling, Bekræft forsendelsesdetaljer, med et input af fakturanummer, kunde-id og datoområde og et output af forsendt del, dato og lagerstatus.
4. Opsæt en Agentforce, en headless-specialiseret agent, der kan bekræfte provisionering og servicestatus.

   Opret agent fra skabelon

   →

   Definer emnet Servicekontrol

   →

   Opret tilpasset forløbshandling

   →

   Føj handling til emne

   1. Aktiver Agentforce, og opret en medarbejderagent fra Agentforce-medarbejderagentskabelonen.
   2. Definer et emne, Servicecheck, med en beskrivelse for at bekræfte servicetilslutning og kontostatus.
      1. Tilføj en tilpasset forløbshandling, Bekræft service, med et input af kunde-id og aktiv-id og et output af servicestatus og serviceundtagelsesårsag.
5. Vis agenter for fakturering, logistik og klargøring som A2A-servere, og registrer dem i agentregistreringen.

   Vis agenter via MuleSoft

   →

   Registrer agenter i registreringsdatabasen

   1. I mangel af direkte A2A-understøttelse på Agentforce-agenter kan MuleSoft-forbindelser bruges til at vise agent-API'er som A2A-servere.
   2. Registrer disse A2A-servere i agentregistreringen.
   3. Brug Anypoint Agent Fabric til orkestrering af agenter.
      1. MuleSoft Agent Broker kan hjælpe med at orkestrerer enhver agent på tværs af platforme baseret på agentfunktioner, der er nævnt i agentkortene.
6. Opsæt en Agentforce Help Agent, en konverserende AI-agent, der interagerer med kunder, vurderer kompleksitet og koordinerer med flere specialiserede agenter for at løse problemet.

   Opret serviceagent	→	Definer undersøgelsesemne	→	Opret adviseringshandling	→	Definer orkestreringsemne
   						↓
   Definer eskaleringsemne	←	Opret Opret sag-handling	←	Opret opkaldsagent-handling	←	Opret agentorkestreringsforløb
   ↓
   Opret Omni-Channel-forløb	→	Tilslut forløb til eskalering

   1. Aktiver Agentforce og opret en serviceagent i Agentforce-konstruktør til at håndtere samtaler og udløse tilpassede handlinger.
   2. Definer et emne, Serviceundersøgelse, med en beskrivelse og instruktioner, så agenten naturligt genkender et komplekst emne med typisk flere samtidige problemer.
      1. Opret tilpassede agenthandlinger.
         • Statusadviseringshandling til at bekræfte problemet og levere statusopdateringer
   3. Definer et orkestreringsemne, der kan kalde andre agenter via handlinger.
      1. Opret en Call Agent-handling, der kalder en forløbshandling. Forløbshandlingen har flere agenthandlinger og kan starte hver af de headless-agenter: Faktureringsagenten, Logistikagenten og Provisioneringsagenten.
      2. Opret en Opret sag-handling, der opretter en sag, tilføjer detaljer og angiver statussen.
   4. Definer et eskaleringsemne med en beskrivelse, der skal eskaleres til en servicemedarbejder.
   5. Opret og aktiver et udgående Omni-Channel-forløb.
      • Føj den til fanen Forbindelser i agenten for eskalering med en eskaleringsmeddelelse.

Agentorkestreringsprocesforløb

Anypoint Code Builder understøtter nu opbygning af agentmæglere. En agentbroker er et intelligent distributions- og orkestreringslag, der forbinder agenter på tværs af domæner og involverer de agenter og værktøjer, der er bedst egnede. MuleSoft-udvikleragent genererer koden for at opsætte et fundament for mægleren.

Baseret på agentfunktioner, der er omtalt i agentkort (A2A-servere), der tidligere er registreret med agentregistreringen, udføres yderligere konfigurationer automatisk af Anypoint Code Builder. Endelig kan vi implementere denne agentbroker til clouden.

Så snart agentbrokeren er tilgængelig for forbrug, distribueres disse anmodninger til de rette agenter. En mægler modtager en meddelelse og bruger LLM til at nedbryde den i opgaver og bestemme, hvilken agent der skal ringe først. I hver gentagne løkke bestemmer den, om den har håndteret den oprindelige meddelelse, eller om den skal arbejde med yderligere agenter for at fuldføre jobbet.

Agentkørselsprocesforløb

Når agenten er opsat og implementeret, forekommer følgende række trin på kørselstidspunktet.

1. Chat-start: En kunde åbner Agentforce (integreret service). Sessions- og kontaktkontekst indlæses, når kunden er logget ind.
2. Hilsen og hensigt: Agenten hilser kunden velkommen. Med tydelig frustration adviserer kunden om overudgifter, den forkerte del og afbrudt service.
3. CRM opslag: Agenten udløser handlingen Hent seneste bestilling og forespørger på Salesforce (bestillingssammendrag/bestillinger) for kundens seneste registrering. Agenten bekræfter derefter bestillingen i kontekst og adviserer kunden om, at den vil undersøge. Den slår yderligere faktura-id'et, det sporingsnummer, der er knyttet til fakturaen, og aktiv-id'et, der er relateret til tjenesten op.
4. Orchestrator-aktivering: Orkestreringsagenten modtager eskalerings- og bestillings-id'et og opretter derefter en sag. Den overfører kontekstdata til og kommunikerer med tre agenter: Faktureringsagenten, Logistikagenten og Provisioneringsagenten.
5. Faktureringsagentens svar: Faktureringsagenten returnerer med detaljer om delen, enhedsomkostninger og den samlede udgift. Den bemærker også en uoverensstemmelse mellem delen i bestillingen og delen i fakturaen. Faktureringsagenten slår prisen for delen i bestillingen op og årsagerne til overprisen.
6. Logistikagentens svar: Logistikagenten returnerer med detaljer om den afsendte del og de undtagelsesnotater, der er oprettet af logistiksystemet, der angiver, at den forkerte del kan være blevet sendt på grund af taggingproblemer. Logistikagenten bekræfter også, at problemet nu er rettet, og at den korrekte del er tilgængelig i originale og nyere versioner.
7. Provisioneringsagentsvar: Provisioneringsagenten returnerer med detaljer om tjenesteafbrydelsen og problemet om de udløbne betalingsoplysninger. Den leverer også de adviseringer, der sendes for at rådgive kunden om at opdatere betalingsoplysningerne.
8. Orchestrator-syntese: Orkestreringsagenten syntetiserer svarene fra alle disse agenter og opretter en løsning ved at se på Knowledge for hvert af problemerne. Først slår det oplysninger op om den forkerte del og starter en returnering. For det andet tilbyder det en rabat for problemet baseret på løsningspolitikdokumenterne og anbefaler også en opgradering til en nyere version, som kunden kan købe (men der er en prisforskel). For det tredje skal den have nye betalingsoplysninger fra kunden, så den eskaleres til servicerepræsentanten for at kommunikere løsningen.
9. Escalation: Orkestreringsagenten eskalerer til servicemedarbejderen – leverer al den nødvendige kontekst, undersøgelsesnotater og løsningsanbefalinger sammen med de nødvendige godkendelser – og bringer servicemedarbejderen ind i opkaldet.
10. Mennesket i løkken: Servicemedarbejderen takker kunden for deres tålmodighed, undskylder for problemer og forklarer problemet. Servicemedarbejderen tilbyder derefter en rabat på 10 % for delen som kompensation og informerer også kunden om en ny opgraderet del og dens fordele. Endelig forklarer de afbrydelsen, får de nye betalingsoplysninger og opdaterer systemet.
11. Proaktiv restaurering: AI-agenten ser samtalen og reagerer proaktivt på gendannelse af tjenesten, bestilling af den opgraderede del og oprettelse af en ny faktura med rabatten og den justerede pris.
12. Sagslukning: Endelig kompilerer det sammendraget, opdaterer sagen og lukker sagen.

Hvis en agent skal være effektiv, skal den kunne integreres med et bredt sæt af virksomhedsdata og værktøjer. Dette giver den vigtige kontekst, som en agent har brug for for at udføre sit konfigurerede mål. Agentforce-strukturen leverer en sofistikeret integrationsarkitektur, der integrerer data, der både er interne for Salesforce og eksterne for Salesforce.

Dette afsnit udforsker mønstrene for tilslutning af agenter til disse ressourcer. Disse mønstre bygger på to grundlæggende tilgange til integration.

• Intern integration (dataadgang og værktøjsadgang): For ressourcer i Salesforce-økosystemet har en agent to måder at fungere på.
  • Dataadgang: Agentforce Core Runtime er dybt integreret med Data 360, så det kan forespørge på interne datatjenester direkte. Det kan som standard formulere og udføre forespørgsler mod Datadiagrammer for at få en 360-graders visning af kunden, udføre semantiske søgninger via RAG for at forstå ustruktureret Knowledge og få adgang til masseoplysninger ved hjælp af Data 360 Query API. Denne direkte sti er optimeret til hastighed og fleksibilitet i hentning af data.
  • Værktøjsadgang: Når en opgave involverer kompleks forretningslogik eller flertrinsprocesser, eller når den kræver streng styring, indkapsles dens muligheder i handlinger. Disse handlinger, der er bygget med Apex eller Forløb, giver agenten en sikker og genanvendelig grænseflade til at gøre mere end blot at læse data – de giver den mulighed for at opdatere registreringer, udløse platformsbegivenheder eller udføre enhver etableret forretningsproces.
• Ekstern integration (MCP/A2A): Når en agent har brug for oplysninger uden for Salesforce (f.eks. fra en ekstern applikation, en mikroservice eller en anden agent), bruger vedkommende MCP (Model Context Protocol). Denne åbne standard leverer et fælles sprog til interoperabilitet. MCP-servere kan tilføjes fra AgentExchange eller en administrator kan tilføje i agentregistreringen eller et Apex-udkald til MCP-serveren. Derefter starter handlingen anmodningen til en ekstern MCP-server og danner bro mellem de interne og eksterne verdener på en struktureret måde. På samme måde, når en agent har brug for at kommunikere med en anden agent, letter Agent2Agent (A2A)-protokollen denne interaktion. Dette tillader oprettelse af komplekse systemer med flere agenter, hvor specialiserede agenter kan samarbejde om at løse komplicerede problemer og fremme modularitet og genanvendelighed.

Følgende mønstre er organiseret omkring de specifikke dataintegrationstemaer, som agenter har brug for. Vi vil vise, hvordan disse mønstre anvendes til at løse særskilte dataudfordringer, fra tilslutning til eksterne applikationer ved brug af MCP til adgang til højvolumen massedata i Data 360, realtids transaktionsregistreringer og ustruktureret indhold ved brug af den kraftfulde kombination af direkte adgang og formelle handlinger i Data 360.

Problem

En agents effektivitet afhænger af dens mulighed for at betjene eksterne værktøjer. Men disse værktøjer – fra ældre ERPs til moderne SaaS-applikationer – mangler et fælles sprog. Hver har en entydig API, godkendelsesmodel og dataformat. Dette tvinger udviklere ind i en skrøbelig og ikke-skalerbar cyklus af opbygning og vedligeholdelse af tilpassede punkt-til-punkt-integrationer for hvert nyt værktøj, som agenten skal bruge.

Kontekst

Overvej en agent, der er udnævnt til at løse en beskadiget forsendelsessag. For at få succes, skal det interagere med tre forskellige eksterne systemer: Det skal forespørge en leverandørs API for at kontrollere for erstatningsopbevaring, ringe til en logistikpartners service for at arrangere en ny levering og få adgang til et finansielt system for at behandle en kredit. Uden en fælles protokol vil agenten kræve tre separate, tilpassede integrationer, der hver især er et potentielt fejlpunkt. MCP leverer et standardiseret kommunikationslag for at gøre disse interaktioner problemfrie og pålidelige.

Følgende er opskrifter for, hvordan du integrerer eksterne tjenester, der vises via MCP, til din agent.

Opskrift 1: Aktivering af eksterne værktøjer med MCP

Problem

Organisationer kører på en blanding af forældede ERP'er og moderne SaaS, men det er svært at integrere dem med en agent, fordi der ikke er nogen fælles protokol – hvert værktøj har sine egne API'er, godkendelse og datamodel. Udviklere ender med at opbygge og vedligeholde tilpassede punkt-til-punkt-forbindelser for hvert værktøj og opretter skrøbelige, ikke-skalerbare og dyre integrationer.

Mønster

Agenten kalder et eksternt værktøj (vises via MCP) gennem en struktureret handling, så den kan bruge specialværktøjer ud over Salesforce-platformen.

Kontekst

• Agenten fungerer som en proxy for et sæt værktøjer, der findes uden for Salesforce Platform.
• Disse eksterne værktøjer kan have forskellige API'er, godkendelsesmekanismer og dataformater.
• Der kræves en standardiseret kommunikationsprotokol for at aktivere problemfri interaktion mellem agenten og disse eksterne værktøjer.
• Genanvendelighed er et vigtigt problem, da de samme eksterne værktøjer kan bruges af flere agenter til forskellige formål.

Interaktioner

1. Udløser: En brugeranmodning eller en intern begivenhed i Agentforce kræver brug af et eksternt værktøj.
2. Hensigt til at handle: Agentforce identificerer hensigten og bestemmer, at der kræves et eksternt MCP-baseret værktøj.
3. Planlægger (intern): Agentforce planlægger vælger det relevante MCP-værktøj eller -handling baseret på dens konfigurerede instruktioner og tilgængelige værktøjer.
4. Kørsel: Agentforce sender en MCP-kompatibel anmodning til den eksterne MCP-server (f.eks. via et Apex til et MuleSoft-slutpunkt, som derefter distribueres til den eksterne MCP-server).
5. Ekstern behandling: Den eksterne MCP-server behandler anmodningen, interagerer med den underliggende eksterne applikation og forbereder et MCP-kompatibelt svar.
6. Resultat: Den eksterne MCP-server returnerer svaret til Agentforce.
7. Opfølgning: Agentforce behandler svaret, opdaterer dets interne tilstand og fortsætter sin opgave eller giver feedback til brugeren.

Trade-Offs

En agents beslutningslogik er kun så god som dens underliggende data. Hvis en agent skal agere intelligent, skal vedkommende have en omfattende forståelse i realtid af verden omkring sig. Uden en defineret dataoverførselsarkitektur kan agenten ikke få adgang til eller behandle de højvolumen realtidsoplysninger, der er vigtige for, at den fungerer.

Integrer transaktionsdata med agenter

Problem

Agenter har ofte brug for at udføre læse-/skrivehandlinger med lav forsinkelse på individuelle registreringer, der findes i registreringssystemer (f.eks. opdatering af en sag eller hentning af en bestillingsstatus). Disse handlinger kræver dataintegritet og pålidelighed for at sikre ensartethed af den underliggende datamodel. Kernearkitektoniske udfordringer er at levere et sikkert, realtids- og skalerbart mønster for denne transaktionelle dataadgang uden at oprette skrøbelige punkt-til-punkt-integrationer.

Kontekst

En succesfuld tilslutning af en agent til disse registreringer kræver en robust arkitektur, der består af flere kernekomponenter.

• Transaktionssystemer: Disse er de autoritative kilder til dataene, f.eks. registreringssystemer som Salesforce, Workday eller SAP, eller tjenester hostet på platforme som AWS.
• Integreringslag: Et effektivt integrationslag, der typisk håndteres af MuleSoft, er afgørende for at oprette en sikker forbindelse til disse uensartede systemer, transformere data og vise dem på Agentforce-platformen.
• MCP-servere: For at sikre interoperabilitet kommunikerer agenter med disse eksterne systemer ved brug af MCP-standarden. Integrationslaget kan oprette forbindelse til forskellige MuleSoft-, Heroku- eller tredjeparts MCP-servere, der er vært for de eksterne tjenester eller agenter.
• Agentudveksling: Denne komponent fungerer som en mappe eller et omskifter, hvilket gør det muligt for Salesforce-agenten at finde og tilslutte sig den korrekte eksterne tjeneste eller agent for at fuldføre sin opgave.

Opskrift 1: Direkte registreringshandlinger via MCP

Mønster

Agenten bruger MCP til at oprette forbindelse til et transaktionsdatasystem og udfører tilstandsbaserede CRUD-handlinger på specifikke, identificerede registreringer med øjeblikkelige ensartethedskrav.

Kontekst

• Samtalende samarbejdsagenter skal overføre registreringssystemdata i arbejdsflowet.
• Systemet for registreringen er et eksternt system.
• Transaktioner skal være idempotent.

Nøglekomponenter

• Agentforce Agent: Med emner og instruktioner til at foretage en transaktionsopdatering. Handlinger kalder en ekstern MCP-server eller Agentforce Exchange-registreret MCP-server.
• MCP-server: Den MCP-server, der viser transaktionsdataene og -funktionen (f.eks. tool=billing.update_record med inputdata)
• Eksternt registreringssystem: Det system, hvor tilstandsændringen forekommer

Interaktioner

1. Udløser: Der forekommer en kommando eller begivenhed, der kræver en transaktion på en registrering.
2. Hensigt til at handle: En Agentforce identificerer en tilstandsændringshensigt.
3. Planlægger (intern): Planlæggeren vælger et MCP-værktøj.
4. Udfør: Værktøjet køres, når adgangskontrollerne på politik-, registrerings- og feltniveau passerer.
5. Resultat: MCP-serveren returnerer et svar
6. Opfølgning: Agentforce behandler svaret.

Trade-Offs

Opskrift 2: Kompleks orkestrering via Mulesoft API

Mønster

Agenten anvender Mulesoft API til komplekse atomtransaktioner med flere trin på tværs af systemer. Dette giver et enkelt, administreret slutpunkt, der sikrer pålidelig end-to-end-behandling og undgår ensartethedsproblemer, pålidelighed, forsinkelse og dataproblemer, der er knyttet til direkte opkald til individuelle systemer.

Kontekst

• Samtaleagenter og autonome agenter har ofte brug for at udføre flere handlinger pålideligt.
• Der er flere transaktionssystemer og handlinger i en transaktion.
• Arbejdsflows kræver transaktion/tilbagerulning, forsøg og policehåndhævelse.
• Transaktionsbehov er i realtid, idempotent, observerbare og kompatible.

Interaktioner

1. Udløser: Der forekommer en kommando eller begivenhed, der kræver, at der udføres en kompleks transaktion.
2. Hensigt til at handle: Agentforce identificerer hensigten.
3. Planlægger (intern): Planlæggeren vælger en handling, der kan kaldes for API- eller API-handling.
4. Kørsel: API'en køres, og et svar returneres.
5. Opfølgning: Agentforce behandler svaret.

Trade-Offs

Integrer analytiske data med agenter

Problem

Organisationer har investeret meget i analytisk infrastruktur – datalagre og søer, realtidsanalysesystemer og forretningsintelligensplatforme – men AI-agenter forbliver afbrudt fra disse systemer. Dette skaber et hul i en agents mulighed for at få en beriget kontekst (f.eks. at en kunde havde returneret dele tre gange i det sidste kvartal) for at hjælpe med at træffe bedre beslutninger (i dette tilfælde eskalering).

Kontekst

En agents driftsmæssige intelligens afledes fra dens mulighed for at syntetisere oplysninger fra fundamentalt forskellige dataformater og kilder. Dette arkitektoniske mønster er derfor ikke designet til en enkelt anvendelsessituation, men som en grundlæggende struktur for dataoverførsel. En effektiv agent skal være udstyret til at behandle strukturerede kilder for at udføre logiske, datastyrede analyser. En agent kræver adgang til højvolumen strukturerede feeds. Dette omfatter integration med virksomhedens datalager (via nul-kopi-integration med Data 360), behandling af mellemprogramtransformerede datastreams eller overførsel af batchfiler som f.eks. CSV'er.

Opskrift 1: Data Lakes integreret via Data 360 Zero-Copy

Problem

Organisationer står over for høje omkostninger, når de bruger traditionelle datapipelines til at kopiere, administrere og transformere analytiske data, der er lagret i datalager (f.eks. Snowflake). Historisk har analyser hovedsageligt været offline, hvilket resulterede i manglende salgsmuligheder for rettidig handling.

Mønster

Agenten forespørger på nul-kopieringsdata (og beregnede indsigter) tilgængelige i Data 360 i stedet for at forespørge på eksterne datalager for kritiske indsigter. Dette hjælper agenter med at basere både transaktionsmæssige og analytiske data på bedre beslutningstagning.

Kontekst

• Din organisation lagrer kunde- og driftsdata i datalager og søer.
• Dine agenter skal have adgang til aggregerede metrikker, historiske tendenser og analytiske indsigter.
• Din agents kontekst skal bruge både transaktionsmæssige og analytiske data (overvej en undersøgelses agents behov for historiske tendensdata).

Interaktioner

1. Udløser: En agent modtager en forespørgsel vedrørende en indsigt, der kræver adgang til analytiske data eller en beregnet indsigt.
2. Kørsel: Agenten udfører en handling, der kalder Data 360-beregnede indsigter via forespørgsels-API, og den beregnede indsigt returneres.
3. Opfølgning: Agentforce behandler svaret.

Trade-Offs

Opskrift 2: Udløsning af handlinger fra datastreams

Problem

Organisationer genererer kontinuerligt værdifulde oplysninger fra forretningsaktiviteter som websitebesøg, opkald, møder, chats og sensordata. Men på det tidspunkt, hvor disse interaktioner bliver tilgængelige eller hentes fra datalagre, går kritiske indsigter tabt, og muligheden for rettidig intervention er forbi. Derfor mangler organisationer det meste af den intelligens, der kan handles på, der er nødvendig i realtid, som ofte er begravet i disse midlertidige streams. Dette fører til huller, manglende coachingmuligheder og beslutninger, der træffes uden fuldstændig kontekst.

Mønster

Agenten modtager indsigter i realtid eller næsten i realtid fra streamingindsigter eller en indsigt i realtid i Data 360 via en datahandling, eller agenten får adgang til en streamingindsigt i realtid ved at forespørge på en MCP-server, der har forbindelse til et realtidsbehandlingssystem som Apache Flink.

Kontekst

• Streamingsystemer som platformsbegivenheder, Pub/Sub API og RTEM genererer enorme mængder streamdata.
• Streambehandlingssystemer som Data 360 og Apache Flink behandler disse individuelle begivenheder, efterhånden som de ankommer.
• Agentforce skal forespørge på streamsystemerne (f.eks. den seneste afskrift på 30 sekunder for live-mødet med yderligere kontekst) eller blive udløst af en datahandling (f.eks. bedrageriregistrering).
• Der er behov for næsten realtidshandling med lav forsinkelse.

Interaktioner

1. Stream emitter: Kildesystemet udsender en kontinuerlig stream af data.
2. Stream-behandling: Streambehandlingssystemer som Data 360 eller Apache Flink behandler oplysningerne.
3. Transform: Indsigter aggregeres, transformeres og syntetiseres til agentbevidste data i middleware (til kompleks transformation) eller i Data 360.
4. Streamindsigtsbegivenhed: En Data 360-datahandling udløses for syntetiserede data (f.eks. en afskrift af en 30-sekunders lydstream).
5. Berig: En agent tilføjer kontekst og registrerer hensigt.
6. Udfør: Agenten udfører handlingen.
7. Opfølgning: Agenten venter på den næste streamingindsigt.

Trade-Offs

Integrer semantiske data med agenter

Organisationer har forretningsartefakter – kataloger, manualer, politikker, Knowledge, relationskort – i forskellige formater og figurer. For at gå ud over simpel opgaveudførelse og engagere sig i sofistikeret begrundelse, skal agenter være i stand til at forstå disse data, hvor de fleste menneskelige Knowledge er lagret.

Opskrift 1: RAG: Lås styrken fra ustrukturerede data op for agenter

Problem

Organisationer har ofte ikke-søgbare oplysninger, der forhindrer agenters mulighed for at få adgang til dem med tillid. Denne mangel fører ofte til ufuldstændige svar fra agenter, der mangler den nødvendige kontekstdybde og verificerbare referencer til at etablere Trust. Derfor er der et tydeligt behov for en standardiseret metode for at gøre det muligt for agenter konsekvent at hente semantisk relevant og nøjagtigt indhold.

Mønster

Dette mønster giver arkitekturen til at gøre det muligt for agenter at overføre og fortolke en lang række ustrukturerede oplysninger, fra interne dokumenter til offentligt webindhold. Givning af en agent adgang til disse data er nøglen til at låse avancerede funktioner op som markedssentimentanalyser, dokumentsammendrag og konkurrentundersøgelser.

Kontekst

• Knowledge findes i filer i forskellige formater og formater.
• Overflødigt indhold er almindeligt på tværs af disse dokumenter.
• En agent skal have nøjagtige oplysninger, der kan anføres.
• Knowledge ændres ofte, så filer skal opdateres og indekseres igen.

Interaktioner

Indholdet kan ikke overføres eller bruges af agenten, som det er. Indholdet skal segmenteres, integreres, lagres i en vektordatabase og indekseres, før det kan hentes og bruges af agenter.

Indtag og tilbered

1. Crawl- og overførselskilder: Kilder kan identificeres på to måder: manuelt, f.eks. ved upload af en PDF-fil, eller efter deres placering, f.eks. AWS S3.
2. Chunking: Det overførte indhold opdeles i mindre, administrerbare segmenter for at gøre effektiv behandling og hentning nemmere. Dette er et kritisk trin for RAG, da det sikrer, at kun de mest relevante oplysninger hentes, snarere end hele dokumenter.
3. Integrering: Hver del konverteres derefter til en numerisk repræsentation kaldet en integration ved hjælp af en specialiseret sprogmodel. Disse integrationer registrerer den semantiske betydning af teksten og tillader tilsvarende søgninger.
4. Vektoropbevaring: Integreringerne lagres i et Data 360-vektorlager, en specialiseret database, der er optimeret til søgninger med høj ydeevne. Dette gør det muligt for agenten hurtigt at finde relateret indhold.
5. Indeksering: Indholdet og dets integrationer indekseres i vektorbutikken, hvilket gør det nemt at søge efter dem til hentning.

Data 360 retriever funktioner

• Hent indhold: Denne funktion tager en forespørgsel som input og udfører en semantisk søgning mod Data 360-vektorlageret for at finde de mest relevante indholdsskruer.
• Filterindhold: Denne funktion tillader filtrering af hentet indhold baseret på metadata, f.eks. dokumenttype, dokumentopretter eller dato for yderligere at justere resultaterne.
• Rank content: Denne funktion rangerer de hentede indholdsskruer baseret på deres lighedsscore (vektorsøgning), nøgleordsscore eller en kombination af begge (hybrid søgning).

Hent og generer

• Forespørgsel: Når en agent har brug for oplysninger, formulerer den en forespørgsel, der også er integreret i en vektor.
• Semantisk søgning: Agenten udfører en semantisk søgning mod Data 360-vektorlageret og sammenligner forespørgslens integrering med integreringerne af de lagrede indholdsskruer. Dette henter de mest semantisk relevante segmenter baseret på vektor score eller hybrid score (vektor og nøgleord kombineret).
• Return-augmented generation (RAG): De hentede indholdsskruer leveres derefter som kontekst til Agentforce sammen med den oprindelige forespørgsel. LLM bruger denne kontekst til at generere et præcist, nøjagtigt og citerbart svar.
• Svar og citation: Agenten præsenterer det genererede svar, ofte med henvisninger til de oprindelige kildedokumenter eller weblinks, for at opbygge Trust og muliggøre verifikation.

Trade-Offs

Opskrift 2: Datadiagrammer: Forudvalgte strukturerede diagramdata for agenter

Problem

Organisationer har ofte isolerede relationsdata, der forhindrer en agents mulighed for at hente dem. Dette problem resulterer ofte i agenter, der leverer ufuldstændige svar, der mangler tilstrækkelige kontekstdetaljer til at opbygge Trust om, hvordan forskellige enheder er forbundet, eller forårsager forsinkelser, når agenter skal hente oplysninger fra flere databaser.

Mønster

Dette mønster giver arkitekturen til at gøre det muligt for agenter at overføre og fortolke en lang række strukturerede og semistrukturerede relationsoplysninger, fra interne CRM-data til eksterne Knowledge. Givning af en agent adgang til disse data er nøglen til at låse avancerede funktioner op, f.eks. Customer 360, komplekse afhængighedsanalyser og dynamisk kontekstopbygning.

Kontekst

1. Relationsdata distribueres på tværs af forskellige systemer og formater.
2. Agenter har brug for at forstå forbindelser mellem enheder (f.eks. en kunde, deres sager, deres bestillinger og relaterede produkter).
3. Knowledge og tilsluttede datamodeller er vigtige for at forstå komplekse relationer.
4. Agenten skal have nøjagtige oplysninger om enhedsrelationer, der kan anføres.

Interaktioner

Relationsdata skal harmoniseres og repræsenteres i en grafstruktur, før de effektivt kan forespørges på og bruges af agenter.

Indtag og tilbered

1. Crawland ingest kilder: Datakilder (f.eks. CRM-systemer, ERPs, eksterne API'er og CSV'er) identificeres og overføres til Data 360.
2. Dataharmonisering: Rå data knyttes til DMO'er (datamodelobjekter) i Data 360, standardiserer deres struktur og opretter en forenet visning.
3. Id-løsning: Dubletkundeprofiler konsolideres, og relaterede registreringer linkes for at oprette en enkelt, nøjagtig visning af hver kunde.
4. Datadiagramoprettelse: DMO'er tilsluttes til at danne et datadiagram, der repræsenterer relationer mellem forskellige enheder (f.eks. er et kunde-DMO tilsluttet til et sags-DMO, som er tilsluttet til et produkt-DMO). Dette diagram tillader effektiv gennemgang af relationer.
5. Beregnede indsigter: Aggregeringsmetrikker og afledte attributter (f.eks. en kundes samlede købshistorik) beregnes og føjes til datadiagrammet for at få en mere avanceret kontekst.

Hent og generer

1. Forespørgsel: Når en agent har brug for oplysninger, der involverer relationer mellem enheder, formulerer den en forespørgsel mod datadiagrammet (f.eks. "Hvad er alle åbne sager for denne kunde, og hvilke produkter er tilknyttet dem?").
2. Gram traversal og forespørgsels-API: Agenten bruger Data 360-forespørgsels-API'en til at gennemgå datadiagrammet og hente tilsluttede registreringer, beregnede indsigter og relevante attributter baseret på forespørgslen.
3. Kontekstgenerering: De hentede relationsbevidste data leveres derefter som kontekst til Agentforce sammen med den oprindelige forespørgsel. LLM bruger denne berigede kontekst til at generere et præcist, nøjagtigt og citerbart svar, der afspejler dataenes sammenhæng.
4. Svar og citation: Agenten præsenterer det genererede svar, ofte med referencer til de specifikke registreringer eller relationer i datadiagrammet, der informerede svaret, for at opbygge Trust og tillade verifikation.

Trade-Offs

Virksomheden står for en ny æra af automatisering og intelligens, ledet af AI-agenter. Fra håndtering af enkle kundeforespørgsler til selvstændig kørsel af komplekse forretningsstrategier lover agenter at omdefinere produktivitet og kundeengagement. Salesforce Agentforce tilbyder det vigtige, betroede fundament for denne transformation. Med en robust suite af deklarative og pro-code-værktøjer, en forenet dataplatform og forpligtelse til åbne standarder gennem A2A og MCP, Agentforce giver et omfattende og pålideligt fundament til at opbygge enhver type agent. Denne arkitektur gør det muligt for organisationer at implementere intelligente målorienterede agenter, der fungerer som tilsluttede partnere, ikke isoleret, for at fremme målbar forretningssucces.

Salesforce leverer et effektivt, integreret sæt værktøjer, forenet af Agentforce, der fungerer som grundlaget for opbygning af sofistikerede agenter. Opskrifterne og eksemplerne i dette dokument forudsætter, at du er bekendt med funktionerne i Agentforce Platform og hvordan agenterne interagerer. Dette afsnit tilbyder en opdatering af de nøglekomponenter, du har brug for at forstå for at få mest muligt ud af opskrifter og mønstre i dette dokument.

Dette afsnit skitserer de grundlæggende platformsfunktioner, der er vigtige for arkitekter og udviklere, der opbygger agenter på Agentforce.

• Salesforce-forløb: Det primære værktøj til definition af agentlogik. Dens deklarative, visuelle grænseflade er ideel til orkestrering af de trin, som en agent skal udføre.
• Apex: Giver styrken til kompleks tilpasset logik, statsstyring for autonome agenter og komplicerede integrationer
• Platformsbegivenheder: Nervesystemet for proaktive og samarbejdsagenter, der fungerer som transportlaget for A2A-protokollen.
• Data 360: Agentens forenede, langsigtede hukommelse. Den leverer den kontekst, der er nødvendig for intelligent handling, og er grundlaget for RAG (getting-augmented generation).
• MuleSoft: Agentens bro til den ydre verden, der aktiverer både systemintegration og agentkommunikation på tværs af platforme via MCP.
• Slack: En primær oversigt for interaktion mellem mennesker og agenter, herunder opgaver, adviseringer og godkendelser
• Agentforce Chat-klient: Den front-end, der kan tilpasses, integreres for kundeorienterede samtaleagenter

Hvis agenter skal være virkelig effektive, kan de ikke eksistere i en silo. Agentforce omfatter to grundlæggende interoperabilitetsmønstre:

• Agent2Agent (A2A) kommunikation: Denne protokol styrer, hvordan agenter i Salesforce-økosystemet kommunikerer med hinanden. Agentforce platform fungerer både som en A2A klient og en server, der opretter og lytter til anmodninger, hvilket er afgørende for samarbejdsagent-swarms. Agenter kan konfigureres med relaterede agenter til at opdage og kalde andre agenter med specifikke færdigheder, hvilket skaber et dynamisk og udvideligt system. Platformsbegivenheder fungerer som den holdbare asynkrone transportmekanisme for disse A2A-meddelelser.

• Modelkontekstprotokol (MCP): Denne standard sikrer, at agenter ikke er låst i en enkelt platform. MCP definerer et fælles meddelelsesformat, der tillader agenter, der bygger på forskellige strukturer, at kommunikere. I denne model fungerer Agentforce som en MCP-klient. En Salesforce-agent kan f.eks. forespørge på en ekstern agent, der er specialiseret i komplekse logistiske beregninger, ved at sende den en MCP-kompatibel anmodning. MuleSoft fungerer som gatewayen og transformerer den interne A2A-anmodning til et eksternt MCP-formateret API-kald, hvilket sikrer problemfri interoperabilitet på tværs af virksomheden.