Nästa användare av din programvara är en AI-agent. Är din arkitektur redo?

Föreställ dig att en AI-agent hanterar en kunds fakturatvist. Den läser klagomålet, kontrollerar kontohistoriken och bedömer att kunden bör få en kreditering. Allt på några sekunder.

Imponerande. Be den nu att faktiskt utfärda krediteringen.

Kundavtalet finns i ett annat system. Godkännandereglerna är dolda i programkoden. Faktureringsverktyget förutsätter att en person klickar sig igenom flera skärmbilder.

Agenten förstår vad som behöver göras, men arkitekturen låter den inte slutföra uppgiften.

Det är ett problem som jag tror att fler företag kommer att stöta på när agentbaserad AI tas i drift. Det märkliga är dock att hindret för att slutföra uppgiften har väldigt lite att göra med agentens intelligens.

I åratal har vi moderniserat företagsprogramvara för dem som använder den. Nu behöver vi modernisera den för de agenter som i allt högre grad kommer att hantera den.

Användargränssnittet var aldrig hela produkten

Tänk på hur företagsprogramvara fungerar i dag. Människor öppnar program, navigerar i kontrollpaneler, fattar beslut och för arbetet vidare från ett system till ett annat. Användargränssnittet är deras sätt att interagera med verksamheten.

En agent behöver inte nödvändigtvis de skärmbilderna. Den kan hämta information och initiera åtgärder via API:er, servrar för Model Context Protocol (MCP) och andra programmatiska gränssnitt. Det är en del av övergången till en huvudlös arkitektur.

Men en huvudlös arkitektur innebär inte att programmet försvinner. Dess data, affärsregler, behörigheter och efterlevnadskrav spelar fortfarande roll. Jag skulle hävda att de spelar ännu större roll.

I åratal har programvaruleverantörer byggt konkurrensfördelar kring väl utformade användargränssnitt, användarvanor och kostnaden för att lära upp medarbetare på nytt. De fördelarna försvagas när agenter utför mer arbete utan att öppna programmets användargränssnitt. Det som blir mer värdefullt är det underliggande systemet för registerdata: tillförlitliga data, validerad domänlogik, operativ styrning och transaktioner som kan granskas.

Det får också kommersiella konsekvenser: upp till 234 miljarder dollar i utgifter för företagsapplikationer kan påverkas av omvälvningar till följd av agentbaserad AI fram till 2030. Det handlar om utgifter som riskerar att påverkas, inte om utgifter som garanterat försvinner. Och när agenter utför arbete som tidigare sköttes av människor i kontrollpaneler kan prissättning per användarplats i allt högre grad ersättas av användnings-, åtgärds- eller resultatbaserade modeller.

För programvaruleverantörer innebär det en utmaning för affärsmodellen. För företag som förlitar sig på deras program är det en arkitekturutmaning.

Vi har moderniserat delarna, inte arbetsflödet

De flesta företag har arbetat med modernisering i åratal. Ett team uppdaterar äldre program. Ett annat samlar fragmenterade data på en modern plattform. Ett tredje bygger integrationer eller nöjer sig med att förnya användargränssnittet.

Varje projekt kan lyckas på egen hand. Problemen börjar när en agent behöver genomföra ett arbetsflöde som omfattar dem alla.

Du kan ge en agent korrekt kundinformation, men vad händer härnäst om programmet som ska agera utifrån informationen har gömt viktiga regler i äldre kod? Eller så kan du tillhandahålla ett väl utformat API, samtidigt som dataunderlaget fortfarande är inkonsekvent. Agenten kan utföra åtgärden, men kan du lita på beslutet?

I båda fallen har vi moderniserat delar av tekniken utan att modernisera arbetet.

Agentbaserad AI bryr sig inte om vilket moderniseringsprojekt som lyckades. Den bryr sig om huruvida hela arbetsflödet fungerar.

Så här kan det se ut i praktiken. En kund behövde snabba upp offertarbetet för komplicerade motorreparationer, där avtalen avgör vilka delar som får repareras, bytas ut eller renoveras. Varje offert krävde flera dagars, ibland flera veckors, manuellt arbete med att gå igenom avtal och underhållshandböcker. Kunden hade redan moderniserat sin dataplattform, men offerterna blev inte klara snabbare eftersom flaskhalsen aldrig hade varit data. Det var efterforskningarna. Vi byggde om arbetsflödet kring en uppsättning researchagenter, minskade tiden för efterforskningar med 80 % och fick fram offerterna i en helt annan takt.

Därför kan modernisering av applikationer och data inte planeras som två oberoende arbetsströmmar. Arkitekturen måste stödja det fullständiga affärsresultatet.

Ett API gör inte ett system redo för agenter

Det är frestande att tro att lösningen är enkel: exponera slutpunkterna, koppla in agenten och sedan är det klart.

Jag önskar att det vore så enkelt.

Att hämta information är en sak. Att utfärda en kreditering, uppdatera en ekonomisk post eller beställa en reservdel är något helt annat. Nu talar vi om att utföra åtgärder, inte bara om att få åtkomst.

Det är här jag använder begreppet kontrollyta för agenter: ett avgränsat och styrt gränssnitt genom vilket agenter läser från och skriver till system för registerdata.

API:er och MCP-servrar kan ge agenter tillgång till verktyg och data. Men MCP tillämpar inte automatiskt era affärsregler eller avgör vem som har befogenhet att agera. Sådana kontroller måste fortfarande byggas in i de underliggande systemen och arbetsflödena.

Kan agenten hämta auktoritativa data? Är affärsreglerna tydliga och tillämpas de konsekvent? Kan agenten rekommendera en åtgärd men bara utföra sådana åtgärder som den har befogenhet att utföra? Kan vi spåra åtgärden, hantera undantaget och, när det är möjligt, återställa den om något går fel?

Det här är inte problem som en bättre modell löser på egen hand. Det handlar om arbetsflöden, applikationsdesign, dataarkitektur, integration och styrning. Och frågorna måste besvaras tillsammans.

Börja med arbetet, inte tekniken

Var ska man då börja?

Jag skulle inte börja med att göra alla applikationer headless eller exponera alla tillgängliga API:er. Jag skulle börja med ett konkret affärsflöde.

Följ det från början till slut. Vilka system innehåller informationen? Var finns affärslogiken? Vilka data kan agenten lita på? Vilka beslut kräver mänskligt godkännande? Vad händer om ett system slutar fungera mitt i processen? Hur upprätthålls styrningen?

Då hittar du de luckor som spelar roll. Det blir din färdplan för moderniseringen: en samordnad att göra-lista för applikationer, data, integrationer och kontroller, med ett affärsresultat som drivkraft snarare än fristående teknikprojekt.

Mät också resultaten utifrån det. Inte efter hur många API:er du har exponerat eller hur mycket data du har migrerat, utan efter om arbetsflödet slutförs tillförlitligt, hur undantag hanteras och om affärsresultaten förbättras.

Målet är inte autonomi överallt. Det handlar om tillförlitligt och förtroendeingivande utförande, med mänskligt omdöme där det hör hemma.

Den verkliga förändringen är större än headless

Det som entusiasmerar mig är inte att bli av med instrumentpaneler. Det är vad som händer när människor inte längre måste flytta arbetet manuellt mellan frånkopplade system för att få jobbet gjort.

Men vi kommer inte dit genom att lägga en agent ovanpå en arkitektur som aldrig utformades för den.

Nästa generation av företagsprogramvara kommer inte bara att definieras av vad den låter människor se. Den kommer också att definieras av vad den låter agenter göra, på ett tillförlitligt och ansvarsfullt sätt.