Fra en rotete Slack-tråd til et agentteam: en gjennomgang steg for steg
Av Team Two · Sist oppdatert 23. september 2026 · 4 min lesing
Det er lett å beskrive AI-agenter i det abstrakte. Det er mer nyttig å følge én forespørsel fra start til slutt og se hva som skjer i hvert steg, og hvor folk fortsatt er involvert.
Her er en forespørsel de fleste support- og driftsteam vil kjenne igjen. En customer success manager legger dette inn i #support-kanalen:
«Kunden hos Nordlys sier at de ble belastet to ganger i august, fakturaen viser den gamle planen, og de lurer på om den nye SSO-funksjonen er inkludert for dem. Kan noen sjekke?»
Tre spørsmål i én melding: en fakturasjekk, en plansjekk og et produktspørsmål. Slik håndterer Team Two det.
1. Meldingen rutes til riktig agent
CSM-en kan nevne en agent direkte, for eksempel @support, og da tar den agenten forespørselen. Hvis de bare poster i en kanal plattformen følger med på, avgjør Team Two hvilken agent som skal ta den. Avhengig av hvordan arbeidsområdet deres er satt opp, klassifiserer den enten meldingen og velger agenten som passer best, sender alt til en lead-agent som kan delegere, eller følger rutingregler dere har definert etter kanal, nøkkelord eller team.
Hvis klassifiseringen ikke er sikker nok, faller den tilbake på rutingreglene deres i stedet for å gjette. Uansett blir valget registrert, så dere kan se hvorfor en agent ble valgt.
2. Tråden blir en fast samtale
Slack-tråden er knyttet til én samtale i Team Two. Hvert svar i den tråden går til samme agent, med hele historikken. Hvis CSM-en kommer tilbake neste morgen og skriver «noe nytt?», vet agenten nøyaktig hva det gjelder.
3. Agenten leser kunnskapen deres først
Før den svarer, søker agenten i kunnskapskildene den har tilgang til. Her kan det være pris- og pakkedokumentet deres, som sier hvilke planer som inkluderer SSO, og faktura-FAQ-en, som forklarer hvordan doble belastninger håndteres.
De relevante avsnittene legges inn i agentens kontekst med kildetitlene, så svaret kan si hvor hvert faktum kommer fra. Søket dekker bare dokumenter som denne agenten, på vegne av denne CSM-en, har lov til å lese.
4. Den fordeler arbeidet på spesialister
Fakturaspørsmålet krever andre verktøy enn produktspørsmålet. Hvis supportagenten er satt opp som lead-agent, kan den gi deler av forespørselen videre til spesialistagenter som kjører parallelt:
- En faktureringsagent med lesetilgang til faktureringssystemet deres sjekker belastningene i august og den gjeldende planen på kontoen.
- En produktagent med utgivelsesnotatene deres bekrefter når SSO ble lansert og hvilke planer som inkluderer det.
Hver spesialistagent kjører med CSM-ens tilganger, ikke bredere. Spesialistagenter kan ikke selv opprette flere agenter, og det er grenser for hvor mange som kjører samtidig og hvor lenge. Dere kan se hver av dem starte, jobbe og bli ferdig i samtalevisningen.
5. Verktøy gjør oppslagene, ikke gjetning
Faktureringsagenten gjetter ikke på om det var en dobbel belastning. Den kaller et verktøy: en integrasjon dere har koblet til, et internt API bak en webhook, eller en MCP-server teamet deres drifter. Verktøykallet og resultatet er en del av samtaleloggen.
Hvilke verktøy en agent har, er deres beslutning. For en flyt som denne gir mange team agentene kun lesetilgang, og lar refusjoner og planendringer ligge hos en person.
6. En person får et tydelig svar og bestemmer
Lead-agenten setter sammen det som kom tilbake og svarer i tråden, for eksempel:
- Det ble gjort to belastninger 3. august for samme faktura. Den ene ser ut som en dobbel belastning.
- Kontoen står fortsatt på den gamle planen fordi oppgraderingen aldri ble bekreftet.
- SSO er inkludert i planen de spurte om, ifølge prisdokumentet.
- Foreslått neste steg: refunder den doble belastningen og bekreft oppgraderingen. Utkast til melding til kunden er vedlagt.
CSM-en sjekker kildene, gjennomfører refusjonen i faktureringssystemet og sender utkastet, eller redigerer det først. Agenten gjorde gravearbeidet. Personen tok beslutningen.
7. Alt er synlig i etterkant
Senere kan alle med tilgang åpne samtalen og se hvilken agent som håndterte den, hvilke dokumenter som ble søkt i, hvilke verktøy som ble kalt og hva de returnerte, og hvor mange tokens den brukte. Administratorer ser forbruk per agent og per team. Selve samtalen forblir privat for de involverte, med mindre de deler den.
Hva dette eksempelet viser
Ingenting her er magi. Det er en rekke deler som virker sammen: ruting, en vedvarende tråd, kunnskapssøk som respekterer tilganger, spesialistagenter med begrensede verktøy, og en logg over hva som skjedde. Et chatvindu gir dere én av disse delene. Verdien kommer av alle sammen, i kanalen der forespørselen kom inn.
Vil dere se dette på deres egne dokumenter? Book en demo.
Ofte stilte spørsmål
Kan agenter utføre handlinger, som å gjennomføre en refusjon?+
Bare hvis dere gir dem et verktøy som kan det. Mange team starter med verktøy som kun leser og lar handlinger ligge hos folk, og utvider deretter tilgangen for bestemte oppgaver med lav risiko.
Hva om agenten velger feil spesialistagent?+
Dere kan se hver rutingbeslutning og delegering i samtalen, og justere agentbeskrivelser eller rutingregler. Folk kan også nevne agenten de vil ha direkte.
Fungerer dette bare i Slack?+
Nei. Den samme flyten fungerer i Microsoft Teams, e-post, webappen og via API-et.
