En agent skriver en rapport, skapar en fil och skickar sedan ett meddelande. Sedan avbryts processen. Vid omstarten står det i chatten: ”Jag skickar resultatet nu.” Har meddelandet gått iväg? Måste filen skapas på nytt? En smidig konversationshistorik besvarar inte de här frågorna.
Den 19 oktober 2026 publicerade Vercel durable-harness. Projektet registrerar agentsteg och resultat så att arbetet kan återupptas, och behandlar avbrutna verktyg olika beroende på hur de beter sig vid en omkörning. Lanseringen är ett tillfälle att tänka noggrannare på arbetets tillstånd. Exemplet i den här artikeln är vår egen modell, inte ett test som vi har kört på projektet.
Avsikt, anrop och resultat är tre olika saker
En avsikt beskriver vad som ska hända härnäst. Ett påbörjat anrop visar att arbetet har inletts. Först ett lagrat resultat dokumenterar vad den egna processen vet om saken. Om de här nivåerna blandas ihop kan en omstart lätt leda till dubbelarbete eller hoppa över något som aldrig blev klart.
För rapporten räcker posten ”Export klar” därför inte. Den behöver en referens till den indata som användes och till den fil som faktiskt skapades. Om källdokumentet ändras kan en tidigare export fortfarande finnas kvar men inte längre vara rätt resultat. Återanvändning börjar med en tydlig koppling.
Step: export-17
Input: bericht-v3
State: completed
Result: bericht-v3.pdf
Next step: notificationDetta är ett läsbart kontrollkort, inte ett API-format. Det visar den väsentliga skillnaden mellan ett filnamn som nämns i en konversation och ett spårbart resultat av ett specifikt steg. I en verklig process skulle motsvarande fil behöva finnas på ett verifierbart sätt.
En säker omstart känner till de oklara tillstånden
Tänk dig tre punkter där processen kan avbrytas. Före exporten finns det ännu inget resultat. Efter exporten men före meddelandet kan filen återanvändas. Medan meddelandet skickas är läget svårare: mottagaren kan redan ha fått det, medan bekräftelsen saknas i den egna loggen.
Det lokala tillståndet ”ingen bekräftelse lagrad” bevisar därför inte ”inte skickat”. Att blint upprepa steget kan förvandla osäkerheten till ett dubblerat meddelande. En förnuftig process markerar steget som oklart och stämmer av med den externa tjänsten, förutsatt att tjänsten erbjuder en lämplig statusförfrågan.
Det är precis här som åtgärder skiljer sig åt. Att läsa en befintlig fil igen förändrar normalt ingenting för mottagaren. Ytterligare ett meddelande, en beställning eller en betalning kan däremot utlösa en ny effekt. En beständig logg löser inte de här skillnaderna å det externa systemets vägnar.
Idempotens är en egenskap hos operationen
En upprepningsbar operation bör vara identifierbar på ett sådant sätt att samma begäran inte av misstag skapar ett nytt jobb. Om en tjänst stöder en nyckel som är avsedd för detta måste samma logiska operation behålla samma nyckel. En nyckel som genereras på nytt vid varje omstart skulle förlora just detta samband.
Om och hur detta fungerar tillförlitligt beror på det faktiska tjänsteavtalet. Ett agentramverk kan inte göra en åtgärd säkert upprepningsbar bara genom att ge den en vänlig etikett. Inte heller är ”exakt en gång” en självklar följd av att loggar lagras beständigt.
Ett litet avbrottstest förklarar mer än en lyckad körning
I din egen utvecklingsmiljö ligger en ofarlig övning nära till hands: ersätt först sändningssteget med en lokal logg, avbryt processen vid de tre nämnda punkterna och se vilka tillstånd som finns vid omstarten. Anteckna i förväg vilka steg som får upprepas och vilka som kräver en kontroll. Använd inte riktiga betalningar eller meddelanden för den här första undersökningen.
Insikten ligger inte i en påhittad framgångsgrad. Den ligger i att kunna namnge tillståndsgränserna i den egna processen. Durable-harness är ett konkret tekniskt angreppssätt för detta. En bra omstart börjar dock alltid med samma fråga: vad har bevisligen hänt, och var vet vi ännu inte?
Källor och status
Research och dokumentation per den 25 oktober 2026. Att göra varje harness beständig.
