Programvareparadimet skifter fra direkte manipulering til målrettet delegering. I forkant av denne transformasjonen er AI-agenter – autonome, intelligente enheter som kan forstå, tenke og handle på vegne av brukere. Denne hviteboken gir en teknisk utforsking av de primære typene AI-agenter: Samtale, Proaktiv, Ambient, Autonomous og Samarbeid. Den definerer hver type, presenterer spesifikke brukstilfeller av CRM (Customer Relationship Management) og gir en arkitektonisk blåkopi for å bygge disse agentene på Salesforce Agentforce Platform, komplett med tekniske eksempler som utnytter Flow, Apex, Data 360, Agent2Agent (A2A)-kommunikasjon og modellkontekstprotokoll (MCP)-interoperabilitet.

En AI-agent er et system som oppfatter miljøet og utfører handlinger for å oppnå bestemte mål. Konseptet er ikke nytt, men fremveksten av kraftige store språkmodeller (LLM-er) har overbelastet deres funksjoner. Vi kan kategorisere agenter basert på deres primære operasjons- og interaksjonsmodus.

Definition: Samtaleagenter er den mest kjente agentypen. De fungerer på en reaktiv, forespørsel-svar-modus, primært via grensesnitt for naturlig språk (tekst eller tale). Kjernefunksjonen deres er å forstå brukerhensikt og gi et relevant svar, enten det er å svare på et spørsmål, hente informasjon eller utføre en enkel kommando.

Viktighet: Samtaleagenter er de digitale inngangsdørene til en organisasjon. De utmerker seg ved å håndtere veldefinerte, gjentagende oppgaver og dermed frigjøre menneskelige ressurser. Deres effektivitet måles av deres evne til å løse brukerhensikt raskt og nøyaktig og til å iverksette tiltak på vegne av brukerne.

Definition: Til forskjell fra samtalerepresentanter som venter på en ledetekst, fungerer proaktive agenter som våkne observatører. De utløses av bestemte hendelser, dataendringer eller forhåndsdefinerte betingelser i et system. Når de utløses, utfører de en oppgave eller starter en arbeidsflyt uten å kreve direkte brukermedvirkning.

Viktighet: Proaktive agenter transformerer et system fra et passivt oppbevaringssted for data til en aktiv deltaker i forretningsprosesser. De identifiserer salgsmuligheter og risikoer etter hvert som de dukker opp, slik at virksomheter kan handle på viktige signaler i sanntid.

Definition: Ambientagenter er en spesifikk type proaktive agenter som arbeider kontinuerlig i bakgrunnen av en brukers arbeidsflyt uten å kreve eksplisitte kommandoer. Brukere drar ofte nytte av sine handlinger uten å være bevisst klar over operasjonen, fordi de er utformet for å øke menneskelig kapasitet samtidig som de opprettholder en lav profil.

Viktighet: Målet med en miljøagent er å redusere den kognitive belastningen på brukerne ved å automatisere det hverdagslige "arbeid om arbeid". De gjør prosesser mer effektive ved å sømløst integrere dem i verktøyene ansatte bruker hver dag, og fange opp og strukturere informasjon automatisk.

Definition: Autonome agenter representerer et betydelig sprang i kompleksitet. De får et mål på høyt nivå og kan uavhengig planlegge og utføre en sekvens av trinn for å oppnå dette målet. De kan begrunde, ta beslutninger og til og med lære fra sine handlinger for å forbedre ytelsen over tid.

Viktighet: Dette er det nærmeste vi kommer til en ekte digital ansatt. Autonome agenter kan delegeres til et komplekst, flertrinns mål, som "Generer 50 nye kvalifiserte salgsemner i manufacturing-sektoren dette kvartalet", og de kan være klarert til å formulere og utføre en plan for å oppnå det.

Definition: Samarbeidsagenter, ofte kalt "agent-sversjoner", er en samling spesialiserte agenter som arbeider sammen for å løse et problem som er for komplekst for en enkelt agent å håndtere. En "orkestrator"- eller "overordnet"-agent dekomponerer ofte en stor oppgave, delegerer underoppgaver til de riktige spesialiserte agentene og syntetiserer deretter utdataene. En robust Agent2Agent (A2A)-kommunikasjonsprotokoll oppnår dette.

Viktighet: Denne løsningen gjenspeiler et mennesketeam. Ved å dele opp et komplekst problem kan hver spesialisert agent ta på seg sine unike kvalifikasjoner: én spesialiserer seg på dataanalyse, en annen på kundekommunikasjon og en tredje på systemintegrering, noe som fører til en mer robust og omfattende løsning.

Etter å ha utforsket taksonomien til AI-agenter, gjenstår det et avgjørende spørsmål: Hvordan kombinerer vi disse elementene for å løse virkelige forretningsproblemer effektivt og pålitelig? Dette kapitlet besvarer dette spørsmålet ved å tilby et oppbevaringssted for vanlige agentiske utformingsmønstre. Hvert mønster er en godt utprøvet løsning på en gjentagende utfordring, og tilbyr en blåkopi for alt fra enkle, engangsagenter til komplekse, samarbeidsagentsversjoner.

Samtaleagenter er ofte hoveddøren til en organisasjons AI-funksjonalitet. De defineres av deres mulighet til å engasjere seg i en statusfylt dialogboks med flere omgange, som fungerer som det primære grensesnittet der brukere utfører oppgaver og henter informasjon med naturlig språk. Denne delen presenterer to viktige oppskrifter for å bygge samtaleagenter, hver skreddersydd til en bestemt kanal: en for de raske, interaktive utvekslingene av meldingsklienter, og en annen for den strukturerte, asynkrone naturen til e-post.

En samtaleagentens intelligens utledes fra dens mulighet til å få tilgang til og tenke over de riktige dataene til riktig tid. Dette mønsteret er avhengig av et avansert datagrunnlag som kobler til kundeposter, Knowledge og forretningsanalyse. De komplette, gjenbrukbare oppskriftene for disse integrasjonene er tilgjengelig i kapittel 4: Integrasjonsmønstre.

Problem

Kunder engasjerer seg på tvers av mange digitale kanaler og forventer øyeblikkelige, kontekstuelle og intelligente svar. Tradisjonelle chatteroboter er enten skriptet eller datasymptomatisk, noe som fører til dårlig tilpassing, tidlig eskalering til mennesker og høye servicekostnader.

Context

• Organisasjonen har digitalt engasjement med flere kanaler (WhatsApp, SMS, Slack og Salesforce Experience Cloud).
• Organisasjonens kunder samhandler med organisasjonen på flere språk.
• Organisasjonen må utvide tjeneste- og salgsarbeidsflyter med agenter som
  • Hente fra sanntids, klarerte kundedata
  • Respekter sikkerhetskrav og krav til etterlevelse
  • Eskaler til agenter bare når det er nødvendig

Nøkkelkomponenter

• Kanalabstraksjon: Med Service Cloud-forbedret chat (tidligere Meldinger for i app og på nett) kan agenten kommunisere på tvers av flere kanaler via én enkelt opplevelse.
• Agentforce tjenesteagent: Agentenes virkemåte og formål defineres av følgende komponenter.
  • Emner og instruksjoner: Definerer agentens personlighet og samtaleformål for direkte brukermedvirkning. Dette inkluderer kjerneoppgaven (for eksempel "Du er ekspert på å løse kundestøtteproblemer"), instruksjoner om å opprettholde en empatisk og profesjonell tone, og klare vakter om omfanget av forespørsler den er autorisert til å håndtere.
  • Handlinger: Tjenesteorienterte handlinger som er verktøy som agenten bruker til å diagnostisere og løse kundeproblemer i sanntid. Disse verktøyene er utformet for å utføre oppgaver som å kontrollere statusen til en bestilling, søke i en Knowledge etter løsninger eller opprette en ny kundestøttesak direkte fra samtalegrensesnittet.
  • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
  • Meldingsmaler: Gjenbrukbare maler som fylles ut dynamisk med direkte CRM-data via flettefelt eller semantiske data fra Data 360 RAG Retrievers. Disse malene gir agenter mulighet til å generere kontekstuelt innhold med merkeprofilering, mens Einstein Trust Layer sikkert maskerer sensitiv informasjon før instruksjonene sendes til LLM.
• Data 360
  • Data 360-komponenter, inkludert DLO-er, DMO-er, vektorbutikk og RAG-henteverktøy, gir agenten en forent oversikt over alle relevante bedriftsdata, fra strukturerte kundeposter til ustrukturerte Knowledge, slik at svarene er nøyaktige og kontekstuelt grunnlagde.
• Service Cloud
  • CRM data: Kobler agenten til den fullstendige sakshistorikken og gir viktig kontekst for kontodetaljer, kontaktposter og berettigelser
  • Live Agent-kø: Støtte for eskalering og ruting til en servicerepresentant med hele samtalekonteksten injisert

Interaksjoner

1. Organisasjonens kunde starter samtalen via en kanal.
2. Meldingen rutes til Agentforce, som bestemmer omfanget (emner) og bruker guardrails.
3. AI komponerer svar ved bruk av ledetekstmaler, mens Flyt eller Apex kan utløse serverdellogikk.
4. Kontekst hentes fra Data 360-objekter, vektorlagring og CRM via RAG retriever.
5. AI returnerer et kontekstuelt svar.
6. Hvis AI ikke kan løse problemet, eskaleres samtalen til Service Cloud Live Agent.

Trade-Offs

Relatert mønster

Greeter mønster: Et enkelt og enkelt å implementere mønster som bruker naturlig språk til å forstå brukerhensikt, og deretter ruter brukeren til den riktige servicerepresentanten

Operatormønster: Bygger på Greeter for å rute forespørsler til den riktige spesialiserte AI-agenten eller servicerepresentanten, og forhandle hensikt hvis det er nødvendig

Orkestrator mønster: Behandler en AI-agent-sversjon. Den mottar en brukerforespørsel, bestemmer hensikt, oppretter en plan, overfører nødvendige data til én eller flere spesialistagenter, og samler deretter svarene for brukeren. Til forskjell fra Operator forblir den det første kontaktpunktet.

Problem

Kundene dine bruker stort sett e-postbaserte asynkrone samtaler, og dette er fremdeles den beste måten å utvide kontakten på. Organisasjonen må nå disse kundene via e-post, men salgsutviklingsrepresentantene kan ikke svare på innkommende e-postmeldinger i tjenestenivåavtalen, noe som fører til tap av salgsemner. I tillegg bruker arbeidsstyrken tid på ukvalifiserte salgsemner.

Context

• Organisasjonen har e-post som primær salgsemneengasjementskanal.
• SDR-er har begrenset kapasitet til å kvalifisere salgsemner i stor skala.
• Salgsprosessen din har multitouch-salgsemneoppfølging før de møtes med SDR-er eller forretningsutviklingsrepresentanter (BDR-er).
• Organisasjonen må utvide service og salg med agenter som
  • Hente fra sanntids aktivering av salg og salgsprodukt- og markedsføringsdata
  • Respekter vagter og overholdelse
  • Planlegge møter basert på salgsemnekvalifikasjonskriterier

Nøkkelkomponenter

• E-postkanal: Håndterer registrering af indgående meddelelser, analyserer deres indhold og vedhæftninger og vedligeholder trådkontinuitet for at aktivere asynkrone samtaler.
• Agentforce SDR Agent: Agentenes virkemåte og formål defineres av følgende komponenter.
  • Emner og instruksjoner: Definerer agentens oppgave å engasjere og kvalifisere innkommende salgsemner via samtale. Dette inkluderer instruksjoner for å forstå prospektbehov, samle viktige kvalifikasjonsdata (for eksempel budsjett, myndighet og tidslinje) og lede samtalen mot et klart neste trinn, som å planlegge et møte med en kundeansvarlig.
  • Handlinger: Spesialiserte salgshandlinger som gir agenten mulighet til å behandle livssyklusen for salgsemner. Disse verktøyene er utformet for å utføre kjerne-SDR-oppgaver, som å berike salgsemnedata, sende malbaserte oppfølgingsmeldinger eller integrere med kalendersystemer for å bestille oppdagelsessamtaler.
  • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
  • Meldingsmaler: Gjenbrukbare maler som fylles ut dynamisk med direkte CRM-data via flettefelt eller semantiske data fra Data 360 RAG Retrievers. Disse malene gir agenter mulighet til å generere kontekstuelt innhold med merkeprofilering, mens Einstein Trust Layer sikkert maskerer sensitiv informasjon før instruksjonene sendes til LLM.
• Data 360
  • Data 360-komponenter, inkludert DLO-er, DMO-er, vektorbutikk og RAG-henteverktøy, gir agenten en forent oversikt over alle relevante bedriftsdata, fra strukturerte kundeposter til ustrukturerte Knowledge, slik at svarene er nøyaktige og kontekstuelt grunnlagde.
• Sales Cloud
  • CRM data: Kobler agenten til den fullstendige sakshistorikken og gir viktig kontekst for kontodetaljer, kontaktposter og berettigelser
  • Planlegge møte mellom kunde og SDR: SDR Live Agent-overføring kan konfigureres til å konfigurere et direktemøte ved bruk av Oppgave- og Møteplanlegging (neste handlinger).
  • Aktivitetslogging: Registrer begivenheder, opgaver og mailaktiviteter, og relater dem til emner, konti og salgsmuligheder som resultat af SDR-agentinteraktioner.

Interaksjoner

1. Kunden sender og mottar e-post via kanalen, som ruter til Agentforce.
2. Agentforce bruker emner, handlinger og vakter til å analysere hensikt.
3. Agentforce utformer kontekstuelle svar ved bruk av ledetekstmaler beriket med CRM og Data 360-kontekst.
4. En e-postdiskusjon med flere omgange fortsetter til løsningen eller retningslinjene gjelder.
5. For kvalifiserte salgsemner planlegger Agentforce et møte og oppdaterer CRM.
6. Hvis hensikten overskrider AI-omfanget, eskalerer Agentforce til Sales Cloud SDR for et svar fra servicerepresentanten.

Trade-Offs

Relatert mønster

Ansvar Bot mønster: Et effektivt mønster for selvbetjening som bruker generativ AI til å forstå naturlig språk for henting av Knowledge, og ikke bare nøkkelord

Samtaleagentene i den forrige delen er fremragende når de reagerer på brukerkommandoer, mens proaktive agenter representerer et paradigmeskift: De handler uten å bli bedt om det. Denne delen inneholder arkitektoniske mønstre for byggeagenter som automatisk overvåker data og hendelser fra både utenfor og innenfor Salesforce.

Problem

Organisasjonen genererer viktige forretningshendelser innenfor og utenfor Salesforce. Det er vanskelig å oversette dem til tidsriktig konteksthandling fordi de er fordelt på tvers av programmer og avdelinger.

Context

• Forretningsprosessene spenner over flere systemer for CRM, betalingsbehandling, forsendelse, markedsføringsautomatisering, telemetri og CDP.
• Organisasjonshendelsene dine skjer 24/7, men tilgjengeligheten av arbeidsstyrken din er begrenset utenfor åpningstidene. Systemer er alltid på, men mennesker er ikke det.
• Hendelsene mangler kontekstbevissthet – de mangler kundekontekst tilgjengelig i Salesforce, noe som tvinger sammenføying av informasjon med flere trinn. I dag finnes implementering enten som diskret kompleks automatisering eller utføres manuelt.
• Mennesker fungerer som en kompilator for å samle dataene (i forskjellige formater) og reagere intelligent på uløste hendelser.
• Målhandlingene brukes på flere systemer.

Nøkkelkomponenter

• Event source
  • Datahandling utløste hendelser etter at eksterne data har blitt hentet inn i Data 360
  • Tredjeparts eller Salesforce Heroku MCP-servere som kan sende hendelser til Salesforce via Salesforce Pub/Sub API
  • Eksternt program som kan sende hendelsesvarsler via Salesforce Pub/Sub API
• Valgfritt mellomprodukt: MuleSoft eller Data 360 for transformasjoner
• Agentforce Agent: Agentenes virkemåte og formål defineres av følgende komponenter.
  • Emner og instruksjoner: Angir agentens kjerneoppgave og dens utløsere, inkludert å definere dets primære mål (for eksempel Overvåke alle saker med høy prioritet og hindre SLA-brudd). Inneholder de spesifikke hendelsene eller datatilstandene som agenten skal lytte etter for å starte oppgavene sine
  • Handlinger: Hendelsesutløste og planlagte handlinger utformet for å svare på eksterne hendelser. Selv om disse handlingene opererer automatisk for rutinemessige oppgaver, inkluderer de ofte muligheten til å orkestrere arbeidsflyter som involverer menneskelig intervensjon, og eskalere til brukere for gjennomgang, godkjenning eller håndtering av scenarier som krever menneskelig vurdering.
  • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
  • Meldingsmaler: Gjenbrukbare maler som fylles ut dynamisk med direkte CRM-data via flettefelt eller semantiske data fra Data 360 RAG Retrievers. Disse malene gir agenter mulighet til å generere kontekstuelt innhold med merkeprofilering, mens Einstein Trust Layer sikkert maskerer sensitiv informasjon før instruksjonene sendes til LLM.
• Data 360
  • Data 360-komponenter, inkludert DLO-er og DMO-er, som lagrer hendelsesdata generert av eksterne systemer og sendt til salesforce, for å transformere og bygge strømming eller sanntidsinnsikt
  • Beregnede, strømmede og sanntidsinformasjon gir agenter umiddelbare, relevante data om kunder. Dette aktiverer preemptiv problemløsning og reduserer eskalering. Datagrafer viser proaktivt relasjoner og innsikt fra forskjellige datakilder, slik at det kan oppdages mønstre eller avvik som er relevante for kundeengasjementet, aktiviteten og profilen.
  • Data 360 vektorlagring og RAG retriever gir agenten en forent visning av alle relevante bedriftsdata og ustrukturerte Knowledge artikler, og sikrer at svarene er nøyaktige og kontekstuelt grunnlag.
• Event targets
  • Varsle ansatte proaktivt eller ta kontakt med kunder
  • Kan utvides til agenter (se mønstre for Ambient Agent og Autonomous Agent)

Interaksjoner

1. Det skjer en merkbar endring i det eksterne systemet.
2. Det eksterne systemet sender en hendelse og publiserer den til Salesforce Event Bus via API (oppretter en plattformhendelse) eller Pub/Sub API, eller Hendelsesdata strømmes til Data 360.
3. Abonnenter på hendelsen utløses. Det utløses en flyt.
4. Flyten kaller opp Agenthandling med hendelsesdataene. Agenten bestemmer riktig handling og utfører den.
5. Utfallet er et varsel eller en arbeidsflyt som utløses. Varsler leveres til en bruker i et samarbeidsverktøy (som Slack). Oppgaver eller hendelser genereres også. Handlinger kan også kalle opp eksterne systemer. Hendelsene går derfor ikke tapt, men blir proaktivt utført, signalisert og handlet, noe som fjerner menneskelig overhead eller kompleks automatisering for å oppdage dem.

Trade-Offs

Relatert mønster

Dommer & jury mønster: Kan brukes sammen med dette mønsteret for å sikre nøyaktigheten og påliteligheten av AI-drevne beslutninger ved å benytte flere "juror"-agenter og en "judge"-agent for kongruensvurdering

Modell av modeller mønster: Dette mønsteret omfavner ulike synspunkter fra flere ekspertagenter for å generere rikere innsikt, som kan supplere den proaktive AI-ens intelligente svar.

Problem

Organisasjonens Salesforce-økosystem genererer en konstant strøm av signaler, men har problemer med å oversette dem til tidsriktig konteksthandling, fordi de krever forretningslogikk, styring og brukere til å sortere og handle. Mange ganger mistes signalene uten noen handling som fører til tapt salgsmulighet.

Context

• Organisasjonen bruker én eller flere Salesforce-skyer: Salg, Service, Markedsføring, Commerce, Health, Manufacturing og andre.
• Du trenger intelligent sortering utover enkel ruting eller regelbasert sortering. Organisasjonen vedlikeholder hundrevis av komplekse forretningsregler.
• Du krever svar i sanntid eller i nær sanntid på hendelser.
• Noen ganger blir de mest privilegerte administratorene de svakeste lenkene i kjeden fordi de ikke ser signalene.

Nøkkelkomponenter

• Event-kildelag
  • CRM-data, plattformhendelser, CDC-data (Change Datafangst) og sanntids hendelsesovervåking (RTEM) data fra lavt nivå plattformaktivitet
• Data 360
  • Data 360-komponenter, inkludert DLO-er og DMO-er, som lagrer hendelsesdata generert av CRM- eller plattformhendelser, for å transformere og bygge strømming eller sanntidsinnsikt
  • Beregnede, strømmede og sanntidsinnsikter gir agenter umiddelbare, relevante data om kundens, ansattes aktivitet eller metadataendringer i systemet. Dette aktiverer preemptiv problemløsning og reduserer eskalering. Denne sanntids situasjonsbevisstheten gir agenter mulighet til å levere tidsriktige intervensjoner for styring og driftsomfattende overholdelse.
  • Datagrafer viser proaktivt relasjoner og innsikt fra forskjellige datakilder, slik at det kan oppdages mønstre eller avvik som er relevante for kundeengasjementet, aktiviteten og profilen.
  • Data 360 vektorlagring og RAG retriever gir agenten en forent visning av alle relevante bedriftsdata og ustrukturerte Knowledge artikler, og sikrer at svarene er nøyaktige og kontekstuelt grunnlag.
• Agentforce Agent: Agentenes virkemåte og formål defineres av følgende komponenter.
  • Emner og instruksjoner: Angir agentens oppgave å håndheve forretningsregler og automatisere prosesser basert på dataendringer i Salesforce. Den definerer agentens mål (for eksempel "Se til at alle salgsmuligheter oppdateres med en primærkontakt før forhandlingsfasen nås") og de spesifikke postopprettelsene, feltoppdateringene og så videre som utløser agenten.
  • Handlinger: Hendelsesutløste og planlagte handlinger utformet for å svare på interne Salesforce-hendelser. Selv om disse handlingene opererer automatisk for rutinemessige oppgaver, inkluderer de ofte muligheten til å orkestrere arbeidsflyter som involverer menneskelig intervensjon, og eskalere til brukere for gjennomgang, godkjenning eller håndtering av scenarier som krever menneskelig vurdering.
  • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
  • Meldingsmaler: Gjenbrukbare maler som fylles ut dynamisk med direkte CRM-data via flettefelt eller semantiske data fra Data 360 RAG Retrievers. Disse malene gir agenter mulighet til å generere kontekstuelt innhold med merkeprofilering, mens Einstein Trust Layer sikkert maskerer sensitiv informasjon før instruksjonene sendes til LLM.
• Event targets
  • Varsle ansatte proaktivt eller kontakt kunder.
  • Kan utvides for å kalle opp andre agenter (se mønstre for ambient AI og autonom AI)

Interaksjoner

1. En merkbar endring skjer i det interne systemet, som en oppdatering av en CRM-post, en metadataendring eller en datahandling utløst fra Data 360.
2. Det interne systemet sender en hendelse og publiserer den til Salesforce Event Bus via API (oppretter en plattformhendelse) eller Pub/Sub API, eller hendelsesdata strømmes til Data 360.
3. Abonnenter på hendelsen utløses og aktiverer en flyt eller Apex.
4. Den aktiverte flyten eller Apex kaller opp Agenthandling.
5. Utfallet er et varsel eller en arbeidsflyt som utløses. Varsler leveres til en bruker i et samarbeidsverktøy (som Slack). Oppgaver eller hendelser genereres også. Handlinger kan også kalle opp eksterne systemer.
6. Hendelsene går derfor ikke tapt, men blir proaktivt utført, signalisert og handlet, noe som fjerner menneskelig overhead eller kompleks automatisering for å oppdage dem.

Trade-Offs

Relatert mønster

Listener/Feed mønster: Kan kombineres med Listener-mønsteret for å utløse proaktive handlinger basert på interne Salesforce-hendelser

Data Steward-mønster: Proaktiv AI kan bruke datastyring til å sikre datakvalitet og konsistens når de svarer på interne hendelser

Zen Data Gardener mønster: For planlagt proaktiv dataklargjøring og standardisering utløst av interne hendelser eller med regelmessige intervaller

Vi startet med agenter som svarer interaktivt i en diskusjonskanal, og deretter fortsatte vi til agenter som reagerer på bestemte hendelser. Når du går utover den hendelsesdrevne modellen med proaktive agenter, representerer miljøagenter et paradigmeskift fra direkte interaksjon til proaktiv, bakgrunnsassistanse. Dette er hodeløse agenter som observerer det digitale miljøet i bakgrunnen. De fungerer som systemets "øyne og ører", oppfatter kontekst fra brukeraktivitet eller datastrømmer og koordinerer deretter med andre agenter eller personer for å utføre oppgaver, vise innsikt eller gi veiledning.

Problem

Organisasjonens forretningsaktiviteter genererer kontinuerlige strømmer av verdifull informasjon (samtaler, møter, chatter, sensordata og mer), men disse dataene forsvinner i sanntid uten oppfanging eller analyse. Når mennesker manuelt dokumenterer disse interaksjonene, mistes viktig innsikt, og øyeblikket for rettidig intervensjon er forbi. Organisasjoner mangler mesteparten av den handlingsorienterte intelligensen nødvendig i sanntid og begravet i midlertidige strømmer, noe som fører til hull, tapte coachingmuligheter og beslutninger tatt uten fullstendig kontekst.

Context

• Dine forretningsaktiviteter genererer kontinuerlige strømmer fra forskjellige kilder, inkludert talesamtaler og videosamtaler, direktesamtaler, sensortelemetri, skjermaktivitet og transaksjonsdata.
• Du trenger innsikt i sanntid eller nær sanntid (innen sekunder eller minutter, og ikke timer eller dager) for å reagere effektivt på og handle på disse strømmene.
• Manuelle dokumentasjonsprosesser mislykkes, som kjennetegnes av lave overholdelses- og oppdateringsfrekvenser, høy kognitiv belastning på ansatte og ufullstendig fangst av viktig informasjon.
• Du trenger en flermodal forståelse som kombinerer data fra lyd, video, skjermdeling, chat og andre metadata for å opprette en fullstendig og nøyaktig kontekst for interaksjoner og hendelser.
• Du trenger både umiddelbare analyser for veiledning i sanntid og varsler og historiske analyser for sammendrag etter interaksjon og identifisering av langsiktige trender.
• Tidskontekst (episodisk minne) er avgjørende for analysen, inkludert å forstå sekvensen, tidspunktet, overgangene og mønstrene på tvers av ulike tidsvinduer i datastrømmene.

Nøkkelkomponenter

• Strømkilde
  • Voice og video: Videokonferanseverktøy (som Slack Huddle, Zoom, Google Meet og Microsoft Teams) og telefonsystemer
  • Samarbeidsverktøy: Slack, Team og andre
• Strømfangstkoblinger
  • Innebygd SDK: Leverandørleverte SDK som bidrar til å hente avskrifter eller meldinger som støtter strømsegmenter eller avskrifter i sanntid
• (Valgfritt) Strømbehandlingslag
  • For lydstrømmer, en tale-til-tekst-funksjonalitet som oversetter lyd til tekst, hvis avskrifter ikke er tilgjengelig i sanntid. Du kan også bruke en administrert leverandør som Amazon Transcribe.
  • For andre datastrømmer, eventuelt en strømbehandlingsmotor som Data 360 eller Apache Flink
• Data 360
  • Data 360-komponenter, inkludert DLO-er og DMO-er, som lagrer hendelsesdata, transformerer og bygger strømming eller sanntidsinnsikt
  • Beregnede, strømmede og sanntidsinnsikt gir agenter umiddelbare, relevante data om kunder, deres aktivitet og kritisk innsikt. Dette aktiverer preemptiv problemløsning og reduserer eskalering. Denne sanntidssituasjonsbevisstheten gir agenter mulighet til å levere tidsriktige intervensjoner og personlig støtte til ansatte, og dermed optimalisere kundetilfredshet og driftsomsetning.
  • Data 360-komponenter, inkludert DLO-er og DMO-er, som lagrer kundedata, transformerer og bygger sanntidsinnsikt
  • Data 360 vektorlagring og RAG retriever gir agenten en forent visning av alle relevante bedriftsdata og ustrukturerte Knowledge artikler, og sikrer at svarene er nøyaktige og kontekstuelt grunnlag.
• Agentforce Agents. Dette mønsteret fokuserer på en miljøagent som observerer en kontinuerlig datastrøm, som en direktesamtaleavskrift eller en videofeed. Den fungerer som en sanntids lytter og tolker ustrukturerte data slik de skjer. En agent som for eksempel lytter på en direktesamtale, kan kalle opp en Data Discovery-agent for å berike en salgsemnes post basert på ny kontekst som deles i samtalen. Her er et eksempel på en slik headless-agent:
  • Tilbakemeldingsagent. Agentenes virkemåte og formål defineres av følgende komponenter.
    • Emner og instruksjoner: Definerer agentens primære oppgave for å analysere samtalestrømmer og trekke ut strukturerte tilbakemeldinger og ytelsesmålinger. Dette inkluderer instruksjoner for å overvåke kundenes stemning, identifisere omtaler av viktige produkter eller konkurrenter og vurdere om den personlige agenten følger anbefalte fremgangsmåter for firmaet eller en salgspillbok.
    • Handlinger: Handlinger for å transformere ustrukturerte samtaledata til handlingsorienterte forretningsinformasjon. Disse handlingene gir agenten mulighet til å opprette en Tilbakemeldingsoppsummering-post, logge produktfunksjonsforespørsler, flagge samtaler med negativ stemning for ledergjennomgang og oppdatere et kontrollpanel for å spore generell agentytelse mot viktige målinger.
    • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
    • Meldingsmaler: Strukturerte, malbaserte LLM-instruksjoner som kan motta inndata og levere et LLM-generert utdata
• Miljømål
  • Varsle brukere på overflaten der agenten og brukeren er, som i en videosamtale eller et skrivebordsprogram

Interaksjoner

1. Når en strøm aktiveres (som når en bruker slutter seg til videosamtalen), legger agenten ved seg selv som observatør.
2. Agenten begynner å motta strømdata, oppdager hensikter trinnvis, tar beslutninger og kaller opp handlinger.
3. Agenten kontekstualiserer basert på hensikt og henter flere data (strukturert eller ustrukturert).
4. Agenten leverer sanntids-svar i rett tid uten brukermeldinger: den kan oppdage en invitasjon i et salgssamtale og gi viktig informasjon for å håndtere invitasjonen.
5. Agenter kan kompilere et samlet sammendrag og handlinger og dele dem med andre agenter og brukere.

Trade-Offs

Relatert mønster

Listener/Feed mønster: Kan kombineres med Listener-mønsteret for å behandle sanntidsstrømmer med samtale- og brukerinteraksjonsdata og vise relevant kontekst og innsikt

Interrogator mønster: Kan brukes sammen med dette mønsteret til å sette sammen kontekst fra flere kilder i strømmen og svare på spørsmål

Problem

De ansatte utfører hundrevis av forretningskritiske aktiviteter daglig på tvers av e-post, kalender, samtaler og programmer, men disse aktivitetene forblir usynlige for organisasjonssystemer før de logges manuelt – noe som sjelden skjer. Denne aktivitetsblindheten betyr at CRM-data er ufullstendige, AI-modeller mangler signalene som er nødvendige for intelligente anbefalinger, og ledere har ingen sanntids synlighet av kundeengasjement. Manuell aktivitetslogging oppretter en produktivitetsavgift mens det fremdeles mangler det meste av det faktiske arbeidet.

Context

På samme måte som strømobservatøren er dette en data- og innholdsobservatør som tilbyr handlingsoppgaver eller utfører handlinger på vegne av brukeren.

Nøkkelkomponenter

• Datalag
  • CRM data: Kundedata som er tilgjengelig i CRM og som gir kontekst til agenten (for eksempel når brukeren er på en salgsmulighetsside, kan agenten hente informasjon om salgsmuligheten og den tilknyttede kontoen fra CRM).
  • Data 360-komponenter, inkludert DLO-er og DMO-er, som lagrer relevante kundedata hentet inn fra forskjellige kilder
  • Beregnede, strømmede og sanntidsinnsikt gir agenter umiddelbare, relevante data om kunder, deres aktivitet og kritisk innsikt. Dette aktiverer preemptiv problemløsning og reduserer eskalering.
  • Data 360 vektorlagring og RAG retriever gir agenten en forent visning av alle relevante bedriftsdata og ustrukturert Knowledge.
• Agentforce Agent: Dette mønsteret fokuserer på en miljøagent som observerer en brukers handlinger direkte i brukergrensesnittet. Den fungerer som en sanntidsassistent som forstår konteksten til brukerens arbeidsflyt for å gi veiledning. En agent kan for eksempel overvåke at en servicerepresentant fyller ut en sakspost og proaktivt viser en relevant Knowledge. Her er et eksempel på en slik headless-agent:
  • Tilbakemeldingsagent. Agentenes virkemåte og formål defineres av følgende komponenter.
    • Emner og instruksjoner: Definerer agentens oppgave å overvåke en brukers handlinger i grensesnittet og gi kontekstuell assistanse. Dette inkluderer målet (for eksempel "veilede en servicerepresentant gjennom saksløsningsprosessen") og de spesifikke brukergrensesnitthendelsene eller dataregistreringsmønstrene den bør se etter for å proaktivt tilby hjelp.
    • Handlinger: Handlinger, bygget med Apex eller Flyt, for å vise relevant informasjon og neste beste handlinger direkte i brukerens arbeidsflyt. Disse handlingene gir agenten mulighet til å hente og vise en relevant Knowledge, foreslå et gyldig neste trinn i en prosess eller flagge et dataoppføringsfelt som kan bryte en forretningsregel, alt som svar på brukerens sanntidsaktivitet.
    • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
    • Meldingsmaler: Gjenbrukbare maler som fylles ut dynamisk med direkte CRM-data via flettefelt eller semantiske data fra Data 360 RAG Retrievers. Disse malene gir agenter mulighet til å generere kontekstuelt innhold med merkeprofilering, mens Einstein Trust Layer sikkert maskerer sensitiv informasjon før instruksjonene sendes til LLM.
• Miljømål
  • Varsle brukere på overflaten der agenten og brukeren er, som på en nettside eller på en administratorside

Interaksjoner

1. Når en bruker besøker en side eller app, legger agenten ved seg selv som observatør.
2. Agenten begynner å inspisere data og handlinger, oppdager hensikter trinnvis, tar beslutninger og kaller opp handlinger.
3. Agenten kontekstualiserer basert på hensikt og henter flere data (strukturert eller ustrukturert).
4. Agenten leverer sanntids-svar i rett tid uten brukermeldinger, og kan foreslå neste beste handling eller tilby å utføre dem på vegne av brukeren.
5. Agenter kan enkelt dele dette med andre agenter og brukere.

Trade-Offs

Relatert mønster

Listener/Feed mønster: Kan kombineres med Listener-mønsteret for å utløse proaktive handlinger basert på observert aktivitet

Data Steward-mønster: Aktivitetsoppfanging-AI kan bruke datastyring til å sikre datakvalitet og konsistens ved logging av oppfangede aktiviteter.

Generatormønster: Kan brukes til å automatisk generere aktivitetsoppsummeringer eller oppfølgingsoppgaver basert på oppfangede aktiviteter

Denne delen beskriver mønstre for samarbeidspartnere, der én eller flere agenter samarbeider med en bruker for å oppnå et felles mål. Disse oppskriftene fokuserer på å opprette et sømløst partnerskap: Agenter håndterer kompleks datainnsamling og utførelse av oppgaver, mens de holder mennesket oppdatert for beslutninger, godkjenninger og strategisk veiledning.

I denne modellen håndterer agenter de automatiserbare delene av en arbeidsflyt. Prosessen blir til en dynamisk tilbakemeldingsløyfe.

• En person kan starte en oppgave via en Samtaleagent, som utløser en proaktiv agent for å behandle serverdeltrinnene.
• Samtidig kan en miljøagent observere sine handlinger for å gi sanntids veiledning.

Denne prosessen oppretter en sømløs sammenslåing av menneskelig og digitalt arbeid. Dette mønsteret viser hvordan Agentforce gjør det enklere å håndtere komplekse jobber som ingen enkelt agent – eller menneske – kan håndtere alene.

Problem

Forretningsprosessene krever samarbeid mellom arbeidere fra forskjellige organisasjoner – både interne og eksterne – hver med forskjellige jobber å utføre som involverer forskjellige kvalifikasjoner og prioritet. Prosessflaskehalser kan skje når som helst og hvor som helst på grunn av ressurskapasitet, kvalifikasjonsbegrensninger eller på grunn av mengden informasjon som utveksles.

Context

• Prosesser spenner over team og krever at flere teammedlemmer samarbeider for å få et vellykket utfall.
• Agentassistenter hjelper allerede arbeidsstyrken i én-til-én-scenarier som samtaleagenter, proaktive agenter og miljøagenter.
• Prosesser bruker agenter i de riktige segmentene av forretningsprosessene. Prosesser trenger imidlertid også samarbeid mellom person og agent. Dette samarbeidet kan involvere samarbeid mellom personer med assistanse fra agenter eller samarbeid mellom personer og agenter.
• Kvalifikasjonshull fylles ut av agenter.
• Agenter bidrar til å forbedre samarbeidet ved å redusere menneskelig innsats i oppgaver som oppfølging og utveksling av viktig informasjon for å bidra til beslutningsprosesser.
• Agenter kan også samarbeide og delegere basert på policyer og retningslinjer.

Nøkkelkomponenter

• Samarbeidsflate
  Agentisk samarbeid krever et felles område der alle deltakere, både mennesker og agenter, kan samhandle. Disse samarbeidsoverflatene er ikke lenger statiske, bare menneskelige miljøer. I stedet er de kanaler der agenter kan inviteres til å delta, bidra og også starte diskusjoner, noe som fundamentalt endrer typen teamarbeid. En agent kan for eksempel opprette og starte en sakssversjon i Slack ved å invitere eksperter og andre agenter til å samarbeide om saken.

• Agentforce Agents
  Dette mønsteret går utover individuelle agentmønstre for å demonstrere hvordan de konvergerer i en Samarbeidsagent-modell og orkestrerer komplekse prosesser som intelligent utvider menneskelige muligheter. De foregående mønstrene – Conversational (2.1), Proactive (2.2) og Ambient (2.3) – definerer Agentforce Agent components.c-retningen. En samtaleagent fungerer som det primære grensesnittet, arbeider sammen med mennesket og fungerer som grensesnittet mellom mennesker og alle agenter som er involvert i samarbeidet. Når en oppgave er for mangesidig, starter samtaleagenten en samarbeidsøkt som samler brukerne og de nødvendige hodeløse agentene for å arbeide med problemet samtidig. Prosessen blir en dynamisk tilbakemeldingsløyfe der en person kan starte en oppgave, som deretter utløser en Proaktiv agent for å administrere serverdeltrinnene, mens en Omgivelsesagent kan observere for å gi veiledning i sanntid, og skape en sømløs sammenslåing av menneskelig og digitalt arbeid.

• Datalag
  I den samarbeidende agentmodellen tjener datalaget en mer dynamisk rolle enn bare å gi informasjon. Det blir det faste minnet og det delte arbeidsområdet for hele teamet for agent-person. Hver agent som er involvert, har sine egne spesifikke databehov, som definert i sitt respektive mønster, men deres samarbeid om en kompleks oppgave avhenger av et delt datamessig grunnlag som sporer tilstanden til den generelle jobben.

  Denne delte tilstanden er avgjørende. Når en oppgave overføres fra en samtaleagent til en proaktiv agent og deretter til en person for godkjenning, må datalaget spore fremdriften, konteksten og beslutningene som tas i hvert trinn. Dette sikrer at alle deltakere har en konsistent og oppdatert visning av episoden.

Interaksjoner

1. Personer starter en samarbeidsøkt med andre personer og agenter.
2. Kontekst, mål, jobber og utfall er definert.
3. Agenten beriker konteksten ved å hente inn mer informasjon og proaktivt planlegge trinnene som kreves for å fullføre jobben, sammen med eiere som er mennesker eller agenter.
4. Fremdrift observeres, kontekst oppdateres og handlinger utføres.
5. Der agenter utfører jobben, gir agenten detaljert informasjon for å hjelpe interessenter med å forstå resonnement, gi tilbakemeldinger og tillate oppfanginger.
6. Agenter utfører arbeidet med full gjennomsiktighet og samsvar.

Trade-Offs

Relatert mønster

Operatormønster: Samarbeidsagenter fungerer ofte som operatorer, ruter forespørsler til de riktige spesialiserte AI-agentene eller servicerepresentanter og forhandler hensikt.

Orkestrator mønster: I scenarier som involverer samarbeid, behandler en orkestreringsagent en strøm av AI-agenter og samler svarene deres for å gi en sømløs brukeropplevelse.

Arbeidsområde (Radar O'Reilly) mønster: Samarbeid agenter bruker dette mønsteret til å behandle et responsivt, enkeltglass-grensesnitt som oppdaterer relevant innhold i sanntid i en samtaleflyt.

I motsetning til samarbeidsmønstre som hjelper en bruker, er autonome agenter utformet for full delegering. Denne delen inneholder de arkitektoniske planene for agenter som uavhengig kan planlegge og utføre komplekse, flertrinns oppgaver for å oppnå et mål på høyt nivå uten å kreve menneskelig intervensjon. Fokuset her er på å skape et system du kan oppnå med et mål og Trust for å gjennomføre det fra start til slutt.

Problem

Organisasjonen realiserer verdi gjennom et svært komplekst sett prosesser, hver med distinkte policydrevne jobber, spillelister og spesifikke kvalifikasjoner som er nødvendige for utførelse. Dette er ofte programmer som krever betydelig investering av tid og ressurser.

Konfigurering av et nytt program har høye kostnader og kan ta måneder før det realiseres verdi. Implementering av tilbakemeldinger og forbedringer krever ofte ekstra tid og innsats. Kompleksitet drives primært av organisasjonens struktur, der distribuerte programmer og prosesser kan føre til avhengigheter som krever at personer administrerer programmet.

Context

• Agenter kan operere uavhengig fra start til slutt. Agenter utformes og konfigureres slik at mål, plan og strategi er forhåndsdefinert.
• Agenter kan ta alle beslutninger uten å søke godkjenning fra mennesker. Agenter får policy- og samsvarsretningslinjer.
• Agenter får tilgang til den nødvendige konteksten og dataene de trenger, og de kan utføre nødvendige handlinger uten å måtte bruke brukere.
• Personer varsles, men er ikke "i sløyfen".

Nøkkelkomponenter

• Mål- og strategidefinisjonslag
  • Process playbooks: Detaljerte beskrivelser av automatisk utførelse med deterministiske regler som agenter må følge
  • Autonomt beslutningskriterier: Regler som gir agenter mulighet til å ta beslutninger uten å kreve godkjenning fra personer
  • Fallback-regler: Forhåndsdefinerte handlinger for håndtering av standard- eller unntaksscenarier når en agents primære prosess mislykkes
  • Scopes: Tydelige grenser som skisserer hva agenter kan og ikke kan gjøre, inkludert hvordan situasjoner utenfor omfang må håndteres
  • Suksesskriterier og definisjon av utført: Målingene og betingelsene som bestemmer når en agents oppgave fullføres
• Agentforce Agents
  • Agentorkestrator eller koreograf: Hovedagenten som eier målet, årsakene og planleggingen
    • Emner og instruksjoner: Når et mål er definert, tar orkestrer- eller koreografagenten ledelsen for å dele opp det overordnede målet i mindre, administrerbare jobber eller deloppgaver. Den utformer en omfattende plan som skisserer sekvensen av jobber og identifiserer de spesifikke agentene eller verktøyene som kreves for hvert trinn. Til slutt sikrer orkestreragenten en sømløs utførelse av planen, overvåker fremdriften, behandler avhengigheter og foretar justeringer etter behov for å oppnå målet effektivt og effektivt. I tilfellet med en koreografagent overfører den konteksten og statusen til nedstrømsagentene for å føre jobben gjennom til fullføring.
    • Handlinger: Handlinger kaller opp verktøy for å utføre en funksjon, hente data eller delegere til andre hodeløse agenter, noe som aktiverer et bredere spekter av funksjoner og mer komplekse arbeidsflyter.
    • Vakter: Vakter fungerer som et sett konfigurerbare regler og kjøretidskontroller som begrenser agentens virkemåte. Fungerer som et sikkerhetslag som kan fange opp ledetekster, validere agentens foreslåtte handlinger og filtrere den endelige responsen for å hindre skadelig innhold, håndheve forretningsregler og sikre at agenten opererer innenfor det utpekte omfanget.
• Datalag
  • CRM Data: kundedata som er tilgjengelig i CRM og gir kontekst til én eller flere agenter
  • Data 360-komponenter, inkludert DLO-er og DMO-er, som lagrer relevante kundedata hentet inn fra forskjellige kilder
  • Beregnede, strømmede og sanntidsinnsikt gir agenter umiddelbare, relevante data om kunder, deres aktivitet og kritisk innsikt. Dette aktiverer preemptiv problemløsning (som håndtering av e-postmeldinger som kommer tilbake), som reduserer eskalering.
  • Data 360 vektorlagring og RAG retriever gir agenten en forent oversikt over alle relevante bedriftsdata og ustrukturert Knowledge
  • Slack-kanalmeldinger eller samtaledata som sakshistorikk og samtalebehandlingshistorikk som gir samtalekontekst
• Overvåking og tilsyn
  • Agentmålfremdriftsovervåking: Sporer fremdriften for autonome agentøkter for å måle utfall og sikre justering med mål
  • Overvåking av agentdrift: Sporer sanntidsstatusen til autonome agenter for intervensjon og feilsøking for å sikre problemfri drift
  • Agentstyringsovervåking: Sporer sporings- og revisjonslogger for å sikre at autonome agenter overholder forhåndsdefinerte mål, mål og etiske retningslinjer

Interaksjoner

1. Jobben defineres med tydelige utfall.
2. Jobben startes via en av følgende metoder:
   • En agent blir oppgitt.
   • En agent tar proaktivt opp jobben basert på kvalifikasjoner.
   • En agent utfører jobben i bakgrunnen.
3. Agenten fastsetter tydelig forventninger og informerer personer, detaljert mål, plan og strategi. Planen beskriver trinnvise prosesser, brukte agenter, brukte data, omfang, agentvurderingsplan og sjekkpunkter for brukere for å overvåke fremdrift, drift og styring.
4. Agenten begynner utførelsen. Ved hver milepæl oppdateres statusen og fremdriften. Personer har mulighet til å gi tilbakemeldinger eller fange opp agentene etter behov.
5. Agenten fullfører jobben. Utfallet og resultatene er tilgjengelig i kontrollpanelet for overvåking.

Trade-Offs

Relatert mønster

Prosjektledermønster: Autonome agenter innebærer ofte dette mønsteret og overvåker langvarige, flertrinns prosesser fra initiering til fullføring med minimalt med menneskelig intervensjon.

Konfigurasjonsmønster: Autonome agenter kan bruke dette mønsteret til å automatisk generere og validere konfigurasjoner basert på krav til naturlig språk eller forhåndsdefinerte policyer, slik at overholdelse og nøyaktighet sikres uten manuell oversikt.

Zen Data Gardener mønster: Dette mønsteret kan brukes av autonome agenter til planlagt, bakgrunnsdatastrøm og standardisering, og sikrer datakvalitet og konsistens over tid for å støtte nøyaktig agentbeslutning.

Nå vil vi sette agenttaksonomi og agentmønstre i gang ved å utforske hvordan de implementeres på Salesforce Platform. For de som ikke er kjent med kjerneelementene i Agentforce, gir Tillegget en nyttig oppdatering om de viktigste teknologiene som refereres gjennom hele dette kapitlet og neste.

Denne delen tar taksonomiet for agenter og illustrerer hver av dem med et vanlig bruksområde for å vise hvordan de brukes i virkelige programmer.

En kunde, Jane, besøker et firmas nettsted for å sjekke statusen til hennes nylige bestilling.

• Interaksjon: Jane åpner chattevinduet (Agentforce Chat Client).
• Agenthandling: Samtaleagenten hilser henne og spør hvordan hun kan hjelpe. Jane spør: "Hvor er min siste bestilling?"
• Prosess:
  1. Agenten, som er basert på Jane's kundeinformasjon fra Salesforce, identifiserer hennes siste bestilling.
  2. Den spør forsendelsessystemet (via en MuleSoft-kobling) om den nyeste sporingsinformasjonen, og gir Jane en sanntidsoppdatering og en sporingslenke.
  3. Den slår deretter opp på policyen og oppgraderer automatisk til raskere forsendelse.
  4. Når Jane stiller et komplekst spørsmål agenten ikke kan håndtere, eskalerer den sømløst chatten til en human tjenesteagent, og gir den fullstendige avskriften for kontekst.

Recipe

Brukte mønstre: Samtale-AI-mønster, integrering av transaksjonsdata til agenter

Design Time

1. Konfigurer en samtaleagent.

   Konfigurere forbedret chat	→	Opprett tjenesteagent	→	Definere emne for kundestøttebestillinger	→	Opprett Hent bestilling-handling
   						↓
   Legge til utgående Omnikanal-flyt for eskalering	←	Opprett eskaleringsemne	←	Legge til handlinger i emner	←	Opprett Hent status-handling
   ↓
   Publisere agenten

2. Konfigurer Forbedret chat som Jane chatte inngangspunkt slik at hun kan åpne Agentforce vinduet på nettsiden.
3. Aktiver Agentforce og opprett en tjenesteagent i Agentforce Builder for å håndtere samtaler og utløse tilpassede handlinger.
4. Definer et Kundestøttebestillinger-emne med en beskrivelse og instruksjoner slik at agenten naturlig gjenkjenner "Hvor er min siste bestilling?".
   1. Opprett tilpassede agenthandlinger:
      1. Handlingen Hent siste bestilling for kontakt for å hente Jane's siste bestilling
      2. Få forsendelsesstatus etter bestillings-ID-handling for å hente sporingsinformasjon via MuleSoft
      3. Du kan eventuelt orkestrere begge handlingene i Flyt – hente den siste bestillingen og kalle opp MuleSoft – ved å bruke eksterne tjenestehandlinger.
      4. Legg til begge handlingene i tjenesteagenten i byggeren, koble dem til emnet Bestillinger og sporing og publiser.
5. Definer et Eskalering-emne med en beskrivelse som skal eskaleres til en servicerepresentant.
   • Opprett og aktiver en utgående Omnikanal-flyt.
   • Legg den til på Tilkoblinger-fanen i byggeren for eskalering med en eskaleringsmelding.
6. Konfigurer Omnikanal.

   Konfigurere Omnikanal

   →

   Definer eskaleringsregler i instruksjoner

   →

   angi prioriteter og kapasitet

   →

   Teste og validere

7. Aktiver sømløs eskalering til servicerepresentanter når AI-agenten ikke kan løse spørringen. Konfigurer Omnikanal-ruting for å tildele chatter til servicerepresentanter og overføre hele avskriften for kontekst.
8. Integrer eskaleringslogikk i Agentforce og en eskaleringshandling slik at agenten vet når komplekse saker skal overføres. Behandle rutingsprioriteter og kapasitet via Omnileder.
9. Test hele opplevelsen: Jane åpner chatten, og agenten hilser henne, identifiserer bestillingen hennes, henter forsendelsesdata og eskalerer sømløst når menneskelig intervensjon er nødvendig (se også Aktiver forbedrede hendelseslogger).
10. Konfigurer dataintegrering.

    Tilordne kontekstdata

    →

    Opprette MuleSoft API-legitimasjon

    →

    Registrere ekstern MuleSoft-tjeneste

11. Gjør agenten kjent med Jane's Salesforce-kontekst ved å tilordne kontakt- og bestillingsposter via godkjente chatte- eller pre-chat-skjemaer.
12. Koble Salesforce sikkert til MuleSoft Shipping API ved bruk av eksterne legitimasjoner og navngitte legitimasjoner for godkjenning.
13. Hvis MuleSoft viser en OpenAPI-spesifikasjon, registrerer du den som en ekstern tjeneste slik at Flyt og agenten kan kalle den deklarativt.
14. Konfigurer ustrukturert dataintegrering.
    1. Opprett et nytt databibliotek under Oppsett. Gi den navnet Bestillings- og forsendelsespolicy.
    2. Legg til PDF-filene til polisedokumenter som inneholder forsendelsespoliseunntakene.
    3. I kulissene blir dokumentene automatisk delt, indeksert og gjort klare til bruk.

Agentkjøretidsflyt for prosess

Når agenten er konfigurert og distribuert, skjer følgende sekvens av trinn ved kjøretid.

1. Chatstarter: Jane åpner Agentforce chat (innebygd tjeneste). Økt- og kontaktkontekstinnlasting etter at Jane er logget på.

2. Hilsning og hensikt: Agenten hilser på Jane. Jane spør om statusen til en bestilling, og hensiktsdeteksjon tilordner "siste bestilling" til emnet Bestillinger og sporing.

3. CRM-oppslag: Agenten utløser handlingen Hent siste bestilling og spør Salesforce (bestillingsoppsummering/bestillinger) om Jane siste post.

4. Sendingsspørring: Agenten kaller opp MuleSoft API via en navngitt legitimasjon, og /shipping/status/{orderId} returnerer en sanntidsstatus og en sporings-URL-adresse.

5. Svarsammensetning: Agentforce fletter resultater og lager et svar: "Bestillingen [OrderID] sendes via [Carrier], ankommer i morgen – [Track Here]."

6. Fallbacks: Hvis det ikke er noe samsvar eller en API-feil, ber agenten om unnskyldning og tilbyr å prøve på nytt for å løse eventuelle dataproblemer.

7. Eskalering: Komplekse eller følelsesmessige spørringer overføres automatisk til en person via Omnikanal og overfører hele chatten og konteksten.

8. Logge: Alle hensikter, handlinger og utfall lagres i interaksjonslogger. API-latens overvåkes i Anypoint Monitoring.

9. Kontinuerlig forbedring: Eskaleringer gir Agentforce ny opplæring. Vanlige flyter blir forbedret i den etterfølgende utgivelsen.

En kunde med høy verdi, John, har lagt til produkter for over 1000 USD i sin online handlevogn, men fullfører ikke kjøpet innen 60 minutter.

• Utløser: En Salesforce Platform-hendelse, Cart_Abandoned__e, utløses fra e-handelssystemet, som inneholder Johns kontakt-ID og handlevognen.
• Agenthandling: En proaktiv agent som abonnerer på denne hendelsen, kommer umiddelbart i handling.
• Prosess:
  1. Agenten sjekker Johns post i Salesforce og ser at han er en VIP-kunde.
  2. Det oppretter en oppgave med høy prioritet for Johns kontoansvarlige, Sarah, med alle detaljene om den forlatte handlevognen.
  3. Den sender et varsel til Sarah via Slack og ber henne følge opp.
  4. Samtidig registrerer den John i en målrettet Marketing Cloud-reise som sender en påminnelsesmelding med en rabattkode på 10 % for begrenset tid for å oppfordre ham til å fullføre kjøpet.

Recipe

Denne oppskriften beskriver implementeringen av en proaktiv AI-agent på Salesforce Platform for å løse problemer med å forlate handlevogn med høy verdi fra VIP-kunder. Løsningen benytter Salesforce Platform Events, Data 360 for Knowledge retrieval og Agentforce til å orkestrere tidsriktige og intelligente oppfølgingshandlinger, og derved omdanne passive data til aktivt forretningsengasjement.

Design Time

1. Konfigurer en forlatt handlevognhendelse til å utløses når John, en VIP-kunde, forlater handlevognen forlatt.

   Opprett tilpasset Kontakt-felt

   →

   Definere ny plattformhendelse

   1. Opprett en Cart_Abandoned__e plattformhendelse med feltene Kontakt-ID, Handleværdi, Dato for siste oppdatering av handlevogn og Handlevogndetaljer.
   2. Konfigurer abandonment-hendelsen: Bruk Commerce Cloud til å opprette en plattformhendelse for Checkout-hendelsesvarsler. Avbrudd oppdages når Checkout-økten er i en mellomliggende tilstand og økten tidsavbrytes etter en terskel. Hvis e-handelen er et eksternt system, kan du også publisere hendelsen til Salesforce med en av disse metodene: Flyter, Apex, Salesforce API-er eller Pub/Sub API.
   3. I Kontakt-objektet oppretter du et nytt felt, Customer_Tier__c, med valglisteverdiene Standard, Premium og VIP.
2. Konfigurere ustrukturert datainntak i Data 360: Legg til et rabattpolicydokument fra et dokumentoppbevaringssted i Data 360 via Amazon S3.

   Opprette AWS S3-legitimasjon	→	Opprette ny S3-datastrøm	→	Konfigurere og distribuere strøm	→	Opprett søkeindeks
   						↓
   				Funksjonen Teste henting	←	Konfigurere og distribuere indeks

   1. Opprett eksterne legitimasjoner for tilgang til S3: Opprett et nytt sett tilgangsnøkler og hemmeligheter for en IAM-bruker eller et IAM Amazon Resource Name (ARN) for en identitetsleverandør.
   2. Opprett en ny S3-datastrøm: I Datastrømmer-fanen oppretter du datastrømmen Policy Documents Stream, velger S3-kilden, velger PDF-filtypen, angir oppdateringsfrekvensen, tilordner metadatafeltene (filnavn og -størrelse) og distribuerer.
   3. Når datastrømmen er fullført, oppretter du et søkeindeks: Bruk passuttrekking for fordeling, E5-large-v2-innbyggingsmodellen og hybridsøketypen, og distribuer deretter indeksen.
   4. Test den opprettede hentingsfunksjonen.
3. Konfigurer agenten for gjenoppretting av VIP-vogn.

   Opprett agent fra mal	→	Legge til gjenopprettingsemne for VIP-handlevogn	→	Legge til emneinstruksjoner	→	Opprett Slack-varselhandling
   						↓
   Legge til handlinger i emne	←	Opprett handlingen Travel Enrollment	←	Opprett tilbudshandling	←	Opprett gjenopprettingsoppgave for handlevogn

   1. Opprett en agent med Agentforce Ansattagent-malen.
   2. Legg til et nytt emne, Gjenopprette VIP-handlevogn, med beskrivelsen av at denne agenten håndterer opphør av handlevogn med høy verdi for VIP-kunder.
   3. Legg til emneinstruksjoner for å validere VIP-status, kvalifisere handlevognen, varsle kontoansvarlig i Slack, anbefale et rabatttilbud og registrere kunden i e-postreisen for gjenoppretting av handlevogn.
   4. Opprett handlinger og en oppgave.
      • Handlingen Varsel om kontoansvarlig: Sender et proaktivt Slack-varsel
      • Gjenopprette forfalt handlevogn-oppgave, tildelt til lederen med handlevogndetaljer
      • Handlingen Get Discount Offer (Hent tilbud): Analyserer policy og tidligere kjøpshistorikk. Opprett en ledetekstmal med jording, referer til hentingens funksjon i ledetekstmalen, og bruk dataene.
      • Handlingen Registrer deg i gjenopprettingsreise: Registrerer seg i Marketing Cloud-gjenopprettingsreisen via APIen og tar imot alle abonnentdata og e-postmeldingen med tilbud som genereres fra agenten.
   5. Legg til handlingene i emnet.
   6. Opprett en reise for gjenoppretting av VIP-kundevogner med maler i Marketing Cloud, eller opprett en ny reise.
4. Send en plattformhendelse for å kalle opp agenten.

   Opprette hendelsesutløst flyt

   →

   Abonnere på plattformhendelse

   →

   Legg til kallbar handling agent

   →

   Overføre hendelsesdata til agent

   1. Opprett en ny plattformhendelsesutløst flyt, VIP Cart Abandonment Recovery.
   2. Velg Hendelsen forlot handlevogn som flyten skal abonnere på.
   3. Konfigurer en tilpasset agentkallbar handling i Flow Builder, og velg VIP Cart Recovery-agenten. Send forespørselen om å starte en gjenoppretting av en VIP-avbrutt handlevogn for kunden, og send plattformhendelsens last.

Agentkjøretidsflyt for prosess

Når agenten er konfigurert og distribuert, skjer følgende sekvens av trinn ved kjøretid.

1. Oppgivelsesdeteksjon: John legger til $ 1200 i handlevognen sin, og ingen Checkout eller fasefremdrift etter 60 minutter utløser forlatelse.
2. Plattformhendelse: Commerce Cloud publiserer hendelsen Cart_Abandoned__e med Johns kontakt-ID, handlevognverdi på $1.200, dato for endring av handlevogn og andre detaljer.
3. Flytinitialisering: Plattformhendelsen utløser gjenopprettingsflyten for VIP-avbrudd av handlevogn.
4. Ansattagentaktivering: Når flyten kjører, kalles VIP Handlevogngjenoppretting-agenten opp.
5. Emneutførelse: Agenten løser spørsmålet Gjenopprett VIP-vogn og utfører instruksjonene.
6. Oppretting av varsel: Agenten varsler Johns kontoansvarlige Sarah i Slack.
7. Oppretting av oppgave: Agenten oppretter en oppgave for Sarah og gir henne råd om oppfølgingene den vil utføre.
8. Rabattsanalyse: Agenten kjører rabattanalysen ved å kalle opp Data 360-hentefunksjonen for å be om "maksimalt antall tillatte rabatter" basert på handlevognverdien, kundenivået og kjøpshistorikken. I dette tilfellet anbefaler funksjonen et rabatttilbud på 10 %.
9. E-postforberedelse og reiseregistrering: Agenten klargjør en e-postmelding med rabatttilbud og registrerer John i Marketing Cloud-reisen VIP Customer Cart Recovery med den nye handlevognprisen.
10. Logging og tilskriving: John løser inn tilbudet, som oppretter en loggattribusjon og konverteringsmålinger.
11. Feedback analyse: Utfallet analyseres for å bestemme tilbud, tid til gjenoppretting og andre optimaliseringsfaktorer ytterligere.

En selger, David, er engasjert i et oppdagelsessamtale med et nytt prospekt. En intelligent agent overvåker aktivt samtalen i sanntid og gir umiddelbar støtte til David ved å svare på prospektets spørsmål.

Eksempel: Hvis prospektet spør om en bestemt produktspesifikasjon, henter agenten automatisk de relevante detaljene og leverer dem til David via Slack eller en privat melding.

• Utløser: Et prospekt stiller et spørsmål som krever spesifikk produktinformasjon under et oppdagelsessamtale med en selger (David).
• Agenthandling: Miljøagenten analyserer samtalelogger og -meldinger kontinuerlig og identifiserer og henter nødvendig informasjon på en intelligent måte.
• Prosess:
  1. Agenten tolker samtaleavskriften i sanntid.
  2. Den identifiserer automatisk viktige handlingselementer og henter relevant informasjon.
  3. I dette tilfellet henter agenten produktinformasjon direkte fra Salesforce.
  4. Den presenterer deretter automatisk den hentede informasjonen til David via Slack eller en privat melding.

Recipe

Det finnes forutsetninger i denne oppskriften som krever sanntids tale-til-tekst-funksjonalitet, og vi forutsetter at de er tilgjengelige via kommunikasjonsleverandøren. Her er for eksempel en oppskrift for å integrere Zoom-kall.

Forutsetning: Eksempel på sanntidsavskrift av en Zoom-kall:

• Opprett en Zoom-app i Zoom Developer Platform med nødvendige omfang for leseopptak, webhook-sending og møtestrøm. Aktiver nødvendige produktfunksjoner som Realtime Media Streams (RTMS).
• Konfigurer en mellomliggende signalserver (Zoom RTMS-eksempel) som mottar lydstrømmen, videresender den til Amazon Transcribe-tjenesten og henter den avskriftte teksten tilbake. Avskriftene publiseres deretter til Salesforce som en plattformhendelse.

Design Time

1. Konfigurer en Sanntids svaragent for salgssamtale.

   Opprett agent fra mal	→	Legge til Assistent samtale-emne	→	Legge til emneinstruksjoner	→	Opprett avskriftsanalyse-handling
   						↓
   		Legge til handlinger i emne	←	Opprett Slack-innsikt-handling	←	Opprett produktspesifikasjon-handling

   1. Opprett en agent med Agentforce Ansattagent-malen.
   2. Legg til et nytt emne, Assistanssamtale, med beskrivelsen av at denne agenten lytter på direktetopptak, forstår hensikten og hjelper med produktdata.
   3. Legg til emneinstruksjoner for å analysere avskrifter, hente produktspesifikasjoner og sende Slack-meldinger.
   4. Opprett handlinger.
      • Handlingen Analyser samtaleavskrift: Analyserer samtaleavskriftsdataene som mottas i sanntid, og trekker ut viktige spørsmål eller handlinger
      • Handlingen Get Product Spec (Hent produktspesifikasjon): Spør produkt Knowledge
      • Sende Slack-innsikt til den interne brukeren
   5. Legg til handlingene i emnet.
2. Konfigurer et Product Knowledge.

   Opprett nytt databibliotek

   →

   Legge til Knowledge

   →

   Systemgrupper og indekser

   →

   Lokal bibliotek i aksjon

   1. Opprett et nytt databibliotek under Oppsett. Gi den navnet Product Knowledge.
   2. Legg til Knowledge som inneholder produktinformasjonen.
   3. I kulissene blir dokumentene automatisk delt, indeksert og gjort klare til bruk.
   4. Bruk jordingen i handlingen Hent produktspesifikasjon.
3. Publiser sanntidsavskriften til Salesforce via Pub/Sub API.

   Server mottar lydavskrift

   →

   Server publiserer plattformhendelse

   1. Opprett en plattformhendelse, Transcript_Segment__e, med feltene Kall-ID, Sekvens, Høyttalere, Starttid for segment, Slutttid for segment, Varighet og Avskriftsdata.
   2. Når du mottar den avskriftte teksten fra lyd, publiserer du umiddelbart dataene via hendelsen Transcript_Segment__e på signalserveren (se forutsetningsseksjonen). Du kan publisere hendelsen til Salesforce med en av disse metodene: Flyter, Apex, Salesforce API-er eller Pub/Sub API.
4. Wireflyt for å abonnere på den publiserte hendelsen Transcript_Segment__e.

   Opprette hendelsesutløst flyt	→	Abonnere på avskriftshendelse	→	Legg til kallbar handling agent	→	Sende last til agent
   						↓
   						Agent sender Slack DM

   1. Opprett en ny plattformhendelsesutløst flyt, Discovery Call Insights.
   2. Velg hendelsen Transcript_Segment__e som flyten skal abonnere på.
   3. Konfigurer en tilpasset agenthandling som kan kalles opp i Flow Builder, og velg Sanntids svar på salgssamtale-agenten. Send hendelsesbelastningen for å rute til emnet Hjelp samtale. Når spørsmålet er utledet fra emnet, sendes spørsmålet til handlingen Hent produktspesifikasjon for å få et svar.
   4. Det endelige svaret kompileres og sendes umiddelbart til brukeren via en Slack DM.

Agentkjøretidsflyt for prosess

Når agenten er konfigurert og distribuert, skjer følgende sekvens av trinn ved kjøretid.

1. Samtaleinitiering: David starter et oppdagelsessamtale med et prospekt i et Zoom-samtale. Zoom RTMS strømmer direktelyden til sluttpunktet for signalserveravskrift.
2. Sanntidsavskrift: Signalserveren mottar lyden, avskriver lyden til tekst og publiserer en Transcript Segment-plattformhendelse i Salesforce Platform.
3. Agentsletting og kontekstklassifisering: Salesforce mottar plattformhendelsen og utløser Discovery Call Insights-flyten.
4. Flyten initierer Sanntids svar-agenten for salgssamtale som mottar segmentet, identifiserer spørsmål (som "Integrerer Toaster 2XP med mobilenheter?"), og klassifiserer dem under emnet Assistent samtale.
5. Knowledge retrieval: Agenten utløser handlingen Hent produktspesifikasjon og spør Knowledge om samsvarende svar.
6. Send privat Slack DM: Agenten utfører Send Slack-innsikt ved å legge inn i Davids Slack DM: "Produkt Toaster 2XP kan integreres med Apple- og Android-enheter og kan kobles til via Bluetooth. Når appen er installert, kobler du bare til via Bluetooth og betjener brødristeren. Her er lenken til manualen."
7. Sanntids fortsettelse: Agenten fortsetter å motta avskriftstekst. Hvis det vises flere innsikter, tråder den kontekstuelle Slack-svar uten å avbryte samtaleflyten.
8. Sammendrag etter samtalen: På slutten av økten kompilerer agenten automatisk et sammendrag: viktige spørsmål, utførte handlinger og refererte produkter.
9. Kontinuerlig forbedring: Agentforce Analytics evaluerer avskrift-svarlatens, nøyaktighet av produktsamsvar og salgsresultater for å avgrense emneinstruksjoner over tid.

En salgsleder, Bob, oppgir en autonom agent et mål: "Øk salget under behandling i California Manufacturing-sektoren med 5 millioner USD de neste 60 dagene."

• Utløser: Lederen tildeler målet via en kommando i Slack.
• Agenthandling: Den autonome agenten starter sin planleggings- og utførelsessløyfe.
• Prosess:
  1. Forskning: Agenten spør Salesforce Data 360 og eksterne datakilder (via MuleSoft) for å identifisere firmaer i California's manufacturing-sektor som ikke er gjeldende kunder.
  2. Kvalifisere: Den analyserer disse firmaene og ser etter kjøpsignaler som nylige finansieringsrunder, nye ansettelser av ledere eller relevante jobbinnlegg. Den scorer og prioriterer de 20 beste prospektene.
  3. Identifisere kontakter: Den finner viktige kontakter (som visedirektører for drift og fabrikkledere) i disse firmaene.
  4. Outreach: Den tegner ut e-postmeldinger med personlig tilpasset tilgang for hver kontakt og refererer til bestemte firmainskaper eller smertepunkter. Den planlegger at disse e-postmeldingene skal sendes over neste uke.
  5. Følg: Den sporer åpninger og svar i e-postmeldinger. Et positivt svar fra et prospekt utløser en analyse av kalenderen for å foreslå møtetider, og genererer automatisk en Salesforce-hendelse og en ny salgsmulighet ved bekreftelse.
  6. Rapport: Den gir ukentlig Fremdriftsrapporter til salgslederen i Slack.

Recipe

Dette er et scenario med flere agenter der hver agent utfører en bestemt oppgave og overfører kontekst, data og kontroll til neste agent. Vi vil bruke noen tilpassede "hodeløse" agenter til forskning og kvalifikasjon, og den forhåndsdefinerte salgsutviklingsrepresentanten (SDR) til prospektutvidelse og overvåking. Vi vil også anta at Bobs firma bruker ZoomInfo til sin markedsundersøkelse. Firmaet mottar også leverandørnettverksdata som beholdes i en database og inneholder verdifull informasjon om firmaene de samarbeider med.

Design Time

1. Konfigurer fleragentarkitektur.

   Forskningsagent innhenter intelligens

   →

   Kvalifikasjonsagent rangerer salgsemner

   →

   SDR-agent starter oppfølging

   1. Forskningsagent: Spørringer mot 360-data og eksterne kilder via MuleSoft
   2. Kvalifikasjonsagent: Prioriterer, scorer og beriker salgsemner
   3. SDR-agent: Henter salgsemnetildelinger, utfører oppfølging, følger opp og planlegger møter. Overvåk aktivitet og fremdrift for SDR-agent med Agentforce Analytics for SDR-agent.
2. Oppdag og hent inn nye firmadata.

   Opprette nytt dataområde

   →

   Hente inn Salesforce CRM-data

   →

   Hente inn ZoomInfo-data

   →

   Hente inn leverandørdatabasedata

   1. Konfigurer et nytt dataområde kalt Salg og markedsføring. Dette nye dataområdet vil inneholde alle dataene som er nødvendige for autonome agenter.
   2. Bruk Salesforce-koblinger til å flyte salgsemne-, konto-, kontakt- og salgsmulighetsCRM-data til dataområdet.
   3. Konfigurer en Data 360-kobling for ZoomInfo. Flyt dataene til Data 360 Sales and Marketing-datarommet.
   4. Konfigurer Anypoint Salesforce Data 360-koblingen til å koble til leverandørdatabasen og hente inn dataene i Data 360.
3. Konfigurer en plattformhendelse for å starte den headless Research and Qualification-agenten.

   Opprett ny plattformhendelse

   1. Opprett en ny AgentGoal__e-plattformhendelse med feltmålet som fanger opp brukerens mål på høyere nivå.
4. Konfigurer en Goal Orchestrator-agent, en AI-agent for diskusjoner som mottar brukerens mål og orkestrerer det til andre agenter.

   Opprett agent fra mal	→	Legge til mål for tolking-emne	→	Legge til emneinstruksjoner	→	Opprett målhendelse-handling
   						↓
   						Legg til handling i emne

   1. Opprett en agent med Agentforce Ansattagent-malen.
   2. Legg til et nytt emne, Løs mål, med beskrivelsen om at denne agenten forstår målhensikten og kan kalle opp flere agenter etter behov.
      • Legg til emneinstruksjoner for å analysere målet og utløse hendelser for andre agenter.
   3. Opprett en Goal-hendelse, AgentGoal__e.
5. Konfigurer en Lead Research and Qualification-agent, som utløses av en orkestreringsagent.

   Opprette Research-emne	→	Opprett opphevingshandling	→	Opprett salgsemneforbedringshandling	→	Opprett salgsemnescoringshandling
   						↓
   				Legge til handlinger i emne	←	Opprett salgsemnekvalifikasjonshandling

   1. Opprett et prospektundersøkelse med beskrivelsen "Forske etter nye salgsemner i et område eller en stat".
   2. Opprett handlinger.
      • Apex-handling for å fjerne Apex for salgsemner: Kontrollere og validere nye salgsemner mot eksisterende kunder
      • Handlingen Enrich Lead Apex, som bruker en ledetekstmal: Ser på den ustrukturerte markedsføringsinnsikten og leverandørdatabasedata for å berike salgsemnedata
      • Handlingen Score salgsemne: Proaktivt score et salgsemne med oppdaterte salgsemnedata
      • Handlingen Qualify Lead for Agent (kvalifisere salgsemne for agent): Basert på scoren tildeler du parametere som kvalifiserer salgsemnet for en SDR-agent
6. Konfigurer en Agentforce SDR-agent for å utføre oppfølging, salgsemneoppfølging og møteplanlegging.

   Opprett SDR-agent fra mal	→	Konfigurere agent Knowledge	→	Konfigurere e-postinnstillinger for agent	→	Angi tildelingsregler for salgsemner
   						↓
   						Definere kvalifiserende salgsemnekriterier

   1. Opprett en ny SDR-agent fra Oppsett-siden med den forhåndskonfigurerte Salgsemneoppdragelsesagent-malen. Konfigurer e-postinnstillingene og tildelingsreglene for salgsemner, velg Salgsemne- eller Kontakt-objektet og definer kvalifiseringskriteriene ( terskel for salgsemnescore og nytt salgsemne) for tildelingsregler.
   2. Konfigurer Agentforce Lead Nurturing ved å konfigurere agenten, tildele tillatelser og konfigurere kadens- og tildelingsreglene.
   3. Konfigurer nødvendig Knowledge for at SDR-agenten skal kunne svare på spørsmål.
7. Konfigurer en ny flyt for å abonnere på den publiserte hendelsen AgentGoal__e.

   Opprette hendelsesutløst flyt

   →

   Abonnere på Hendelsen Agentmål

   →

   Legg til kallbar handling agent

   1. Opprett en ny plattformhendelsesutløst flyt kalt Rut mål til agenter.
   2. Velg hendelsen Agent Goal (Agentmål) som flyten skal abonnere på.
   3. Konfigurer en tilpasset agenthandling som kan kalles opp i Flow Builder, og velg agenten Lead Research and Qualification.

Agentkjøretidsflyt for prosess

Når agenten er konfigurert og distribuert, skjer følgende sekvens av trinn ved kjøretid.

• Måltildeling: Bob oppgir en autonom agent til å "øke pågående arbeid i California Manufacturing med 5 millioner USD på 60 dager".
• Målorkestrering: Den autonome Goal Orchestrator-agenten mottar målet, analyserer hensikten og oppretter en plattformhendelse, AgentGoal__e. Målorkestrer-agenten er utformet for å kontinuerlig utvide egenskapene for å håndtere flere mål. Du kan utvide den for å legge til flere orkestreringsfunksjoner eller be brukeren om klargjøring for å forstå hensikten bedre og starte målet.
• Ruting: Flytlinjemål til agenter utløses og kaller opp salgsemneundersøkelse og -kvalifisering-agenten.
• Forskning: Lead Research and Qualification-agenten spør Data 360 for ny salgsemneinformasjon, fjerner duplikater mot eksisterende kunder, trekker ut flere markedsundersøkelsesdata fra Data 360 og beriker salgsemnet. Den gir ytterligere score til salgsemnet, identifiserer viktige kontakter og kvalifiserer salgsemnet.
• Outreach: Når salgsemnet er kvalifisert, blir salgsemnet berettiget til SDR-agenten via tildelingsreglene for salgsemner. SDR-agenten gjør den første kontakten og opprettholder samtaler med kontakten ved å svare på spørsmål relatert til produktet.
• Følg: Ved slutten av kadensen eller på forespørsel fra salgsemnet ber agenten om en møteplan hvis salgsemnet er kvalifisert for servicerepresentantengasjement. Deretter planlegger den møtet og avslutter flyten.
• Agent Analytics: Kontrollpanelet i SDR Agent Analytics gir innsikt i hvor effektiv agentene gjør det.

En langtidskunde opplever et mangesidig problem: De ble overfakturert, erstatningsdelen de mottok, var feil, og tjenesten deres er nå frakoblet.

• Utløser: Kunden starter en chat, og den første samtaleagenten gjenkjenner raskt kompleksiteten og eskalerer til en agent-sversjon.
• Agenthandling: En orkestreringsagent tar over.
• Prosess:
  1. Orkestrator: Vedlikeholder samtalen med kunden ved å oppdatere
  2. Orkestradelegerte: Ved å bruke A2A-protokoltimplementeringen oppdager orkestrator "relaterte agenter" (fakturering, logistikk og klargjøring) med de nødvendige funksjonene og sender oppgaver.
     • Til faktureringsagent: "Undersøke faktura #INV-7890 for kunde X. Er det avvik?"
     • Til logistikkagent: "Kontroller sporingsnummer #TN-12345 for kunde X. Bekreft avsendte delenummer og gjeldende lagerbeholdning for riktig del."
     • For å klargjøre agent: "Kontroller tjenestestatusen for kontoen #ACC-5678. Hvis tilkoblet, hva er årsakskoden?"
  3. Spesialiserte agenter utfører: Hver agent mottar A2A-forespørselen, spør sitt respektive system og formulerer et svar.
  4. Syntese: Agentene rapporterer funnene sine tilbake til orkestreringen via A2A-svar. Orchestrator syntetiserer informasjonen: "Kunden ble faktisk overfakturert med 50 USD. Feil del ble sendt på grunn av en lagerfeil. Tjenesten ble automatisk koblet fra på grunn av faktureringsproblemet."
  5. Bekreftelse: Orchestrator informerer kunden om problemet og tilbyr å eskalere problemet til en servicerepresentant med tydelig veiledning om de neste trinnene.
  6. Løsning: Den foreslår deretter en fullstendig løsning til servicerepresentanten for godkjenning. Servicerepresentanten slutter seg til samtalen. Servicerepresentanten ser raskt på alle dataene som er relevante for problemet, inkludert agentens anbefalte løsning: "Opprett en ny forsendelsesbestilling for den høyre delen med raskere forsendelse. Start en retur for feil del. Godkjenn 10 % rabatt på den nye bestillingen, og oppsalg delen med den nyeste forbedrede versjonen. Oppdater betalingsinformasjon og tilbud for å konfigurere en gjentagende faktureringsordning."

Recipe

Denne oppskriften beskriver implementeringen av et samarbeidsagentsystem utformet for å takle komplekse kundeserviceproblemer som involverer flere fasetter. Ved å bruke en orkestreragent til å delegere oppgaver til spesialiserte agenter (Billing, Logistikk og Klargjøring) via en A2A-protokoll og deretter syntetisere funnene deres, gir systemet omfattende løsninger og integrerer sømløst servicerepresentanter for endelig godkjenning og kundeinteraksjon.

Design Time

1. Konfigurer Forbedret chat som kundens chatteoppføringspunkt slik at kunden kan åpne Agentforce-vinduet på nettsiden.
2. Konfigurer en Agentforce Billing Agent, en headless spesialisert agent som kan ta en bestilling eller faktura og utføre en faktureringsforespørsel.

   Opprett agent fra mal

   →

   Definere emne for faktureringsforespørsel

   →

   Opprett tilpasset flythandling

   →

   Legg til handling i emne

   1. Aktiver Agentforce og opprett en ansattagent fra Agentforce Ansattagent-malen.
   2. Definer et emne, Faktureringsforespørsel, med beskrivelsen "Undersøke fakturaavvik, betalingsproblemer og faktureringsfeil."
      1. Legg til en tilpasset flythandling, Sjekk fakturaavvik, med en inndata for fakturanummer, kunde-ID og datoområde, og en utdata for avvikbeløp, rodårsak og berørte transaksjoner.
3. Opsæt en Agentforce Logistics Agent, en headless specialiseret agent, der kan bekræfte forsendelser, spore forsendelse og kontrollere lager.

   Opprett agent fra mal

   →

   Definer emne for forsendelsesbekreftelse

   →

   Opprett tilpasset flythandling

   →

   Legg til handling i emne

   1. Aktiver Agentforce og opprett en ansattagent fra Agentforce Ansattagent-malen.
   2. Definer et emne: Leveringsbekreftelse, med en beskrivelse for å bekrefte forsendelse for faktura.
      1. Legg til en tilpasset Flyt-handling, Bekreft forsendelsesdetaljer, med en inndata for fakturanummer, kunde-ID og datoområde, og en utdata for forsendelsesdel, dato og lagerbeholdningsstatus.
4. Konfigurer en Agentforce, en headless spesialisert agent som kan bekrefte klargjørings- og tjenestestatus.

   Opprett agent fra mal

   →

   Definere tjenestekontrollemne

   →

   Opprett tilpasset flyt-handling

   →

   Legg til handling i emne

   1. Aktiver Agentforce og opprett en ansattagent fra Agentforce Ansattagent-malen.
   2. Definer et emne, Service Check, med en beskrivelse for å bekrefte tjenestetilkoblingen og kontostatusen.
      1. Legg til en tilpasset Flyt-handling, Bekreft tjeneste, med en inndata for kunde-ID og aktivum-ID, og en utdata for tjenestestestatus og årsak til tjenesteunntak.
5. Vis fakturerings-, logistikk- og klargjøringsagenter som A2A-servere, og registrer dem i Agentregister.

   Eksponere agenter via MuleSoft

   →

   Registrere agenter i register

   1. I fravær av direkte A2A-støtte på Agentforce Agenter kan MuleSoft-koblinger brukes til å eksponere agent-APIer som A2A-servere.
   2. Registrer disse A2A-serverne i Agent Registry.
   3. Bruk Anypoint Agent Fabric til orkestrering av agenter.
      1. MuleSoft Agent Broker kan bidra til å orkestrere en hvilken som helst agent på tvers av plattformer basert på agentfunksjonalitet som er nevnt på agentkortene.
6. Konfigurer en Agentforce Hjelp-agent, en AI-agent som samhandler med kunder, vurderer kompleksitet og koordinerer med flere spesialiserte agenter for å løse problemet.

   Opprette tjenesteagent	→	Definere undersøkelsesemne	→	Opprett varselhandling	→	Definere orkestreringsemne
   						↓
   Definer eskaleringsemne	←	Opprett opprett sak-handling	←	Opprett Call Agent-handling	←	Opprett agentorkestreringsflyt
   ↓
   Opprett Omnikanal-flyt	→	Koble til flyt for eskalering

   1. Aktiver Agentforce og opprett en tjenesteagent i Agentforce Builder for å håndtere samtaler og utløse tilpassede handlinger.
   2. Definer et emne, Service Investigation, med en beskrivelse og instruksjoner slik at agenten naturlig gjenkjenner et komplekst emne med, vanligvis, flere samtidige problemer.
      1. Opprett tilpassede agenthandlinger.
         • Statusadviseringshandling for å bekrefte problemet og gi fremdriftsoppdateringer
   3. Definer et orkestreringsemne som kan kalle opp andre agenter via handlinger.
      1. Opprett en Call Agent-handling som kaller opp en Flyt-handling. Flythandlingen har flere agenthandlinger og kan starte hver av de hodeløse agentene: Faktureringsagent, Logistikkagent og Klargjøringsagent.
      2. Opprett en Opprett sak-handling som oppretter en sak, legger til detaljer og angir statusen.
   4. Definer et Eskalering-emne med en beskrivelse som skal eskaleres til en servicerepresentant.
   5. Opprett og aktiver en utgående Omnikanal-flyt.
      • Legg den til på Tilkoblinger-fanen i Agent for eskalering med en eskaleringsmelding.

Agenter orkestreringsprosessflyt

Anypoint Code Builder støtter nå byggeragentmeglere. En agentmegler er et intelligent rutings- og orkestreringslag som kobler agenter på tvers av domener og engasjerer de best egnede agentene og verktøyene. MuleSoft Dev Agent genererer koden for å sette opp et grunnlag for megleren.

Basert på agentfunksjonalitet som er nevnt på agentkortene (A2A-servere), som tidligere har blitt registrert i Agentregister, utføres flere konfigurasjoner automatisk av Anypoint Code Builder. Til slutt kan vi distribuere denne agentmegleren til skyen.

Når agentmegleren er tilgjengelig for forbruk, rutes disse forespørslene til de riktige agentene. En megler mottar en melding og bruker LLM til å dele den opp i oppgaver og bestemme hvilken agent som skal ringes først. I hver gjentagende sløyfe bestemmer den om den har løst den opprinnelige ledeteksten, eller om den må arbeide med flere agenter for å fullføre jobben.

Agentkjøretidsflyt for prosess

Når agenten er konfigurert og distribuert, skjer følgende sekvens av trinn ved kjøretid.

1. Chatstarter: En kunde åpner Agentforce (innebygd tjeneste). Økt- og kontaktkontekstinnlasting etter at kunden er logget på.
2. Hilsning og hensikt: Agenten hilser kunden velkommen. Kunden varsler med tydelig frustrasjon om overforbruk, feil del og frakoblet tjeneste.
3. CRM-oppslag: Agenten utløser handlingen Hent siste bestilling og spør Salesforce (bestillingsoppsummering/bestillinger) om kundens siste post. Agenten bekrefter deretter bestillingen i kontekst og varsler kunden om at den vil undersøke. Den slår ytterligere opp på faktura-IDen, sporingsnummeret som er knyttet til fakturaen, og aktivum-IDen som er relatert til tjenesten.
4. Orkestrator aktivering: Orchestrator-agenten mottar eskalerings- og bestillings-IDen og oppretter deretter en sak. Den overfører kontekstdataene til og kommuniserer med tre agenter: Faktureringsagent, Logistikkagent og Klargjøringsagent.
5. Billing Agent-svar: Faktureringsagenten returnerer med detaljer om delen, enhetskostnad og totalkostnad. Den merker også et avvik mellom delen i bestillingen og delen i fakturaen. Faktureringsagenten slår opp på prisen for den delen av bestillingen og årsakene til overforbruket.
6. Logistics Agent-svar: Logistikkagenten returnerer med detaljer om den sendte delen og unntaksmerknadene opprettet av logistikksystemet, som angir at feil del kan ha blitt sendt på grunn av kodingsproblemer. Logistikkagenten kontrollerer også at problemet nå er løst og at den riktige delen er tilgjengelig i den opprinnelige og nyere versjonen.
7. Svar fra klargjøringsagent: Klargjøringsagenten returnerer med detaljer om tjenesteavkoblingen og problemet med den utløpte betalingsinformasjonen. Den leverer også varslene som sendes for å gi råd til kunden om å oppdatere betalingsinformasjonen.
8. Orkestrator-syntese: Orchestrator-agenten syntetiserer svarene fra alle disse agentene og lager en løsning ved å se på Knowledge for hvert av problemene. Først slår den opp på informasjon på feil del og starter en retur. Deretter tilbyr den en rabatt for problemet basert på løsningspolicydokumentene, og anbefaler også en oppgradering til en nyere versjon som kunden kan kjøpe (men det er en prisforskjell). For det tredje trenger den ny betalingsinformasjon fra kunden, så den eskaleres til servicerepresentanten for å kommunisere løsningen.
9. Eskalering: Orchestrator-agenten eskalerer til servicerepresentanten – og gir alle nødvendige kontekstnotater, undersøkelsesnotater og løsningsanbefalinger sammen med nødvendige godkjenninger – og bringer servicerepresentanten inn i samtalen.
10. Menneske i sløyfe: Servicerepresentanten takker kunden for tålmodigheten, ber om unnskyldning for problemet og forklarer problemet. Servicerepresentanten tilbyr deretter en rabatt på 10 % for delen som kompensasjon, og informerer også kunden om en ny oppgradert del og dens fordeler. Til slutt forklarer de koblingen, får den nye betalingsinformasjonen og oppdaterer systemet.
11. Proaktiv restaurering: AI-agenten overvåker samtalen og handler proaktivt for å gjenopprette tjenesten, bestille den oppgraderte delen og opprette en ny faktura med rabatten og justert pris.
12. Saksavslutning: Til slutt kompilerer den sammendraget, oppdaterer saken og avslutter saken.

For at en agent skal være effektiv må den kunne integreres med et bredt sett bedriftsdata og -verktøy. Dette gir den grunnleggende konteksten en agent trenger for å oppnå sitt konfigurerte mål. Agentforce-rammeverket tilbyr en sofistikert integrasjonsarkitektur som integrerer data som er både interne for Salesforce og eksterne for Salesforce.

Denne delen utforsker mønstrene for å koble agenter til disse ressursene. Disse mønstrene bygger på to grunnleggende tilnærminger for integrering.

• Intern integrasjon (datatilgang og verktøyetilgang): For ressurser i Salesforce-økosystemet har en agent to måter å operere på.
  • Datatilgang: Agentforce kjernetiden er dypt integrert med Data 360, slik at den kan spørre direkte interne datatjenester. Det kan innebygd formulere og utføre spørringer mot Datagrafer for å få en 360-graders visning av kunden, utføre semantiske søk via RAG for å forstå ustrukturert Knowledge, og få tilgang til masseinformasjon ved hjelp av Data 360 Query API. Denne direkte banen er optimalisert for hastighet og fleksibilitet i datahentingen.
  • Tilgang til verktøy: Når en oppgave involverer kompleks forretningslogikk eller flertrinns prosesser, eller når den krever streng styring, innkapsles dens evner i handlinger. Disse handlingene er bygd med Apex eller Flyt, og gir en sikker og gjenbrukbar grensesnitt for agenten til å gjøre mer enn bare lese data – de tillater den å oppdatere poster, utløse plattformhendelser eller utføre en etablert forretningsprosess.
• Ekstern integrasjon (MCP/A2A): Når en agent trenger informasjon utenfor Salesforce (for eksempel fra et eksternt program, en mikrotjeneste eller en annen agent), bruker den Model Context Protocol (MCP). Denne åpne standarden gir et felles språk for interoperabilitet. MCP-servere kan legges til fra AgentExchange eller en administrator kan legge til i Agent Registry eller et Apex-oppkall til MCP-serveren. Handlingen starter deretter forespørselen til en ekstern MCP-server som bygger bro mellom de interne og eksterne verdenene på en strukturert måte. På samme måte, når en agent trenger å kommunisere med en annen agent, Agent2Agent (A2A) protokollen forenkler denne interaksjonen. Dette gjør det mulig å opprette komplekse systemer med flere agenter der spesialiserte agenter kan samarbeide for å løse komplekse problemer, og fremme modulærhet og gjenbrukbarhet.

Følgende mønstre er organisert rundt de spesifikke dataintegreringstemaene agenter trenger. Vi vil demonstrere hvordan disse mønstrene brukes til å løse forskjellige dataproblemer, fra tilkobling til eksterne programmer ved hjelp av MCP til tilgang til høyvolums massedata i Data 360, sanntids transaksjonsposter og ustrukturert innhold ved hjelp av den kraftige kombinasjonen av direkte tilgang og formelle handlinger i Data 360.

Problem

En agents effektivitet avhenger av dens mulighet til å betjene eksterne verktøy. Disse verktøyene, fra eldre ERP-er til moderne SaaS-programmer, mangler imidlertid et delt språk. Hver av dem har et unikt API, godkjenningsmodell og dataformat. Dette tvinger utviklere inn i en sprø og ikke skalerbar syklus med å bygge og vedlikeholde tilpassede, punkt-til-punkt-integrasjoner for hvert nytt verktøy agenten trenger å bruke.

Context

Vurder en agent som er oppgitt til å løse en skadet leveransesak. For å lykkes må den samhandle med tre eksterne systemer: den må spørre en leverandørs API for å sjekke for erstatningsbeholdning, ringe en logistikkpartners tjeneste for å ordne en ny levering, og få tilgang til et finansielt system for å behandle en kreditt. Uten en felles protokoll ville agenten kreve tre separate, tilpassede integrasjoner, hver av dem et potensielt feilpunkt. MCP tilbyr et standardisert kommunikasjonslag for å gjøre disse interaksjonene sømløse og pålitelige.

Følgende er oppskrifter for hvordan du integrerer eksterne tjenester som vises via MCP, til agenten.

Oppskrift 1: Aktiver eksterne verktøy med MCP

Problem

Organisasjoner kjører på en blanding av eldre ERP-er og moderne SaaS, men det er vanskelig å integrere dem med en agent fordi det ikke er noen felles protokoll – hvert verktøy har sine egne API-er, godkjenning og datamodell. Utviklere bygger og vedlikeholder tilpassede punkt-til-punkt-koblinger for hvert verktøy, noe som fører til skjøre, ikke skalerbare og kostbare integrasjoner.

Mønster

Agenten kaller opp et eksternt verktøy (eksponert via MCP) via en strukturert handling, slik at den kan bruke spesialiserte verktøy utover Salesforce-plattformen.

Context

• Agenten fungerer som en proxysett for et sett verktøy som finnes utenfor Salesforce-plattformen.
• Disse eksterne verktøyene kan ha ulike API-er, godkjenningsmekanismer og dataformater.
• Det kreves en standardisert kommunikasjonsprotokoll for å muliggjøre sømløs interaksjon mellom agenten og disse eksterne verktøyene.
• Gjenbruk er et viktig problem fordi de samme eksterne verktøyene kan brukes av flere agenter til forskjellige formål.

Interaksjoner

1. Utløser: En brukerforespørsel eller en intern hendelse i Agentforce krever bruk av et eksternt verktøy.
2. Hensikt å handle: Agentforce identifiserer hensikten og finner ut at det kreves et eksternt MCP-basert verktøy.
3. Planlegger (intern): Agentforce planlegger velger det riktige MCP-verktøyet eller -handlingen basert på dens konfigurerte instruksjoner og tilgjengelige verktøy.
4. Utførelse: Agentforce sender en MCP-kompatibel forespørsel til den eksterne MCP-serveren (for eksempel via et Apex til et MuleSoft-endepunkt, som deretter rutes til den eksterne MCP-serveren).
5. Ekstern behandling: Den eksterne MCP-serveren behandler forespørselen, samhandler med det underliggende eksterne programmet og klargjør et MCP-kompatibelt svar.
6. Resultat: Den eksterne MCP-serveren returnerer svaret til Agentforce Agent.
7. Følg: Agentforce Agent behandler svaret, oppdaterer dets interne tilstand og fortsetter oppgaven eller gir tilbakemelding til brukeren.

Trade-Offs

En agents beslutningslogikk er bare så god som dens underliggende data. For at en agent skal kunne handle intelligent må den ha en omfattende, sanntids forståelse av verden rundt seg. Uten en definert datainntaksarkitektur kan ikke agenten få tilgang til eller behandle informasjonen i sanntid med stor trafikk som er viktig for at den skal fungere.

Integrere transaksjonsdata med agenter

Problem

Agenter må ofte utføre lese/skrive-operasjoner med lav latens på individuelle poster som befinner seg i postsystemer (for eksempel oppdatere en sak eller hente en bestillingsstatus). Disse handlingene krever dataintegritet og pålitelighet for å sikre konsistens for den underliggende datamodellen. Den kjernearkitektoniske utfordringen er å gi et sikkert, sanntids og skalerbart mønster for denne transaksjonelle datatilgangen uten å opprette skjøre punkt-til-punkt-integrasjoner.

Context

En vellykket tilkobling av en agent til disse postene krever en robust arkitektur som består av flere kjernekomponenter.

• Transaksjonssystemer: Dette er de autoritative kildene til dataene, som systemer for poster, som Salesforce, Workday eller SAP, eller tjenester som befinner seg på plattformer som AWS.
• Integrasjonslag: Et kraftig integrasjonslag, som vanligvis håndteres av MuleSoft, er avgjørende for sikker tilkobling til disse forskjellige systemene, transformasjon av data og eksponering til Agentforce-plattformen.
• MCP-servere: For å sikre interoperabilitet kommuniserer agenter med disse eksterne systemene ved bruk av MCP-standarden. Integreringslaget kan koble til forskjellige MuleSoft-, Heroku- eller tredjeparts MCP-servere som er vert for de eksterne tjenestene eller agentene.
• Agent Exchange: Denne komponenten fungerer som en mappe eller et byttepanel slik at Salesforce-agenten kan oppdage og koble seg sikkert til den riktige eksterne tjenesten eller agenten for å fullføre oppgaven sin.

Oppskrift 1: Direkte registreringsoperasjoner via MCP

Mønster

Agenten bruker MCP til å koble til et transaksjonsdatasystem og utfører statlige CRUD-operasjoner på bestemte, identifiserte poster med umiddelbare konsistenskrav.

Context

• Samtaleagenter som samarbeider må transaksjonere postsystemdata i arbeidsflyten.
• Postsystemet er et eksternt system.
• Transaksjoner må være idempotent.

Nøkkelkomponenter

• Agentforce Agent: Med emner og instruksjoner for å gjøre en transaksjonsoppdatering. Handlinger kaller opp en ekstern MCP-server eller Agentforce Exchange-registrert MCP-server.
• MCP-server: MCP-serveren som viser transaksjonsdataene og -funksjonen (for eksempel tool=billing.update_record med inndata)
• Eksternt system for post: Systemet der endringen av status skjer

Interaksjoner

1. Utløser: Det oppstår en kommando eller hendelse som krever en transaksjon for en post.
2. Hensikt å handle: En Agentforce identifiserer en tilstandsendringshensikt.
3. Planlegger (intern): Planleggeren velger et MCP-verktøy.
4. Utfør: Verktøyet utføres etter at tilgangskontroller på policy-, post- og feltnivå har blitt utført.
5. Resultat: MCP-serveren returnerer et svar
6. Følg: Agentforce Agent behandler svaret.

Trade-Offs

Oppskrift 2: Komplekst orkestrering via Mulesoft API

Mønster

Agenten benytter Mulesoft API til komplekse, flertrinns atomtransaksjoner på tvers av systemer. Dette gir et enkelt, styrt endepunkt som sikrer pålitelig ende-til-ende-behandling og unngår problemene med konsistens, pålitelighet, latens og data som er knyttet til direktesamtaler til individuelle systemer.

Context

• Samtaleagenter og autonome agenter må ofte utføre flere operasjoner pålitelig.
• Det er flere transaksjonssystemer og operasjoner i en transaksjon.
• Arbeidsflyter krever transaksjon/tilbakestilling, nye forsøk og policyhåndhevelse.
• Transaksjonsbehovene er sanntids, idempotente, observerbare og samsvarende.

Interaksjoner

1. Utløser: Det oppstår en kommando eller hendelse som krever at en kompleks transaksjon fullføres.
2. Hensikt å handle: Agentforce identifiserer hensikten.
3. Planlegger (intern): Planleggeren velger en kallbar handling for API- eller API-handling.
4. Utførelse: API-et utføres og et svar returneres.
5. Følg: Agentforce Agent behandler svaret.

Trade-Offs

Integrere analytiske data med agenter

Problem

Organisasjoner har investert mye i analytisk infrastruktur – datalagrer og innsjøer, sanntidsanalyse og forretningsintelligensplattformer – men AI-agenter forblir frakoblet fra disse systemene. Dette oppretter et gap i en agents mulighet til å få en forbedret kontekst (for eksempel at en kunde hadde returnert deler tre ganger i forrige kvartal) for å bidra til å ta bedre beslutninger (i dette tilfellet eskalering).

Context

En agents operative intelligens utledes fra dens evne til å syntetisere informasjon fra fundamentalt forskjellige dataformater og -kilder. Dette arkitektoniske mønsteret er derfor ikke utformet for ett enkelt brukstilfelle, men som et grunnleggende rammeverk for datainntak. En effektiv agent må være utstyrt med å behandle strukturerte kilder for å utføre logisk, datadrevet analyse. En agent krever tilgang til strukturerte feeder med stor trafikk. Dette inkluderer integrering med bedriftens datasjøer (via null-kopi-integrering med Data 360), behandling av mellomliggende datastrømmer eller inntak av gruppedata som CSV-er.

Oppskrift 1: Data Lakes integrert via Data 360 Zero-Copy

Problem

Organisasjoner står overfor høye kostnader når de bruker tradisjonelle data under behandling til å kopiere, behandle og transformere analytiske data som er lagret i datasjøer (for eksempel Snowflake). Historisk har analyser i stor grad vært offline, noe som resulterer i manglende salgsmuligheter for rettidig handling.

Mønster

Agenten spør om null kopierte data (og beregnede innsikter) som er tilgjengelig i Data 360, i stedet for å spørre eksterne datalagrer for å få viktig innsikt. Dette hjelper agenter med å lage grunnlag for både transaksjons- og analytiske data for bedre beslutningsprosesser.

Context

• Organisasjonen lagrer kundedata og driftsdata i datalagrer og innsjøer.
• Agentene trenger tilgang til aggregerte målinger, historiske trender og analytisk innsikt.
• Agentens kontekst trenger både transaksjons- og analytiske data (vurder en undersøkelsesagents behov for historiske trenddata).

Interaksjoner

1. Utløser: En agent mottar en spørring om en innsikt som krever tilgang til analytiske data eller en beregnet innsikt.
2. Utførelse: Agenten utfører en handling som kaller opp Beregnet Data 360-innsikt via Query API, og den beregnede innsikten returneres.
3. Følg: Agentforce Agent behandler svaret.

Trade-Offs

Oppskrift 2: Utløse handlinger fra datastrømmer

Problem

Organisasjoner genererer kontinuerlig verdifull informasjon fra forretningsaktiviteter som nettstedsbesøk, samtaler, møter, chatter og sensordata. Men når disse interaksjonene blir tilgjengelige eller hentes fra datalagrer, mistes viktig innsikt, og muligheten for rettidig intervensjon er passert. Følgelig mangler organisasjoner det meste av den handlingsorienterte intelligensen som er nødvendig i sanntid, som ofte er begravd i disse midlertidige strømmene. Dette fører til hull, manglende coaching-muligheter og beslutninger som tas uten fullstendig kontekst.

Mønster

Agenten mottar sanntids eller nær sanntidsinnsikt fra strømmingsinnsikt eller en sanntidsinnsikt i Data 360 via en datahandling, eller agenten får tilgang til en strømmingsinnsikt i sanntid ved å spørre en MCP-server som er i grensesnitt med en sanntids behandlingsmotor som Apache Flink.

Context

• Strømmingssystemer som plattformhendelser, Pub/Sub API og RTEM genererer enorme mengder strømmedata.
• Strømbehandlingssystemer som Data 360 og Apache Flink behandler disse individuelle hendelsene etter hvert som de ankommer.
• Agentforce må spørre strømningssystemene (for eksempel den siste 30-sekunders avskriften for direktemøtet med ekstra kontekst) eller bli utløst av datahandling (for eksempel svindeloppdagelse).
• Det er behov for handling i nær sanntid med lav latens.

Interaksjoner

1. Strømutgivelse: Kildesystemet sender ut en kontinuerlig strøm av data.
2. Strømbehandling: Strømbehandlingsmotorer som Data 360 eller Apache Flink behandler informasjonen.
3. Transform: Innsikter aggregeres, transformeres og syntetiseres til agentbevisste data i mellomprogramvare (for kompleks transformasjon) eller i Data 360.
4. Stream-innsiktshendelse: En Data 360-datahandling utløses for syntetiserte data (for eksempel en avskrift av en 30 sekunders lydstrøm).
5. Anrik: En agent legger til kontekst og oppdager hensikt.
6. Utfør: Agenten utfører handling.
7. Følg: Agenten venter på neste strømmede innsikt.

Trade-Offs

Integrere semantiske data med agenter

Organisasjoner har forretningsartikler – kataloger, manualer, policyer, Knowledge, relasjonskart – i forskjellige formater og former. For å gå utover enkel utførelse av oppgaver og engasjere seg i sofistikert resonnement, må agenter være i stand til å forstå disse dataene der mesteparten av menneskelig Knowledge er lagret.

Oppskrift 1: RAG: Låse opp kraften i ustrukturerte data for agenter

Problem

Organisasjoner har ofte ikke-søkbar informasjon som hindrer agenter i å få tilgang til den med tillit. Denne mangelen fører ofte til ufullstendige svar fra agenter, mangler nødvendig kontekstdybde og verifiserbare sitater for å etablere Trust. Det er derfor et tydelig behov for en standardisert metode for å gi agenter mulighet til å hente semantisk relevant og nøyaktig innhold konsekvent.

Mønster

Dette mønsteret gir arkitekturen som gir agenter mulighet til å hente inn og tolke en rekke ustrukturert informasjon, fra interne dokumenter til offentlig nettinnhold. Å gi en agent tilgang til disse dataene er nøkkelen til å låse opp avanserte funksjoner som markeds stemningsanalyse, dokumentoppsummering og konkurrentundersøkelse.

Context

• Knowledge finnes i filer i forskjellige formater.
• Overflødigt indhold er almindeligt på tværs af disse dokumenter.
• En agent trenger nøyaktig informasjon som kan siteres.
• Knowledge endres ofte, så filer må oppdateres og indekseres på nytt.

Interaksjoner

Innholdet kan ikke tas inn eller brukes av agenten slik det er. Innholdet må deles, bygges inn, lagres i en vektordatabase og indekseres før det kan hentes og brukes av agenter.

Spis inn og lag

1. Søk og inntast kilder: Kilder kan identifiseres på to måter: manuelt, som å laste opp en PDF-fil, eller etter plasseringen, som AWS S3.
2. Chunking: Inntatt innhold brytes ned i mindre, administrerbare biter for å gi enklere behandling og henting. Dette er et viktig trinn for RAG fordi det sikrer at bare de mest relevante bitene av informasjon hentes, i stedet for hele dokumenter.
3. Innbygging: Hver bit blir deretter konvertert til en numerisk representasjon kalt en innbygging ved hjelp av en spesialisert språkmodell. Disse innbyggingene fanger opp den semantiske betydningen av teksten og tillater likhetsbaserte søk.
4. Vektorlagring: Innbyggingene lagres i et Data 360-vektorlager, en spesialisert database optimalisert for søk med høy ytelse av likhet. Da kan agenten raskt finne relatert innhold.
5. Indeksering: Innholdet og dets innbygginger indekseres i vektorbutikken slik at de lett kan søkes etter for henting.

Data 360 retriever funksjoner

• Hent innhold: Denne funksjonen tar en spørring som inndata og utfører et semantisk søk mot Data 360-vektorlageret for å finne de mest relevante innholdsbundene.
• Filterinnhold: Denne funksjonen tillater filtrering av hentet innhold basert på metadata, som dokumenttype, forfatter eller dato, for å begrense resultatet ytterligere.
• Rank content: Denne funksjonen rangerer de hentede innholdsbitene basert på sin likhetsscore (vektorsøk), nøkkelordscore eller en kombinasjon av begge (hybrid søk).

Hente og generere

• Spørring: Når en agent trenger informasjon, formulerer den en spørring som også er innebygd i en vektor.
• Semantic search: Agenten utfører et semantisk søk mot Data 360-vektorlageret og sammenligner spørringens innbygging med innbyggingene av de lagrede innholdsbunkene. Dette henter de mest semantisk relevante bitene basert på vektor score eller hybrid score (vektor og nøkkelord kombinert).
• Fangstforbedret generering (RAG): De hentede innholdsbunkene leveres så som kontekst til Agentforce sammen med den opprinnelige spørringen. LLM bruker denne konteksten til å generere et presist, nøyaktig og anførselsbart svar.
• Svar og sitat: Agenten presenterer det genererte svaret, ofte med sitater til de opprinnelige kildedokumentene eller nettlenkene, for å bygge Trust og muliggjøre verifisering.

Trade-Offs

Oppskrift 2: Datagrafer: Forhåndskurerte strukturerte grafdata for agenter

Problem

Organisasjoner har ofte isolerte relasjonsdata som hindrer en agents mulighet til å hente dem. Dette problemet fører ofte til at agenter gir ufullstendige svar som mangler tilstrekkelige kontekstdetaljer for å bygge Trust om hvordan forskjellige enheter er koblet sammen, eller fører til forsinkelser når agenter må hente informasjon fra flere databaser.

Mønster

Dette mønsteret gir arkitekturen for å gi agenter mulighet til å hente inn og tolke et bredt utvalg av strukturert og semi-strukturert relasjonsinformasjon, fra interne CRM-data til eksterne Knowledge. Å gi en agent tilgang til disse dataene er nøkkelen til å låse opp avanserte funksjoner som Customer 360, kompleks avhengighetsanalyse og dynamisk kontekstbygging.

Context

1. Relasjonsdata er fordelt på tvers av ulike systemer og formater.
2. Agenter må forstå tilkoblinger mellom enheter (for eksempel en kunde, deres saker, deres bestillinger og relaterte produkter).
3. Knowledge og tilkoblede datamodeller er avgjørende for å forstå komplekse relasjoner.
4. Agenten trenger nøyaktig informasjon om enhetsrelasjoner som kan siteres.

Interaksjoner

Relasjonsdataene må harmoniseres og representeres i en grafstruktur før de kan spørres og brukes effektivt av agenter.

Spis inn og lag

1. Crawland-inntakskilder: Datakilder (for eksempel CRM-systemer, ERP-er, eksterne API-er og CSV-er) identifiseres og hentes inn i Data 360.
2. Dataharmonisering: Rådata tilordnes til datamodellobjekter (DMO-er) i Data 360, standardiserer strukturen og oppretter en forent visning.
3. Identitetsløsning: Duplikatkundeprofiler konsolideres og relaterte poster kobles sammen for å opprette en enkelt, nøyaktig visning av hver kunde.
4. Datagrafoppretting: DMO-er kobles til for å danne en datadiagram som representerer relasjoner mellom forskjellige enheter (for eksempel er et kunde-DMO koblet til et saks-DMO, som er koblet til et produkt-DMO). Dette diagrammet tillater effektiv gjennomgang av relasjoner.
5. Beregnede innsikter: Aggregerte målinger og utledede attributter (for eksempel en kundes totale kjøpshistorikk) beregnes og legges til i datadiagrammet for å få rikere kontekst.

Hente og generere

1. Spørring: Når en agent trenger informasjon som involverer relasjoner mellom enheter, formulerer den en spørring mot datadiagrammet (for eksempel "Hva er alle åpne saker for denne kunden og hvilke produkter er tilknyttet dem?").
2. Graf traversal og Query API: Agenten bruker Data 360 Query API til å gå gjennom datadiagrammet og hente tilkoblede poster, beregnede innsikter og relevante attributter basert på spørringen.
3. Kontekstgenerering: De hentede relasjonsbevisste dataene blir deretter gitt som kontekst til Agentforce agenter sammen med den opprinnelige spørringen. LLM bruker denne beregnede konteksten til å generere et presist, nøyaktig og anførselsbart svar som gjenspeiler dataenes sammenkobling.
4. Svar og sitat: Agenten presenterer det genererte svaret, ofte med referanser til de spesifikke postene eller relasjonene i datadiagrammet som informerte svaret, for å bygge Trust og tillate verifisering.

Trade-Offs

Virksomheten står på kanten av en ny æra med automatisering og intelligens, ledet av AI-agenter. Fra å håndtere enkle kundespørringer til å utføre komplekse forretningsstrategier automatisk, lover agenter å omdefinere produktivitet og kundeengasjement. Salesforce Agentforce gir det viktigste, pålitelige grunnlaget for denne transformasjonen. Med en robust pakke med deklarative og kodeverktøy, en forent dataplattform og en forpliktelse til å åpne standarder gjennom A2A og MCP, gir Agentforce et omfattende og pålitelig grunnlag for å bygge alle typer agenter. Denne arkitekturen gjør det mulig for organisasjoner å distribuere intelligente målrettede agenter som fungerer som tilkoblede partnere, ikke isolert, for å oppnå målbar forretningssuksess.

Salesforce tilbyr et kraftig, integrert sett verktøy, forent av Agentforce plattformen, som fungerer som grunnlaget for å bygge sofistikerte agenter. Oppskriftene og eksemplene i dette dokumentet forutsetter at du er kjent med funksjonaliteten til Agentforce og hvordan agenter samarbeider. Denne delen gir deg en oppdatering av de viktigste komponentene du trenger å forstå for å få mest mulig ut av oppskriftene og mønstrene i dette dokumentet.

Denne delen beskriver de grunnleggende plattformfunksjonene som er avgjørende for arkitekter og utviklere som bygger agenter på Agentforce.

• Salesforce-flyt: Det primære verktøyet for å definere agentlogikk. Det deklarative, visuelle grensesnittet er ideelt for orkestrering av trinnene en agent vil utføre.
• Apex: Gir muligheten til kompleks tilpasset logikk, statusbehandling for autonome agenter og komplekse integrasjoner
• Plattformhendelser: Nervesystemet for proaktive og samarbeidende agenter, som fungerer som transportlaget for A2A-protokollen.
• Data 360: Agentens forente, langsiktige minne. Den sørger for den konteksten som er nødvendig for intelligent handling, og er grunnlaget for generering med utvidet henting (RAG).
• MuleSoft: Agentens bro til den ytre verden, som aktiverer både systemintegrering og agentkommunikasjon på tvers av plattformer via MCP.
• Slack: En primær overflate for interaksjon mellom personer og agenter, inkludert oppgaver, varsler og godkjenninger
• Agentforce Chat Client: Den tilpassbare, innebygde frontsiden for kunderettede samtaleagenter

For at agenter skal være virkelig effektive, kan de ikke eksistere i en silo. Agentforce omfatter to kjerneinteroperabilitetsmønstre:

• Agent2Agent (A2A) kommunikasjon: Denne protokollen styrer hvordan agenter i Salesforce-økosystemet kommuniserer med hverandre. Agentforce plattformen fungerer både som en A2A-klient og en server, for å lage og lytte på forespørsler, som er avgjørende for samarbeidende agent-sversjoner. Agenter kan konfigureres med relaterte agenter for å oppdage og kalle opp andre agenter med spesifikke kvalifikasjoner, noe som skaper et dynamisk og utvidbart system. Plattformhendelser fungerer som den langvarige, asynkrone transportmekanismen for disse A2A-meldingene.

• Model Context Protocol (MCP): Denne standarden sikrer at agenter ikke er låst i en enkelt plattform. MCP definerer et vanlig meldingsformat som tillater at agenter som bygger på forskjellige rammeverk, kommuniserer. I denne modellen fungerer Agentforce som en MCP-klient. En Salesforce-agent kan for eksempel spørre en ekstern agent som spesialiserer seg på komplekse logistiske beregninger, ved å sende den en MCP-kompatibel forespørsel. MuleSoft fungerer som gatewayen og transformerer den interne A2A-forespørselen til et eksternt MCP-formateret API-kall, som sikrer sømløs interoperabilitet på tvers av virksomheten.