Från en rörig Slack-tråd till ett agentteam: steg för steg
Av Team Two · Senast uppdaterad 23 september 2026 · 4 min läsning
Det är lätt att beskriva AI-agenter i allmänna termer. Det är mer givande att följa en förfrågan från början till slut och se vad som händer i varje steg, och var människor fortfarande är med.
Här är en förfrågan som de flesta support- och driftteam känner igen. En customer success manager skriver det här i kanalen #support:
”Kunden hos Nordlys säger att de har debiterats två gånger i augusti, deras faktura visar den gamla planen och de vill veta om den nya SSO-funktionen ingår för dem. Kan någon kolla?”
Tre frågor i ett meddelande: en faktureringskontroll, en plankontroll och en produktfråga. Så här hanterar Team Two det.
1. Meddelandet routas till rätt agent
CSM:en kan nämna en agent direkt, till exempel @support, och då tar den agenten förfrågan. Om de bara skriver i en kanal som plattformen bevakar avgör Team Two vilken agent som ska hantera den. Beroende på hur er arbetsyta är uppsatt klassificerar den antingen meddelandet och väljer den agent som passar bäst, skickar allt till en lead-agent som kan delegera, eller följer routingregler som ni har definierat per kanal, nyckelord eller team.
Om klassificeraren inte är tillräckligt säker faller den tillbaka på era routingregler i stället för att gissa. Oavsett vilket registreras valet, så att ni kan se varför en viss agent valdes.
2. Tråden blir en fastlåst konversation
Slack-tråden kopplas till en konversation i Team Two. Varje svar i den tråden går till samma agent, med hela historiken. Om CSM:en kommer tillbaka nästa morgon och skriver ”något nytt?”, vet agenten exakt vad ”nytt” syftar på.
3. Agenten läser er kunskap först
Innan agenten svarar söker den i de kunskapskällor den har åtkomst till. Här kan det vara ert dokument om priser och paketering, som anger vilka planer som inkluderar SSO, och er fakturerings-FAQ, som förklarar hur dubbeldebiteringar hanteras.
De relevanta avsnitten läggs in i agentens kontext tillsammans med källornas titlar, så att svaret kan ange var varje uppgift kommer ifrån. Sökningen omfattar bara dokument som den här agenten, när den agerar för den här CSM:en, får läsa.
4. Arbetet fördelas på specialister
Faktureringsfrågan kräver andra verktyg än produktfrågan. Om supportagenten är uppsatt som lead-agent kan den lämna delar av förfrågan till specialistagenter som arbetar parallellt:
- En faktureringsagent med läsåtkomst till ert faktureringssystem kontrollerar augustidebiteringarna och den nuvarande planen på kontot.
- En produktagent med era release notes bekräftar när SSO släpptes och vilka planer som inkluderar det.
Varje specialist arbetar med CSM:ens behörigheter, inte bredare. Specialister kan inte själva skapa fler agenter, och det finns gränser för hur många som körs samtidigt och hur länge. Ni kan följa hur var och en startar, arbetar och blir klar i konversationsvyn.
5. Verktyg gör uppslagen, inte gissningar
Faktureringsagenten gissar inte om det har skett en dubbeldebitering. Den anropar ett verktyg: en integration ni har anslutit, ett internt API bakom en webhook eller en MCP-server som ert team driver. Verktygsanropet och dess resultat ingår i konversationens historik.
Vilka verktyg en agent har är ert beslut. För ett flöde som det här ger många team agenterna enbart läsåtkomst och låter återbetalningar och planändringar ligga kvar hos en person.
6. En person får ett tydligt svar och beslutar
Lead-agenten sammanställer det som kom tillbaka och svarar i tråden, till exempel:
- Två debiteringar gjordes den 3 augusti för samma faktura. En av dem ser ut att vara en dubblett.
- Kontot har fortfarande den gamla planen eftersom uppgraderingen aldrig bekräftades.
- SSO ingår i den plan de frågade om, enligt prisdokumentet.
- Föreslaget nästa steg: återbetala dubbeldebiteringen och bekräfta uppgraderingen. Ett utkast till meddelande till kunden bifogas.
CSM:en kontrollerar källorna, gör återbetalningen i faktureringssystemet och skickar utkastet, eller redigerar det först. Agenten gjorde grävandet. Personen fattade beslutet.
7. Allt går att se i efterhand
Senare kan alla med åtkomst öppna konversationen och se vilken agent som hanterade den, vilka dokument som söktes igenom, vilka verktyg som anropades och vad de returnerade, samt hur många tokens som gick åt. Administratörer ser användningen per agent och per team. Själva konversationen förblir privat för de inblandade, om de inte delar den.
Vad exemplet visar
Inget av detta är magi. Det är ett antal delar som samverkar: routing, en beständig tråd, kunskapssökning som respekterar behörigheter, specialister med begränsade verktyg och en historik över vad som hände. Ett chattfönster ger er en av de delarna. Värdet kommer av att alla finns på plats tillsammans, i den kanal där förfrågan kom in.
Vill ni se det här på era egna dokument? Boka en demo.
Vanliga frågor
Kan agenter utföra åtgärder, som att göra en återbetalning?+
Bara om ni ger dem ett verktyg som kan göra det. Många team börjar med verktyg som bara läser och låter åtgärder ligga kvar hos människor, och breddar sedan åtkomsten för specifika uppgifter med låg risk.
Vad händer om agenten väljer fel specialist?+
Ni kan se varje routingbeslut och varje delegering i konversationen och justera agentbeskrivningar eller routingregler. Medarbetare kan också nämna den agent de vill ha direkt.
Fungerar det här bara i Slack?+
Nej. Samma flöde fungerar i Microsoft Teams, e-post, webbappen och via API:et.
