Fra en rodet Slack-tråd til et team af agenter: trin for trin
Af Team Two · Senest opdateret 23. september 2026 · 4 min. læsning
Det er let at beskrive AI-agenter i abstrakte vendinger. Det er mere nyttigt at følge én forespørgsel fra start til slut og se, hvad der sker i hvert trin, og hvor mennesker stadig er involveret.
Her er en forespørgsel, som de fleste support- og driftsteams vil kende. En customer success manager skriver dette i #support-kanalen:
»Kunden hos Nordlys siger, at de er blevet opkrævet to gange i august, at fakturaen viser den gamle plan, og de vil vide, om den nye SSO-funktion er inkluderet for dem. Kan nogen tjekke det?«
Tre spørgsmål i én besked: et faktureringstjek, et tjek af planen og et produktspørgsmål. Sådan håndterer Team Two det.
1. Beskeden sendes til den rigtige agent
CSM'en kan nævne en agent direkte, for eksempel @support, og så tager den agent forespørgslen. Skriver de bare i en kanal, som platformen følger, afgør Team Two, hvilken agent der skal håndtere den. Afhængigt af hvordan jeres workspace er sat op, klassificerer den enten beskeden og vælger den agent, der passer bedst, sender alt til en lead-agent, der kan uddelegere, eller følger routingregler, I har defineret ud fra kanal, nøgleord eller team.
Hvis klassificeringen ikke er sikker nok, falder den tilbage på jeres routingregler i stedet for at gætte. Uanset hvad bliver valget registreret, så I kan se, hvorfor en agent blev valgt.
2. Tråden bliver til en fastlåst samtale
Slack-tråden er knyttet til én samtale i Team Two. Hvert svar i tråden går til den samme agent, med hele historikken. Hvis CSM'en vender tilbage næste morgen og skriver »noget nyt?«, ved agenten præcis, hvad »nyt« henviser til.
3. Agenten læser jeres viden først
Før agenten svarer, søger den i de videnskilder, den har adgang til. Her kunne det være jeres dokument om priser og pakker, der angiver, hvilke planer der inkluderer SSO, og jeres FAQ om fakturering, der forklarer, hvordan dobbeltopkrævninger håndteres.
De relevante passager lægges ind i agentens kontekst sammen med kildernes titler, så svaret kan angive, hvor hver oplysning kommer fra. Søgningen omfatter kun dokumenter, som denne agent, på vegne af denne CSM, må læse.
4. Den fordeler arbejdet mellem specialister
Faktureringsspørgsmålet kræver andre værktøjer end produktspørgsmålet. Hvis supportagenten er sat op som lead-agent, kan den give dele af forespørgslen videre til specialistagenter, der kører parallelt:
- En faktureringsagent med læseadgang til jeres faktureringssystem tjekker opkrævningerne i august og den nuværende plan på kontoen.
- En produktagent med jeres release notes bekræfter, hvornår SSO blev lanceret, og hvilke planer der inkluderer det.
Hver specialist kører med CSM'ens rettigheder, ikke bredere. Specialister kan ikke selv oprette flere agenter, og der er grænser for, hvor mange der kører på én gang, og hvor længe. I kan se hver enkelt starte, arbejde og blive færdig i samtalevisningen.
5. Værktøjer laver opslagene, ikke gætværk
Faktureringsagenten gætter ikke på, om der var en dobbeltopkrævning. Den kalder et værktøj: en integration, I har tilsluttet, et internt API bag en webhook eller en MCP-server, jeres team driver. Værktøjskaldet og resultatet er en del af samtalens historik.
Hvilke værktøjer en agent har, er jeres beslutning. I et flow som dette giver mange teams kun agenterne læseadgang og lader refusioner og planændringer blive hos en person.
6. En person får et klart svar og beslutter
Lead-agenten samler det, der kom tilbage, og svarer i tråden, for eksempel:
- Der blev foretaget to opkrævninger den 3. august for den samme faktura. Den ene ligner en dobbeltopkrævning.
- Kontoen er stadig på den gamle plan, fordi opgraderingen aldrig blev bekræftet.
- SSO er inkluderet i den plan, de spurgte om, ifølge prisdokumentet.
- Forslag til næste skridt: refundér dobbeltopkrævningen og bekræft opgraderingen. Udkast til besked til kunden er vedhæftet.
CSM'en tjekker kilderne, udsteder refusionen i faktureringssystemet og sender udkastet, eller redigerer det først. Agenten gravede. Personen traf beslutningen.
7. Alt kan ses bagefter
Senere kan alle med adgang åbne samtalen og se, hvilken agent der håndterede den, hvilke dokumenter der blev søgt i, hvilke værktøjer der blev kaldt, og hvad de returnerede, samt hvor mange tokens der blev brugt. Administratorer ser forbruget per agent og per team. Selve samtalen forbliver privat for de involverede, medmindre de deler den.
Hvad eksemplet viser
Der er ingen magi her. Det er en række dele, der arbejder sammen: routing, en vedvarende tråd, vidensøgning der respekterer rettigheder, specialister med begrænsede værktøjer og en registrering af, hvad der skete. Et chatvindue giver jer én af de dele. Værdien kommer af dem alle sammen, i den kanal hvor forespørgslen kom ind.
Vil I se det på jeres egne dokumenter? Book en demo.
Ofte stillede spørgsmål
Kan agenter udføre handlinger, som at udstede en refusion?+
Kun hvis I giver dem et værktøj, der kan. Mange teams starter med værktøjer, der kun kan læse, og lader handlinger blive hos mennesker, og udvider derefter adgangen til specifikke opgaver med lav risiko.
Hvad hvis agenten vælger den forkerte specialist?+
I kan se hver routingbeslutning og uddelegering i samtalen og justere agentbeskrivelser eller routingregler. Medarbejderne kan også nævne den agent, de ønsker, direkte.
Virker det kun i Slack?+
Nej. Det samme flow virker i Microsoft Teams, e-mail, webappen og via API'et.
