När AI-agenten strular: reservplanen innan jobbet står still

Den farligaste AI-störningen är sällan den dramatiska. Det är den som bara gör vardagsflödet lite opålitligt: kundutkastet skickas två gånger, OCR-jobbet körs om utan koll, prompt-registret hämtar fel version eller en agent tappar kontext mitt i en ärendehantering.
Den 10-11 juni kom tre påminnelser samtidigt. Mistral hade aktiva degraderingar i Conversations API och AI Registry Prompts API. Google Workspace Gemini visade "Something went wrong" för användare i Workspace. Claude hade förhöjda fel på Haiku 4.5. Det här är inte en artikel om att en viss leverantör är dålig. Det är en artikel om att AI nu sitter så nära riktiga arbetsflöden att även en begränsad komponentstörning behöver en lokal reservplan.
Statussidan räcker inte som driftplan
En statussida säger ofta vilken tjänst som har problem. Den säger inte vilket av era arbetsflöden som kan göra fel sak.
Det är skillnaden som avgör. Om ett vanligt chattfönster blir långsamt väntar användaren. Om en agent är kopplad till kundmejl, interna dokument, OCR, prompt-versioner eller uppföljningsärenden kan samma störning skapa dubbelarbete, tappad kontext eller beslut på fel underlag.
En AI-agent är ett arbetsflöde där en modell kan läsa kontext, välja nästa steg och ibland använda verktyg. En komponentstörning är ett fel i en av delarna bakom flödet: modellen, sessionslagret, prompt-registret, OCR, en koppling, ett webbgränssnitt, en databas eller verktygskörningen. Ni behöver veta vilken del som bär vilket ansvar.
Tre färska signaler att ta på allvar
Mistral: tillståndsbärande agenter behöver annan reservväg än en enkel chatt. Mistrals statusaktivitet visade två pågående degraderingar: Conversations API från 10 juni 08:08 UTC och AI Registry Prompts API från 10 juni 20:50 UTC. Samma aktivitetssida visade även korta degraderingar för OCR API, Integrations API, AI Registry Skills API och Chat Completions för mistral-tiny-2407. Det ska inte beskrivas som ett generellt Mistral-API-stopp. Det praktiska är smalare och viktigare: flöden som bygger på konversationstillstånd eller prompt-register behöver veta vad som pausas, vad som kan köas och vad som får falla tillbaka till en enklare väg.
Källa: Mistral AI Status activity, Conversations API Degraded och AI Registry Prompts API Degraded
Google Workspace Gemini: ett appfel är inte samma sak som en API-störning. Google rapporterade att Gemini App in Workspace och Gemini Side Panel gav "Something went wrong"-fel den 10 juni. Slutrapporten nämnde felkoderna 1099 och 1076, ingen alternativ lösning under incidenten och en preliminär orsak: en databasfråga som påverkade hämtningen av Gemini Apps verktygskatalog. Det är viktigt att avgränsa: AI Studio-statusen visade inte en motsvarande Gemini API-incident i det här underlaget. För en organisation betyder det att ett Workspace-flöde kan vara trasigt även om utvecklar-API:et ser friskt ut.
Källa: Google Workspace Status: Gemini incident och Google AI Studio status
Claude: modellfel och agentmiljö är två olika saker som ändå möts i vardagen. Claude Status rapporterade förhöjda fel på Claude Haiku 4.5 den 10 juni. Incidenten påverkade claude.ai, Claude API, Claude Code och Claude Cowork och var löst 17:21 UTC. Samma dag publicerade Anthropic en genomgång av Claude Managed Agents där de trycker på sessionshistorik, isolerad körning, credentials, observability, webhooks och eventloggar. Det säger något användbart: produktion handlar inte bara om vilken modell som svarar bäst, utan om hur körningen kan spåras, pausas och återupptas.
Källa: Claude Status: Elevated errors on Claude Haiku 4.5 och Claude Managed Agents architecture
Reservplanen: sex frågor innan agenten får jobba själv
Börja inte med ett stort styrdokument. Ta ett verkligt flöde: kunduppföljning, dokumentrouting, transkriptsammanfattning, offerthjälp, intern service desk eller ett OCR-flöde. Svara sedan på sex frågor.
-
Vilken statuskomponent är flödet beroende av? Skriv inte bara "Mistral", "Gemini" eller "Claude". Skriv Conversations API, Workspace Gemini, Claude API, Claude Code, OCR API, prompt registry, connector eller webbyta.
-
Vad är ett säkert symptom? Bestäm vad systemet ska tolka som stopp: timeout, tomt svar, felkod, saknad promptversion, tappad session, låg träffsäkerhet eller upprepade retries. Ett diffust "AI:n känns konstig" räcker inte.
-
Vilka steg får aldrig köras om blint? Sändning av mejl, publicering, fakturahantering, uppdatering av kunddata och beslut som påverkar elever, kunder eller ekonomi ska ha en stoppspärr. AI kan förbereda. En människa bör godkänna när konsekvensen lämnar systemet.
-
Vad kan köas idempotent? Idempotent betyder att samma jobb kan köras en gång till utan att skapa dubbel effekt. En sammanfattning kan ofta köas om. Ett kundutskick kan inte köas om på samma sätt utan deduplicering och kvitto.
-
Vilken reservväg är acceptabel? Ibland är reservvägen en enklare modell. Ibland är det ett tillståndslöst API i stället för ett konversationsflöde. Ibland är det manuell rutin. Skriv också vad reservvägen inte får göra. Det är där många incidenter blir dyra.
-
Vem äger återstarten? Någon behöver läsa statusen, kontrollera loggarna, släppa kön och skriva en kort notis om vad som hände. Om ingen äger återstarten blir varje incident en gissningslek.
Ett enkelt exempel från vardagen
Tänk ett flöde där AI läser ett mötestranskript, föreslår uppföljning, hittar kundnamn i CRM och förbereder ett mejl.
Om transkriptanalysen faller kan jobbet köas. Om CRM-kopplingen faller ska agenten inte gissa kundnamn. Om mejlsteget faller ska inget skickas igen utan kvitto. Om promptregistret inte svarar ska flödet använda en känd version eller pausa. Och om hela konversationstillståndet verkar trasigt ska en människa se den senaste säkra loggen innan arbetet fortsätter.
Det låter mindre imponerande än "agenten sköter allt". Bra. Det är poängen. Riktiga arbetsflöden blir inte bättre av att AI får mer självförtroende än driftplanen tål.
Där Hammer brukar börja
För Hammer-kunder är det här ofta Tool Forge-arbete. Inte ännu en demo, utan en karta över flödet: statuskomponenter, loggar, ägare, stoppregler, fallback och vilka utdata som måste godkännas.
Om ni redan använder AI i kundsvar, dokument, intern support eller analys kan en första övning vara liten: välj ett flöde som skulle göra ont om det kördes fel i två timmar. Rita komponenterna. Skriv stoppläget. Bestäm vem som startar om. Först därefter är det värt att automatisera mer.
Vanliga frågor
Är en AI-statussida tillräcklig för drift?
Nej. Statussidan är en signal. Ni behöver också veta vilken komponent ert flöde använder, vad som pausas, vad som köas och vem som godkänner återstart.
När ska ett AI-arbetsflöde stoppas?
Stoppa flödet när det kan skapa dubbla utskick, fel kunddata, tappad kontext, okontrollerade retries eller beslut utan mänsklig granskning.
Vad är en bra fallback för agentflöden?
En bra fallback är tydligt avgränsad: använd känd promptversion, växla till enklare API där det är säkert, köa idempotent arbete och visa mänsklig granskning när flödet kan få extern effekt.
Vilka AI-flöden bör få en reservplan först?
Börja med flöden som rör kundkontakt, ekonomi, elev- eller personaldata, publicering, dokumentrouting, OCR eller system där AI kan skriva tillbaka till ett annat verktyg.
Smedjans nyhetsbrev
Få nya artiklar i inkorgen
Välj de ämnen som intresserar dig. Inget brus, max ett mejl i veckan.
Vi följer GDPR. Avsluta när du vill.


