En demo visar att något är möjligt. Produktion ställer en annan fråga: vad händer den dagen agenten har fel, API:et är nere och den som byggde den är på semester? Det här är listan vi går igenom innan en agent får röra riktiga kunder.
Behörigheter: minsta möjliga
Agenten ska ha exakt de rättigheter uppgiften kräver, inte de som råkade följa med API-nyckeln. Läsrätt där det räcker, skrivrätt bara i de fält den faktiskt uppdaterar, och ett eget konto så att det syns i loggarna vem som gjorde vad.
Ett eget konto gör också avstängningen enkel. Behöver ni stoppa agenten mitt i natten ska det vara en knapp, inte en utredning.
Godkännanden: var går gränsen?
Vi delar alltid upp handlingarna i tre högar. Det agenten får göra själv, det som kräver att en människa godkänner, och det den aldrig får göra. Betalningar, krediteringar, löften till kund och raderingar hamnar i mitten eller sist.
Gränsen ska skrivas ned och sättas av verksamheten, inte av utvecklaren. Det är en affärsfråga förklädd till en teknisk inställning.
Loggar, mätning och kostnadstak
Varje handling loggas med tidpunkt, indata, beslut och resultat. Det är både felsökning och ansvarsfrihet: utan loggen är det ord mot ord om vad som hände.
Mät samtidigt något som betyder något för verksamheten. Andel ärenden som gick hela vägen, hur ofta en människa behövde rätta, hur lång tid det tog. Antal anrop till modellen är en driftssiffra, inte ett resultat.
Sätt ett tak för kostnaden per dygn med larm långt innan taket nås. Det som skenar är nästan aldrig priset per anrop, det är ett flöde som börjar anropa sig självt.
Beredskap och överlämning
Bestäm i förväg vem som larmas, hur agenten pausas och vad som händer med ärenden under tiden. Ett flöde som faller tillbaka på en människa är inte ett misslyckande, det är designen.
Och dokumentera så att någon annan än byggaren kan ta över. Vi lämnar över konfiguration, färdigheter och integrationer vid varje leverans. Läs mer under Deploy Agents, eller boka ett samtal om ni har en agent som fungerar bra i demo men inte riktigt vågar gå live.
Testa som om det vore skarpt
Innan en agent får arbeta mot kund kör vi den parallellt mot riktiga ärenden utan att något skickas. Utkasten granskas av den som annars gör jobbet, och vi räknar hur ofta agenten hade haft rätt, hur ofta den hade varit nära och hur ofta den hade gjort fel.
Det är också då ramarna justeras. Nästan alltid visar det sig att ett par ärendetyper ska lämnas till en människa direkt, och att några andra kan släppas helt fria.
Det som går sönder i verkligheten
Det är sällan modellen. Det är ett API som börjar svara långsammare, ett fält som byter namn efter en uppdatering, en bilaga i ett format ingen tänkte på, eller en användare som skriver på ett språk flödet inte var byggt för.
Därför bygger vi alltid in ett fallback: när agenten inte är säker, eller när ett verktyg inte svarar, hamnar ärendet hos en människa med en notering om varför. Tyst misslyckande är det enda oacceptabla utfallet.
Vanliga frågor
Hur mycket övervakning behövs? Larm på fel, på kostnad och på att flödet faktiskt kör. Det är grunden. Därefter en månadsvis genomgång av vad som hamnade hos människor och varför.
Vad gör vi när modellen uppdateras? Kör era sparade testärenden igen och jämför. Det är därför uppsättningen med verkliga exempel är värd att bygga tidigt.
Vem ansvarar när agenten har fel? Ni, som alla andra system i verksamheten. Därför ska godkännandesteget ligga på allt som får konsekvenser, och loggen ska visa vad som hände.
Går det att börja smalt? Ja, och det är vår rekommendation. Ett flöde, en kanal, en typ av ärende. Bredda när siffrorna visar att det bär.