Långlivade AI-agenter: vad durable agents är och när de lönar sig

En långlivad AI-agent, på engelska ofta kallad durable agent, är en huvudagent som kan behålla arbetskontext över flera körningar. Den glömmer inte uppdraget när en session tar slut. Den kan hålla fast vid samma repo, samma branch och ofta samma pull request, och ta emot en uppföljning i stället för att börja om.

Det är skillnaden mot en vanlig engångsagent som får en uppgift, levererar och släpper minnet. Det är också skillnaden mot att starta flera parallella agenter som var och en har sitt eget fönster. De tre modellerna konkurrerar inte alltid. En långlivad huvudagent kan samordna subagenter, om plattformen stöder det.

En långlivad agent är inte automatiskt bättre. Den är mer ihärdig. Det är både vinsten och risken.

Hela översikten finns i guiden om AI: starta här. Här är frågan mer konkret: när tjänar ett svenskt småföretag eller ett medelstort företag på att låta en agent leva vidare, och när ska ni hellre stänga den?

Vad en långlivad agent faktiskt gör

Begreppet durable dyker upp i flera leverantörers dokumentation, men det betyder inte alltid exakt samma sak. Gemensamt är kontinuitet.

I praktiken betyder det oftast tre saker:

1. Samma agentidentitet. Ni skickar inte en ny, anonym körning varje gång. Ni återupptar samma agent.
2. Samma arbetsyta. Repo, branch, öppna filer, testmiljö och ibland en PR följer med.
3. Samma samtalsspår. Tidigare beslut, fel och uppföljningar finns kvar, i original eller som komprimerad sammanfattning.

Ett exempel från kodvärlden: ni ber agenten lägga till en kontaktfunktion på sajten. Den skapar en branch, skriver kod och öppnar en PR. Nästa dag skriver ni “formuläret skickar inte på mobil”. En engångsagent behöver hela bakgrunden på nytt. En långlivad agent fortsätter i samma PR.

Anthropic beskriver kärnproblemet bakom det här i Effective harnesses for long-running agents: komplexa uppdrag ryms sällan i ett enda kontextfönster. Varje ny session börjar utan minne, ungefär som skiftarbete där nästa person inte vet vad som hände nyss. Utan en tydlig överlämning mellan körningarna gissar agenten, gör för mycket på en gång eller deklarerar jobbet klart för tidigt.

OpenAI Agents SDK talar om sessions som ett lager för arbetskontext, och om durable execution när en körning kan behöva vänta, återupptas eller överleva omstarten av en process (Running agents). Det är en mer teknisk variant av samma idé: tillståndet ska inte dö med den enskilda körningen.

En plattform kan kalla samma mönster för cloud agent, background agent eller durable agent. Namnet spelar mindre roll än om ni kan återkomma till samma arbete utan att tappa branch, PR och beslut.

Det här är alltså inte samma sak som att “AI minns er” i största allmänhet. Det är ett arbetssätt där huvudagenten får en livslängd som matchar uppdraget.

Tre modeller att hålla isär

Det är lätt att blanda ihop tre olika sätt att organisera arbetet. De löser olika problem.

Engångsagent vs långlivad agent

Flera parallella agenter

Anthropic skiljer i Building effective agents mellan workflows (fasta steg i kod) och agents (modellen styr själv vilka verktyg den använder). Parallella arbetare och en orkestrerande huvudagent är ett känt mönster där, kallat orchestrator-workers. En långlivad agent är hur ni låter just den huvudagenten överleva mer än en körning.

I Claude Code-dokumentationen om subagenter är poängen tydlig: en subagent får ett eget kontextfönster så att sökresultat, loggar och filinnehåll inte fyller huvudsamtalet. Den lämnar tillbaka en sammanfattning. Det är isolation, inte livslängd.

Samma distinktion syns i en del API:er i molnet. Cursor beskriver till exempel sitt API som en durable agent plus en körning per prompt: uppföljningen går till samma agent och använder aktuell konversation och arbetsyta (Cloud Agent API). Det är ett leverantörsexempel, inte en branschstandard. Andra verktyg löser samma behov med sessioner, sparad minnesfil eller en öppen PR.

Durable och subagent är inte motsatser

Det här är den vanligaste missuppfattningen.

En långlivad huvudagent svarar på frågan: vem äger uppdraget över tid?

En subagent svarar på frågan: vem gör den här sidouppgiften utan att smutsa ner huvudkontexten?

Ni kan alltså ha:

• en engångsagent utan subagenter
• en engångsagent som släpper iväg subagenter under en enda session
• en långlivad huvudagent som själv gör allt
• en långlivad huvudagent som samordnar subagenter över flera dagar

Den sista varianten är ofta den mest användbara i ett verkligt webbprojekt. Huvudagenten håller plan, branch och PR. En subagent kan söka i dokumentationen. En annan kan köra tester. En tredje kan göra en oberoende genomgång av diffen. Huvudagenten tar emot korta rapporter och går vidare.

Anthropic skriver i Effective context engineering for AI agents att subagenter är ett sätt att hantera den begränsade uppmärksamhetsbudgeten: sidouppgiften kan sluka tiotusentals tokens, medan huvudagenten bara får den korta slutsatsen. Det är ett argument för isolation, inte mot kontinuitet.

Praktisk tumregel: låt huvudagenten vara långlivad när uppdraget är långlivat. Låt sidouppgifter vara korta.

När företaget tjänar på respektive modell

Det här är ett processbeslut, inte ett varumärkesval. Verktyget ni råkar ha (chatt, kodredigerare, molnagent) spelar mindre roll än hur uppdraget ser ut.

Välj engångsagent när

• uppgiften ryms i en tydlig brief och ett svar
• ni vill ha ett utkast till en text, en FAQ eller en rubriklista
• ni inte vill ge agenten skrivrätt i repo eller produktion
• resultatet är lätt att kasta och göra om

Exempel: “Föreslå fem H2 för en sida om öppettider.” Det ska inte leva i tre dagar.

Välj långlivad agent när

• samma uppdrag kommer tillbaka med uppföljningar
• arbetet sitter i Git: branch, commits, PR, CI
• ni behöver att agenten minns vad som redan är avfärdat
• en människa kan titta till arbetet vid fasta grindar, inte varje minut

Exempel: “Bygg landningssidan, rätta layouten på mobil, fixa testfelen, uppdatera meta.” Det är ett uppdrag, inte fyra osammanhängande chattar.

Välj flera agenter eller subagenter när

• research skulle drunkna i implementationshistoriken
• QA ska göras av någon som inte just skrev koden
• två oberoende spår kan köras utan att röra samma filer
• ni uttryckligen vill ha en andra bedömning innan godkänt

Exempel: huvudagenten implementerar. En subagent läser bara testerna och rapporterar vad som faktiskt failar. En annan jämför copy mot er tonalitet.

Kodredigerare med inbyggd agent, som vi beskriver i Cursor-guiden, är ett typiskt ställe där de här valen dyker upp. Samma logik gäller i andra miljöer: Claude Code, Agents SDK, interna orkestreringar. Välj modell efter uppdraget, inte efter logotypen.

Ett konkret flöde: research till release

Tänk ett vanligt webbuppdrag för ett tjänsteföretag: ny tjänstesida, ny sektion på startsidan, eller en bugg i formuläret. Så kan de tre modellerna se ut i samma kedja.

1. Research

Engångsagent. Ni klistrar in befintlig copy, målgrupp och tre konkurrenters sidor. Agenten föreslår vinkel och disposition. Ni sparar det som duger i briefen. Sedan stänger ni chatten.

Långlivad agent. Researchen är första körningen i ett uppdrag som ni redan vet kommer att bli kod och PR. Agenten sparar slutsatsen i uppdragets arbetsyta, inte bara i er skalle.

Subagent. Huvudagenten delegerar “sammanfatta tre källor, lämna bara det som påverkar dispositionen”. Sökbruset stannar i sidospåret.

Research utan mänsklig avgränsning blir snabbt en hög med länkar. Briefen ägs av er, inte av agenten. Se AI-arbetsflöde för hur brief, utkast och grindar hänger ihop oavsett agentmodell.

2. Implementation

Här lönar sig den långlivade agenten oftast, om ni faktiskt ändrar kod eller strukturerade filer.

Ett vettigt mönster:

1. Människa sätter mål, gränser och vad som inte får brytas.
2. Agenten jobbar i en ny branch, inte mot produktion.
3. Ändringar kommer som diff, inte som “lita på att det blev bra”.
4. Uppföljningar går till samma agent: “mobilmenyn täcker loggan”, “alt-text saknas”, “tabellen går utanför på 375 px”.

Anthropics långkörningsexperiment pekar på att agenten ska göra inkrementella framsteg och lämna miljön i ett skick som en kollega kan ta över: commits, progressanteckningar, inte halvfärdiga drag mitt i en fil. Det är samma hygien ni vill ha av en junior utvecklare.

Parallella implementationsagenter i samma filer är däremot en klassisk källa till mergekonflikter. Dela på uppgifter, inte på samma komponent.

3. QA

Låt inte samma röst som skrev koden sätta godkänt.

AI QA handlar om innehåll. Samma princip gäller kod och publicering: checklista, andra ögon, stopp innan något går ut.

Bra uppdelning:

Ett återkommande fel i långa agentsessioner är för tidigt PASS: agenten ser att mycket är gjort och markerar uppdraget som klart. Anthropic såg exakt det när senare sessioner tittade sig omkring, såg framsteg och förklarade jobbet färdigt. Motmedlet är en yttre sanning: testlista, checklista, CI, eller en människa som säger nej.

4. Korrigering

Det är här den långlivade modellen visar sig.

En uppföljning som “CI är röd på lint” eller “kunden vill ha annan rubrik” ska inte föda en ny agent som inte känner PR:en. Den ska gå tillbaka till huvudagenten, med samma branch. Annars får ni två konkurrerande sanningar.

Begränsa ändå varje uppföljning. “Fixa allt som är fel” är en inbjudan till att agenten rör saker ni inte bad om. “Rätta lintfelen i de filer PR:en redan ändrar” är ett uppdrag.

5. Release

Release är ett mänskligt beslut. Punkt.

Agenten kan förbereda: sammanfatta diffen, peka på risker, köra build, föreslå changelog. Den ska inte trycka merge till produktion, byta DNS eller skicka kundmejl utan att någon ansvarar.

Har agenten koppling till externa system via MCP eller liknande protokoll blir den gränsen ännu viktigare. Model Context Protocol är byggt så att verktyg kan kräva samtycke före körning. Det är inte byråkrati. Det är hur ni behåller kontroll när en långlivad agent får mer yta att verka på.

Risker och styrning ni måste sätta innan ni skalar

En långlivad agent med skrivrätt är närmare en medarbetare med nyckel än en chattruta. Då behövs samma typ av ram som i en AI-policy, plus några punkter som gäller just agenter.

Kontextdrift

Ju längre historiken blir, desto mer gammalt skräp följer med: tidiga gissningar, övergivna planer, sammanfattningar som slätar över viktiga nej. Agenten kan börja optimera mot en bild av uppdraget som inte längre stämmer.

Gör så här:

• Skriv det aktuella målet i uppdragets arbetsyta, inte bara i chatten.
• När inriktningen ändras: säg det uttryckligen, och be agenten uppdatera planen.
• Starta en ny agent om uppdraget byter karaktär. Kontinuitet är inte ett plåster på fel brief.

För tidigt godkänt

Kräv verifiering mot något utanför agentens självförtroende: tester, checklista, förhandsgranskning, en kollega. “Jag har testat” i en agentsvarstext är inte bevis.

Behörigheter

Ge minsta möjliga yta. Läs i repo är en sak. Skrivrätt i produktionsbranchen, tillgång till kundregister eller öppna mejlutskick är en annan. MCP och liknande kopplingar ska granskas per server och per verktyg, inte slås på i klump.

Kostnad

En långlivad agent som tänker, söker och kör tester i loop drar tokens. Flera subagenter multiplicerar räkningen. Sätt en övre gräns per uppdrag och en människa som får stoppa körningen. OpenAI noterar att långlivade körningar och mänskliga stopp just är till för att arbetet kan spänna över väntan och omstarter, inte för att det ska få pågå obegränsat.

Branchkonflikter

Två agenter på samma branch, eller en agent plus en människa som pushar utan att säga till, ger konflikter. En huvudagent per PR är en bra default. Parallellt arbete hör hemma i olika brancher eller i rena läsuppdrag.

Mänskliga beslut

NIST:s AI Risk Management Framework är frivilligt, men riktningen är användbar även för ett litet team: någon ska äga vad systemet får göra, riskerna ska vara uttalade, och det ska gå att ingripa. För er räcker det ofta med tre namngivna saker: vem som får starta agenten, vem som får godkänna PR, och vem som får stoppa körningen.

Verifiering och revisionsspår

Spara det som gör att ni kan svara på “vad hände?” om en vecka:

• länk till agentkörningen eller sessionen
• branch och PR
• vilka uppföljningar som skickades
• vem som godkände merge
• vilka tester som kördes

Utan det spåret blir den långlivade agenten en svart låda som bara den som råkade sitta vid tangentbordet minns.

Checklista: bör ni välja en långlivad agent?

Kryssa i tysthet. Fem ja är en stark signal. Två ja räcker sällan.

1. Uppdraget lever mer än en session. Ni vet redan att det blir “och så det här också” i morgon.
2. Arbetet har en Git-sanning. Branch, commits och PR slår chattminne.
3. Ni kan peka ut vad som inte får röras. Produktion, kunddata, betalning, DNS.
4. Det finns en granskare som inte är samma person som startade agenten, eller åtminstone inte samma dag.
5. Det finns ett sätt att säga nej till godkänt som inte är agentens egen sammanfattning: test, checklista, förhandsvisning.
6. Behörigheterna är minsta möjliga. Skriv i en egen branch. Inte i main. Inte i mejlsystemet.
7. Ni har ett tak för tid och kostnad. En agent som “nästan är klar” i tre dagar är oftast fel modell eller fel brief.
8. Uppföljningar kan gå till samma agent. Annars har ni ingen nytta av att den är långlivad.
9. Sidouppgifter kan isoleras. Research och QA ska inte drunkna i implementationslogg.
10. Ni kan förklara uppdraget för en kollega på fem meningar. Om ni inte kan det kan inte agenten heller bära det över tid.

Om listan landar i nej: använd en engångsagent, eller skippa agenten och gör uppgiften själva. En enklare modell är inte ett nederlag. Anthropics råd i agentartikeln är just att börja enkelt och bara lägga på orkestrering när det faktiskt förbättrar utfallet.

Ett köpbeslut utan leverantörsreligion

Ni köper inte “durable” som en magisk egenskap. Ni köper ett arbetssätt.

Fråga leverantören eller er byrå tre saker, oavsett produktnamn:

Pris per månad säger lite. En billig plan med obegränsad agent som skriver i fel branch är dyr. En dyrare plan med grindar, isolation och PR-flöde kan vara billigare i tid och reparationer.

För många små team är steget före långlivade agenter fortfarande det ni redan känner: en brief, ett utkast, en människa som läser, versionshantering. Agenten kommer in när den kedjan redan sitter, och när samma tekniska uppdrag faktiskt återkommer.

Kort sammanfattning

En långlivad AI-agent behåller uppdrag, arbetsyta och uppföljningar över flera körningar. En engångsagent är rätt när uppgiften är liten. Flera agenter eller subagenter är rätt när sidouppgifter ska isoleras. De två sista är inte motsatsen till den första.

Företag tjänar på den långlivade modellen när arbetet redan lever i Git, när uppföljningar är naturliga, och när någon människa äger godkänt, behörighet och release. Utan de grindarna får ni kontextdrift, för tidigt PASS och en räkning som växer i tysthet.

Vill ni gå igenom vilket arbetssätt som passar er sajt och er vardag? Kontakta oss så tittar vi på läget utan att sälja in en viss agentplattform.

Källor och vidare läsning

1. Anthropic: Building effective agents. Workflows kontra agenter, orkestrering och när komplexitet faktiskt lönar sig.
2. Anthropic: Effective harnesses for long-running agents. Varför långa uppdrag faller mellan kontextfönster, och hur stegvisa framsteg plus verifiering motverkar för tidigt godkänt.
3. Anthropic: Effective context engineering for AI agents. Kontext som begränsad budget, subagenter som isolation.
4. Claude Code Docs: Subagents. Subagenten får eget fönster och lämnar en sammanfattning till huvudagenten.
5. OpenAI Agents SDK: Running agents. Sessions, mänskliga stopp och durable execution när körningar behöver överleva väntan eller omstart.
6. NIST: AI Risk Management Framework. Frivillig ram för styrning, mänsklig översyn och ansvar.

Funktioner, API:er och produktnamn ändras. Kontrollera alltid den officiella dokumentationen innan ni tecknar eller skalar upp.