Den neste brukeren av programvaren din er en KI-agent. Er arkitekturen din klar?

Se for deg en KI-agent som håndterer en kundeklage på en faktura. Den leser klagen, sjekker kontohistorikken og vurderer at kunden bør få kreditert et beløp. Alt på noen sekunder.

Imponerende. Be den nå faktisk kreditere beløpet.

Kundeavtalen ligger i et annet system. Godkjenningsreglene er gjemt i programkoden. Faktureringsverktøyet forventer at en person klikker seg gjennom flere skjermbilder.

Agenten forstår hva som må gjøres, men arkitekturen lar den ikke fullføre oppgaven.

Det er et problem jeg forventer at flere virksomheter vil støte på etter hvert som agentisk KI tas i bruk i produksjon. Det merkelige er imidlertid at hindringen for å fullføre oppgaven har svært lite å gjøre med hvor intelligent agenten er.

I årevis har vi modernisert bedriftsprogramvare for menneskene som bruker den. Nå må vi modernisere den for agentene som i stadig større grad kommer til å betjene den.

Brukergrensesnittet var aldri hele produktet

Tenk på hvordan bedriftsprogramvare fungerer i dag. Folk åpner applikasjoner, navigerer i dashbord, tar beslutninger og flytter arbeid fra ett system til et annet. Brukergrensesnittet er måten de samhandler med virksomheten på.

En agent trenger ikke nødvendigvis disse skjermbildene. Den kan hente informasjon og sette i gang handlinger via API-er, Model Context Protocol-servere (MCP) og andre programmatisk tilgjengelige grensesnitt. Dette er en del av overgangen til en hodeløs arkitektur.

Men hodeløs betyr ikke at applikasjonen forsvinner. Dataene, forretningsreglene, tilgangsrettighetene og kravene til etterlevelse er fortsatt viktige. Jeg vil hevde at de er enda viktigere.

I årevis har programvareleverandører bygget konkurransefortrinn rundt gjennomarbeidede brukergrensesnitt, brukervaner og kostnadene ved å lære opp ansatte på nytt. Disse fortrinnene svekkes når agenter utfører mer arbeid uten å åpne applikasjonens brukergrensesnitt. Det som blir mer verdifullt, er det underliggende registretsystemet: pålitelige data, validert domenelogikk, operasjonell styring og transaksjoner som kan revideres.

Det får også kommersielle konsekvenser: Bedriftsapplikasjoner til en verdi av opptil 234 milliarder dollar kan bli utsatt for forstyrrelser fra agentisk KI innen 2030. Det er utgifter som står i fare for å bli forstyrret, ikke utgifter som garantert forsvinner. Og når agenter utfører arbeid som tidligere ble gjort av mennesker i dashbord, kan prising per bruker i økende grad vike for prismodeller basert på bruk, handlinger eller resultater.

For programvareleverandører er dette en utfordring for forretningsmodellen. For virksomheter som er avhengige av applikasjonene deres, er det en arkitekturutfordring.

Vi har modernisert delene, ikke arbeidsflyten

De fleste virksomheter har modernisert i årevis. Ett team oppdaterer eldre applikasjoner. Et annet samler fragmenterte data på en moderne plattform. Et tredje bygger integrasjoner eller nøyer seg med å fornye brukergrensesnittet.

Hvert prosjekt kan lykkes på egen hånd. Problemene begynner når en agent må gjennomføre en arbeidsflyt på tvers av dem alle.

Du kan gi en agent nøyaktig kundeinformasjon, men hva skjer videre hvis applikasjonen som skal handle på grunnlag av den, har gjemt kritiske regler i gammel programkode? Eller du kan gjøre et ryddig API tilgjengelig, mens dataene bak det fortsatt er inkonsistente. Agenten kan utføre en handling, men kan du stole på beslutningen?

I begge tilfeller har vi modernisert deler av teknologien uten å modernisere arbeidet.

Agentisk KI bryr seg ikke om hvilket moderniseringsprosjekt som var vellykket. Den er opptatt av om hele arbeidsflyten fungerer.

Slik ser det ut i praksis. En kunde trengte å få fart på tilbudsarbeidet for kompliserte motorreparasjoner, der kontraktene fastsetter hvilke deler som kan repareres, skiftes ut eller overhales. Hvert tilbud krevde dager, noen ganger uker, med manuell gjennomgang av kontrakter og vedlikeholdsmanualer. Kunden hadde allerede modernisert dataplattformen sin, men tilbudene ble ikke utarbeidet raskere fordi flaskehalsen aldri hadde vært dataene. Det var gjennomgangen. Vi bygget arbeidsflyten på nytt rundt en pakke med researchagenter, reduserte tiden brukt på gjennomgangen med 80 prosent og fikk tilbudsarbeidet til å gå i et helt annet tempo.

Derfor kan ikke modernisering av applikasjoner og data planlegges som to uavhengige arbeidsstrømmer. Arkitekturen må støtte det fullstendige forretningsresultatet.

Et API gjør ikke et system klart for agenter

Det kan være fristende å tro at løsningen er enkel: Gjør endepunktene tilgjengelige, koble til agenten, og så er du ferdig.

Jeg skulle ønske det var så enkelt.

Å hente informasjon er én ting. Å kreditere et beløp, oppdatere en økonomisk post eller bestille en reservedel er noe helt annet. Da snakker vi om å utføre handlinger, ikke bare om å få tilgang.

Det er her jeg bruker begrepet kontrollflate for agenter: det avgrensede, styrte grensesnittet som agenter bruker til å lese fra og skrive til registre.

API-er og MCP-servere kan gjøre verktøy og data tilgjengelige for agenter. Men MCP håndhever ikke automatisk forretningsreglene deres eller avgjør hvem som har fullmakt til å handle. Disse kontrollene må fortsatt bygges inn i de underliggende systemene og arbeidsflytene.

Kan agenten hente autoritative data? Er forretningsreglene tydelige og konsekvent anvendt? Kan den anbefale en handling, men bare utføre handlinger den er autorisert til å utføre? Når noe går galt, kan vi spore handlingen, håndtere unntaket og, der det er mulig, reversere den?

Dette er ikke problemer en bedre modell løser på egen hånd. Det er spørsmål om arbeidsflyt, applikasjonsdesign, dataarkitektur, integrasjon og styring. Og de må besvares samlet.

Ta utgangspunkt i arbeidet, ikke teknologien

Så hvor bør du begynne?

Jeg ville ikke begynt med å gjøre alle applikasjoner hodeløse eller åpne for alle tilgjengelige API-er. Jeg ville begynt med én meningsfull arbeidsflyt i virksomheten.

Følg arbeidsflyten fra begynnelse til slutt. Hvilke systemer inneholder opplysningene? Hvor ligger forretningslogikken? Hvilke data kan agenten stole på? Hvilke beslutninger krever godkjenning fra et menneske? Hva skjer hvis et system svikter halvveis? Hvordan opprettholdes styringen?

Da finner du de viktige hullene. Det er veikartet for moderniseringen: en samordnet liste over oppgaver på tvers av applikasjoner, data, integrasjoner og kontroller, styrt av et forretningsmål snarere enn av usammenhengende teknologiprosjekter.

Og mål resultatene deretter. Ikke etter hvor mange API-er dere har gjort tilgjengelige eller hvor mye data dere har migrert, men etter om arbeidsflyten gjennomføres pålitelig, hvordan unntak håndteres, og om forretningsresultatene blir bedre.

Målet er ikke full autonomi overalt. Det er pålitelig og tillitvekkende gjennomføring, med menneskelig skjønn der det hører hjemme.

Den egentlige endringen handler om mer enn hodeløs teknologi

Det som begeistrer meg, er ikke å bli kvitt dashbordene. Det er det som skjer når folk ikke lenger må flytte arbeid manuelt mellom frakoblede systemer for å få jobben gjort.

Men vi kommer ikke dit ved å legge en agent oppå en arkitektur som aldri var utformet for den.

Den neste generasjonen virksomhetsprogramvare vil ikke bare kjennetegnes av hva den lar mennesker se. Den vil kjennetegnes av hva den lar agenter gjøre, pålitelig og ansvarlig.