--- title: "En agent som skriver till ERP: gränsen mellan att läsa och skriva" url: "https://hurukan.com/sv/blog/en-agent-som-skriver-till-erp" description: "Att läsa från ett registersystem är billigt och säkert. Vid skrivningen fallerar integrationer. Vad som måste finnas innan en agent får skriva, och var Hurukan drar gränsen." --- # En agent som skriver till ERP: gränsen mellan att läsa och skriva 20 oktober 2026·4 min läsning·Redaktionen En ekonomihandläggare sedd från sidan vid ett skrivbord med två skärmar, den ena visar en abstrakt blågrå huvudbok, en hand vilar på musen och ett utskrivet dokument hålls mot skärmen för jämförelse, svalt kontorsljus Ett inköpsteam kör en pilot. En agent läser öppna behov, lagersaldon och leverantörernas ledtider, och i tre veckor gör den precis det alla hoppats på: den föreslår beställningar, inköparna granskar dem, inköparna knappar in dem i ERP-systemet. Sedan ställer någon den självklara frågan. Varför skriver vi om det agenten redan har förberett? Ge den skrivbehörighet. En måndagsmorgon visar ERP-systemet två inköpsorder till samma leverantör, samma rader, två minuter isär. Den ena har leverantörens orderbekräftelse bifogad. Den andra är tom under huvudet. Kopplingen hade fått timeout vid första försöket och försökt igen; ERP-systemet tog emot båda halvorna av historien. Leverantören har redan börjat plocka mot en av dem, och ingen i rummet kan säga vilken. Inget i agentens resonemang var fel. Det som fallerade var skrivningen, och det är vid skrivningen varje integration har fallerat i tjugo år. Att läsa från ett registersystem är ett löst och nästan riskfritt problem: en läsning kan upprepas, cachas, jämföras och kastas. En skrivning ändrar den post som resten av företaget betraktar som sanningen, och posten har inget sätt att veta om ändringen var menad en gång eller två. ## Varför det är ett annat problem att skriva tillbaka **En läsning går att upprepa, en skrivning gör det inte.** Om en läsning misslyckas halvvägs läser man igen. Om en skrivning misslyckas halvvägs har man ett dokument som finns till hälften, och nästa försök antingen dubblerar den del som kom fram eller hoppar över den som inte gjorde det. Varje avstämningskörning vid månadsskiftet finns på grund av den här asymmetrin. **En halv skrivning är värre än ingen.** En inköpsorder med huvud och utan rader klarar ERP-systemets egen validering. Den låser också numret hos leverantören, dyker upp bland öppna åtaganden och plockas upp av nästa rapport. Felet är osynligt precis där det spelar roll. **Det finns ingen ångra-knapp i ett registersystem.** Ekonomisystem är byggda så att inget raderas. En felaktig bokning rättas med en återföring, en felaktig faktura med en kreditnota. Varje rättelse är ett nytt dokument med eget nummer och eget revisionsspår, så ett misstag gjort i maskinhastighet lämnar skräp i maskinhastighet som en människa får städa för hand. **En timeout gör en avsikt till två handlingar.** Kopplingen vet inte om systemet tog emot begäran och var långsamt med svaret, eller aldrig fick den. Utan ett sätt att säga “det här är samma begäran som förut” pekar det säkra valet och det korrekta valet åt motsatta håll. **Skrivningen går förbi innebörden.** ERP-systemet kontrollerar att fält är ifyllda och att koder finns. Det vet inte att den här kunden har en kreditspärr som beslutades på ett möte, eller att den här leverantören bara får användas för en anläggning. De reglerna lever i människor, och en direkt skrivning går rakt förbi dem. **Ingen kan säga vem som skrev.** Integrationsanvändaren som skapade ordern är ett tekniskt konto som delas av varje jobb som går genom det. Frågan “vem beslutade det här” har inget svar i posten, och det är ämnet för [en identitet för människor och agenter](https://hurukan.com/sv/blog/en-identitet-for-manniskor-och-agenter). ## Vad som måste finnas innan en agent skriver **Idempotenta förslag.** Varje avsedd ändring bär en identifierare, skapad före första försöket. Att skicka den två gånger måste ge ett resultat, och den mottagande sidan måste kunna säga “redan gjort” i stället för att göra om det. Om målsystemet inte klarar det måste lagret framför göra det, genom att kontrollera innan det skickar och registrera vad det skickade. **Ett godkännandesteg som en människa äger.** Inte en notis, ett beslut: förslaget, underlaget bakom det och risken det bär, godkänt, ändrat eller avvisat av någon vars namn hamnar i posten. Vilka skrivningar som kräver det är ingen smaksak; det står nedskrivet per åtgärd, och pengar som lämnar företaget eller ett ingånget åtagande står alltid på listan. **En logg som går att spela upp igen.** Vad agenten såg, vad den drog för slutsats, vad som föreslogs, vem som godkände, vad som skickades, vad som kom tillbaka. Skriven så att en människa månader senare kan följa kedjan, och strukturerad så att kedjan kan spelas upp mot en kopia av systemet när något måste rekonstrueras. **En gräns som ontologin gör uttrycklig.** De åtgärder som finns på varje affärsobjekt, de tillstånd varje objekt får befinna sig i, de regler en ändring måste uppfylla och vilka åtgärder som räknas som kritiska. En agent som bara agerar i de termerna kan inte skriva något modellen inte tillåter, och en människa som läser modellen ser exakt vad agenten får göra. **Avstämning efter skrivningen.** Läs tillbaka det som kom fram och jämför med det som skickades. De flesta dubbla bokningar hittas av leverantören eller revisorn; de borde hittas av systemet som skapade dem, inom några minuter. ## Ett test du kan göra i dag Ta den senaste integrationen som skriver in i ert ERP- eller ekonomisystem. Den behöver inte innehålla någon agent; en webbshopskoppling eller en uppladdning från ett kalkylblad duger. Ställ tre frågor till de som byggde den och skriv ner svaren. Vad händer om samma meddelande kommer två gånger? Vad händer om överföringen misslyckas efter rad tre av sju? Var är det registrerat vem som godkände dokumentet som skrevs, och på vilket underlag? Om ni har en testmiljö, prova sedan de två första och räkna rättelserna som krävs för att få posten tillbaka till sanningen. Om något svar är “det skulle vi få veta av leverantören” eller “det skulle vi se vid månadsskiftet” är integrationen inte redo för en agent, oavsett vad agenten kan läsa. Luckan finns inte i modellen; den finns i skrivvägen, och det är samma lucka för en människa som för programvara. Hurukan drar sin egen gräns här. Agenter förbereder, utformar och föreslår inom nedskrivna gränser, och de agerar bara i de termer ontologin definierar. Det som går till ekonomisystemet, eller till ett befintligt system som hålls i drift vid sidan av, går efter att en människa godkänt det, genom en koppling, med förslaget, beslutet och utfallet i en och samma logg. Kritiska operationer väntar på en människa i varje konfiguration. Varför ett registersystem inte kan anförtros att agera på egen hand utvecklas i [ett registersystem kan inte agera](https://hurukan.com/sv/blog/ett-registersystem-kan-inte-agera); skrivvägen är där [Hurukan](https://hurukan.com/sv) börjar. - registersystem - ERP - agenter - idempotens - godkännanden ## Läs vidare - [En identitet för människor och agenter: vem som får göra vad](https://hurukan.com/sv/blog/en-identitet-for-manniskor-och-agenter) - [Det levande tillståndet och registret: två minnen i ett operativsystem för företaget](https://hurukan.com/sv/blog/det-levande-tillstandet-och-registret-tva-minnen)