Din næste softwarebruger er en AI-agent. Er din arkitektur klar?

Forestil dig en AI-agent, der håndterer en kundes indsigelse mod en faktura. Den læser klagen, gennemgår kundens kontohistorik og vurderer, at kunden bør have en kreditering. Alt sammen på få sekunder.

Imponerende. Bed den nu om rent faktisk at udstede krediteringen.

Kundeaftalen ligger i et andet system. Godkendelsesreglerne er gemt dybt i applikationens kode. Faktureringsværktøjet forventer, at en person klikker sig gennem flere skærmbilleder.

Agenten forstår, hvad der skal gøres, men arkitekturen lader den ikke fuldføre opgaven.

Det er et problem, som jeg forventer, at flere virksomheder vil støde på, efterhånden som agentbaseret AI går i produktion. Det mærkelige er imidlertid, at hindringen for at fuldføre opgaven kun i meget ringe grad har noget at gøre med agentens intelligens.

I årevis har vi moderniseret virksomhedssoftware til de mennesker, der bruger den. Nu skal vi modernisere den til de agenter, der i stigende grad kommer til at betjene den.

Brugergrænsefladen var aldrig hele produktet

Tænk over, hvordan virksomhedssoftware fungerer i dag. Folk åbner applikationer, navigerer rundt i betjeningspaneler, træffer beslutninger og flytter opgaver fra ét system til et andet. Brugergrænsefladen er den måde, de interagerer med virksomheden på.

En agent har ikke nødvendigvis brug for de skærmbilleder. Den kan hente oplysninger og iværksætte handlinger via API’er, MCP-servere baseret på Model Context Protocol og andre programmatiske grænseflader. Det er en del af skiftet mod en hovedløs arkitektur.

Men en hovedløs arkitektur betyder ikke, at applikationen forsvinder. Dens data, forretningsregler, tilladelser og krav til overholdelse af regler er stadig vigtige. Jeg vil hævde, at de er vigtigere end nogensinde.

I årevis har softwareleverandører opbygget konkurrencefordele omkring veludformede brugergrænseflader, brugernes vaner og omkostningerne ved at oplære medarbejdere på ny. Disse fordele svækkes, når agenter udfører mere arbejde uden at åbne applikationens brugergrænseflade. Det, der bliver mere værdifuldt, er det underliggende registreringssystem: pålidelige data, valideret domænelogik, operationel styring og transaktioner, der kan revideres.

Det får også kommercielle konsekvenser: Op til 234 milliarder $ i udgifter til virksomhedsapplikationer kan være udsat for forstyrrelser som følge af agentbaseret AI inden 2030. Det er udgifter, der risikerer at blive påvirket, ikke udgifter, som med sikkerhed forsvinder. Og når agenter overtager arbejde, som tidligere blev udført af mennesker i betjeningspaneler, kan prissætning pr. bruger i stigende grad blive afløst af modeller baseret på forbrug, handlinger eller resultater.

For softwareleverandører er det en udfordring for forretningsmodellen. For virksomheder, der er afhængige af deres applikationer, er det en arkitektonisk udfordring.

Vi har moderniseret delene, men ikke arbejdsgangen

De fleste virksomheder har arbejdet med modernisering i årevis. Ét team opdaterer ældre applikationer. Et andet samler fragmenterede data på en moderne platform. Et tredje opbygger integrationer eller nøjes med at opdatere brugergrænsefladen.

Hvert projekt kan lykkes for sig. Problemerne begynder, når en agent skal udføre en arbejdsgang på tværs af dem alle.

Du kan give en agent nøjagtige kundeoplysninger, men hvad sker der så, hvis applikationen, der skal handle på oplysningerne, stadig har kritiske regler gemt dybt i ældre kode? Eller du kan stille en velfungerende API til rådighed, mens de underliggende data stadig er inkonsistente. Agenten kan handle, men kan du stole på dens beslutning?

I begge tilfælde har vi moderniseret dele af teknologien uden at modernisere arbejdet.

Agentbaseret AI er ligeglad med, hvilket moderniseringsprojekt der lykkedes. Det afgørende er, om hele arbejdsgangen fungerer.

Sådan ser det ud i praksis. En kunde havde brug for at fremskynde tilbudsarbejdet ved komplekse motorreparationer, hvor kontrakterne fastlægger, hvilke dele der må repareres, udskiftes eller renoveres. Det tog dage, nogle gange uger, at udarbejde hvert tilbud, fordi der skulle foretages manuel research på tværs af kontrakter og vedligeholdelsesmanualer. Kunden havde allerede moderniseret sin dataplatform, men tilbuddene blev ikke udarbejdet hurtigere, fordi flaskehalsen aldrig havde været dataene. Det var researchen. Vi byggede arbejdsgangen om med en række researchagenter, reducerede researchtiden med 80 % og fik tilbudsarbejdet op i et helt andet tempo.

Derfor kan modernisering af applikationer og data ikke planlægges som to uafhængige arbejdsspor. Arkitekturen skal understøtte det samlede forretningsresultat.

En API gør ikke et system klar til agenter

Det kan være fristende at tro, at løsningen er enkel: Gør endepunkterne tilgængelige, tilslut agenten, og så er du færdig.

Hvis bare det var så nemt.

Det er én ting at hente oplysninger. At udstede en kreditering, opdatere en finansiel postering eller bestille en reservedel er noget helt andet. Her taler vi om at udføre handlinger, ikke bare om at få adgang.

Det er her, jeg bruger udtrykket agenternes kontrolflade: den afgrænsede, styrede grænseflade, som agenter bruger til at læse fra og skrive til registreringssystemer.

API’er og MCP-servere kan stille værktøjer og data til rådighed for agenter. Men MCP håndhæver ikke automatisk jeres forretningsregler eller afgør, hvem der har bemyndigelse til at handle. De kontroller skal stadig bygges ind i de underliggende systemer og arbejdsgange.

Kan agenten hente autoritative data? Er forretningsreglerne tydelige og anvendes de konsekvent? Kan den anbefale en handling, men kun udføre de handlinger, den har bemyndigelse til at udføre? Kan vi spore handlingen, håndtere undtagelsen og, hvor det er muligt, rulle den tilbage, når noget går galt?

Det er ikke problemer, som en bedre model kan løse på egen hånd. Det er spørgsmål om arbejdsgange, applikationsdesign, dataarkitektur, integration og styring. Og de skal besvares samlet.

Tag udgangspunkt i arbejdet, ikke teknologien

Så hvor skal man begynde?

Jeg ville ikke begynde med at gøre alle applikationer headless eller blotlægge alle tilgængelige API’er. Jeg ville begynde med én forretningsmæssigt vigtig arbejdsgang.

Følg den fra start til slut. Hvilke systemer indeholder registreringerne? Hvor ligger forretningslogikken? Hvilke data kan agenten have tillid til? Hvilke beslutninger kræver menneskelig godkendelse? Hvad sker der, hvis et system svigter midt i forløbet? Hvordan opretholdes styringen?

Så finder du de mangler, der betyder noget. Det er din moderniseringsplan: en koordineret opgaveliste på tværs af applikationer, data, integrationer og kontroller, der tager udgangspunkt i et forretningsresultat frem for usammenhængende teknologiprojekter.

Og mål på det, der betyder noget. Ikke hvor mange API’er du har blotlagt, eller hvor mange data du har migreret, men om arbejdsgangen gennemføres pålideligt, hvordan undtagelser håndteres, og om forretningsresultaterne forbedres.

Målet er ikke autonomi overalt. Det er pålidelig og tillidsvækkende eksekvering, med menneskelig dømmekraft dér, hvor den hører hjemme.

Det reelle skifte handler om mere end headless-arkitektur

Det, der begejstrer mig, er ikke at slippe af med dashboards. Det er tanken om, at folk ikke længere behøver at flytte arbejdet manuelt mellem usammenhængende systemer for at få opgaven løst.

Men vi når ikke dertil ved at placere en agent oven på en arkitektur, der aldrig er designet til den.

Den næste generation af virksomhedssoftware vil ikke kun blive defineret af, hvad den giver mennesker mulighed for at se. Den vil blive defineret af, hvad den giver agenter mulighed for at gøre – pålideligt og ansvarligt.