När AI-agenter flyttar in i flödena måste datan kunna svara själv

AI-agenter är på väg in i integrationsflödena. De ska svara kunder, boka om leveranser och fatta beslut som hittills har krävt en människa. Men en agent gör inte som en människa när den är osäker: den frågar ingen.

Det spelar roll, eftersom samma ord ofta betyder olika saker i olika system. Ta begreppet "levererad":

• I affärssystemet är en order levererad när den har fakturerats.
• I lagersystemet är den levererad när den har plockats och lämnat porten.
• Hos transportören är den levererad först när mottagaren har kvitterat.

Tre system använder samma ord för tre olika saker. Hittills har det fungerat ändå, för det har alltid varit en människa som läst datan. Den som ser tre olika svar blir misstänksam och ringer någon som vet. Kunskapen om vad datan betyder har legat i loggar ingen öppnar, i gamla mappningsbeskrivningar och i huvudet på ett par erfarna kollegor.

En agent ringer ingen. Den här artikeln handlar om vad som händer då, och om varför en stor del av lösningen redan finns i era integrationer.

Det som ändrats är läsaren, inte datan

En agent får en uppgift, hämtar det den hittar och agerar. Finns ingen definition att slå upp väljer den den som verkar rimlig. Det är inte ett fel i modellen. Det är vad som händer när ett beslut ska fattas utan den kontext beslutet kräver.

Tänk dig en kundtjänstagent som ska svara på "var är min order?". Den frågar affärssystemet, ser att ordern är levererad och säger det till kunden. Ordern är fakturerad, men den står fortfarande kvar på lagret.

Se webbinariet: Var är min order? AI:s svar på retailers största tidstjuv

Det här är ett resonemang, inte en mätning. Jag har ännu inte sett en organisation råka illa ut på just det här sättet, sannolikt för att de flesta kör sin första agent mot ett enda välkänt flöde där någon vet vad fälten betyder. Frågan är vad som händer vid den femte agenten, den som rör sig mellan system som ingen enskild person längre har hela bilden av.

Då blir en gammal administrativ skuld en operativ risk. Det är inte ett dataproblem utan ett betydelseproblem, och det uppstår mellan systemen snarare än i något av dem.

Betydelsen finns redan, men den är passiv

Det som brukar förvåna är att de flesta organisationer inte behöver skapa metadatan, alltså beskrivningen av vad datan betyder, från grunden. Den finns redan inbyggd i de integrationer ni har i dag.

Varje mappning mellan två system är ett påstående om vad ett fält betyder. Varje transformation är en regel för hur en betydelse översätts till en annan. Den som byggt era integrationer har redan skrivit ner stora delar av organisationens begreppsapparat, fast utspridd i tusen enskilda beslut i stället för i ett dokument.

En reservation, eftersom den avgör hur mycket arbete som återstår: en mappning är alltid sann om format men bara ibland om betydelse. I ett landskap som vuxit i femton år ser vissa fält ut som de gör för att mottagarsystemet ville ha det så, inte för att det är vad saken heter. Den sortens mappning är en fossil, inte ett begrepp. Betydelsen finns alltså till största delen. Resten är arbete, men i en helt annan storleksordning än att börja från ett tomt dokument.

Att aktivera betydelsen är att flytta den från dokumentation till drift: skördad löpande ur de system som faktiskt är kopplade, uppdaterad när flödet ändras och lagrad strukturerat i stället för i en loggrad. Skillnaden syns tydligt i en karta över integrationerna. En karta byggd på hur någon kategoriserade flödet den dag det togs i drift visar en avsikt, och börjar åldras samma dag. En karta byggd på det som faktiskt körts den senaste månaden visar verkligheten. Den första är ett dokument, den andra ett instrument. Varför flödet finns måste någon fortfarande skriva, men vad som faktiskt rör sig behöver ingen underhålla.

En gammal mekanism med rätt form

Hos oss heter det nodattribut, och det har funnits i iCore-plattformen sen första början. Det byggdes inte för det här.

En nod är en ögonblicksbild av datan vid en viss punkt i ett flöde. Ett nodattribut är ett namngivet fält kopplat till den noden, lagrat som strukturerad data. Ursprungligen användes det för att styra flödet: vart ska det här ta vägen?

Två saker gör att samma mekanism nu bär något större. Namnet sätts med avsikt av den som bygger flödet. Det är en utsaga, inte ett avtryck av vad ett mottagarsystem råkade vilja ha. Och ögonblicksbilden säger inte bara vad något betyder, utan vad det betydde just där. Den levererade ordern är fakturerad i en nod, plockad i nästa och kvitterad i den tredje. Det som utan kontext ser ut som tre motstridiga sanningar blir en ordnad kedja.

Det är ingen ny produkt. Det är en tjugo år gammal funktion som fått en renässans, för att en ny sorts läsare flyttat in i flödena. Jag tycker att det är en bättre historia än om vi hade byggt något för AI.

Det tredje lagret heter förtroende

Hösten 2024 skrev jag en serie om att dela upp integrationsdata i ett operativt och ett analytiskt lager. Den slutade i en mening jag fortfarande står för: extraherar man fel saker får man kattguld, och kattguld glänser precis tillräckligt för att någon ska bygga en rapport på det.

Det jag inte namngav då var vad som avgör skillnaden. Lagren hålls inte ihop av att data flyttas mellan dem, utan av att betydelsen flyttas med. Betydelsen är det tredje lagret – och det enda av de tre som inte går att köpa färdigt.

På en CIO-konferens i höstas hörde jag två stora svenska bolag beskriva exakt det här. Inget av dem sa metadata. Båda sa förtroende. De har bättre ord än jag: det handlar om att någon ska våga agera på en siffra utan att först ringa och kolla.