Bygga en AI-agent: ett konkret exempel

AI-agenter är årets modeord, och det märks. Mycket av det som säljs som agenter är i praktiken en vanlig automatisering med finare namn, och Gartner har förutspått att över 40 procent av alla satsningar på AI-agenter avbryts före utgången av 2027, ofta på grund av oklart värde, höga kostnader och svaga kontroller. Det bästa sättet att skilja substans från hype är att titta på ett konkret bygge. Så låt oss göra det.

Att bygga en AI-agent end-to-end är att koppla en språkmodell till verkliga system, data och godkännandeflöden så att den kan utföra en avgränsad uppgift i produktion, inte bara svara i en demo. Skillnaden mot en chattassistent är att agenten gör något, i flera steg och system, inte bara berättar.

En AI-agent skiljer sig från en assistent genom att den utför en uppgift i flera steg och system, med en människa som sätter ramarna och godkänner.

Exemplet nedan är representativt, inte ett specifikt kunduppdrag, men mönstret känner de flesta igen. Detaljerna är förenklade. Principerna är de vi arbetar efter på riktigt.

Exemplet: en agent för offertförfrågningar

Ta ett bolag som får in offertförfrågningar via mejl. Idag läser en säljare förfrågan, slår upp produkt och pris i affärssystemet, kontrollerar lagersaldo och kundvillkor, skriver ihop en offert och skickar. Det är repetitivt och regelstyrt på vägen, men kräver ett omdöme i slutet. Med andra ord: en bra kandidat för en agent som tar grovjobbet och låter människan godkänna.

Det här är inte processautomatisering i vanlig mening, där ett fast flöde upprepas likadant varje gång. Förfrågningarna ser olika ut, och agenten måste tolka vad som efterfrågas innan den vet vilka uppgifter den behöver hämta. Det är där det agentiska kommer in.

Vad agenten gör, steg för steg

Flödet ser ut så här, och varje led motsvarar något agenten faktiskt utför i ett riktigt system.

• Läser och tolkar. Agenten läser mejlet och plockar ut vad som efterfrågas: vilken produkt, vilken kvantitet, eventuella villkor. Det är tolkningssteget, och det som gör uppgiften svår nog att motivera en agent.
• Hämtar data. Den slår upp pris, lagersaldo och kundens villkor i affärssystemet, via systemets eget gränssnitt med rätt behörigheter. Här agerar agenten i ert system, inte vid sidan av.
• Kontrollerar mot regler. Den stämmer av mot era regler: marginalkrav, tillåten rabattnivå, kreditgräns. Faller något utanför, flaggar den i stället för att chansa.
• Förbereder ett utkast. Den sätter ihop ett förslag till offert, komplett nog att granska men inte att skicka.
• Lämnar för godkännande. En säljare ser utkastet, godkänner, ändrar eller avvisar. Inget går ut utan den kontrollen.
• Skickar och loggar. Efter godkännande skickas offerten, och varje steg loggas: vad agenten läste, hämtade, föreslog och vem som godkände.

Det är fem, sex led, men poängen är inte antalet. Det är att agenten planerar sig igenom en uppgift som varierar, i flera system, med en människa vid ratten där det betyder något.

Arkitekturen bakom

Under ytan är agenten byggd i tre lager, samma struktur som i mycket av det vi bygger. Längst ner era system och er data: affärssystemet, kundregistret, prislistan. I mitten en AI-motor som tolkar förfrågan, planerar vilka uppgifter den behöver och anropar rätt funktion i rätt system för att hämta dem. Överst ett gränssnitt där säljaren ser utkastet och godkänner.

Det som gör det agentiskt, snarare än en vanlig integration, är mittenlagret. Agenten bestämmer själv vilka anrop som behövs för just den förfrågan, i stället för att följa ett fast skript. Den friheten är styrkan, och samtidigt det som måste tämjas med tydliga regler och kontrollpunkter, annars gör den för mycket.

Var det skar sig

Den ärliga delen, för den lär mer än framgångarna. Två saker krånglade tidigt.

Agenten misstolkade tvetydiga förfrågningar. En kund som skrev löst om "det vanliga" fick agenten att gissa fel produkt med stor självsäkerhet. Lösningen var inte en smartare modell, utan ett explicit tolkningssteg: agenten klassificerar förfrågan mot ett begränsat antal kända kategorier, och är den osäker frågar den hellre än gissar. Avgränsning slog finess.

Och den ville hjälpa för mycket. När en uppgift saknades fyllde den i ett rimligt antagande i stället för att stanna. Det är precis den sortens hjälpsamhet som blir farlig i en offert. Vi byggde in regeln att osäkerhet ska lyftas, inte lösas på egen hand, samma princip vi använder för att hantera AI-hallucinationer i alla våra lösningar.

Ett tredje problem var mindre uppenbart. Agenten kunde matcha en förfrågan mot fel kund när två hade liknande namn, och då blev hela offerten fel på ett sätt som var svårt att upptäcka i efterhand. Lösningen var att kräva en entydig identifiering innan något hämtades, och att hellre fråga än anta när matchningen var osäker. Mönstret går igen: agenten ska tveka där en människa skulle ha dubbelkollat.

Det som krävde mest jobb var inte modellen

En vanlig missuppfattning är att en agent mest handlar om en kraftfull modell. I det här bygget var modellen den minst besvärliga delen. Tiden gick åt till tre andra saker: att koppla in agenten i affärssystemet med rätt behörigheter, att bygga kontrollpunkterna där en människa ska in, och att avgränsa uppgiften så snävt att agenten gjorde rätt sak varje gång.

Det är samma insikt som går igen i all AI-utveckling som ska nå produktion: integration, kontroll och avgränsning avgör utfallet, inte modellens råstyrka. En agent utan kopplingar är en demo, och en agent utan kontrollpunkter är en risk.

Integrationen var dessutom den tidstjuven få räknar med. Att läsa ur ett affärssystem låter enkelt tills man inser att behörigheterna måste vara exakt rätt, att data ibland saknas eller är inkonsekvent, och att varje anrop måste tåla att systemet svarar långsamt eller inte alls. Det är inget glamoröst arbete, men det är det som avgör om agenten fungerar en torsdag i mars när allt går lite trögt, inte bara i en demo en tisdag.

Varför så många agentprojekt fastnar

Tillbaka till Gartners siffra. När fyra av tio agentsatsningar väntas avbrytas är orsaken sällan att tekniken inte fanns. Det är att projekten var för breda, för lite avgränsade och byggda utan ramar. Mycket av det som kallas agenter är dessutom egentligen fasta arbetsflöden runt ett modellanrop, vilket är helt i sin ordning, men då ska man kalla det vad det är.

En smal agent med riktig integration och ett mänskligt godkännande fungerar redan idag. En bred, oövervakad agent som ska sköta allt gör det inte. Det är samma logik som när man automatiserar en process med AI över huvud taget: börja avgränsat, behåll kontrollen, utöka när förtroendet finns. Vill ni förstå vad en agent är på ett mer principiellt plan har vi skrivit om AI-agenter för svenska SME.

Vill ni se var en agent gör nytta hos er?

Vi bygger AI-agenter som lever i era system, gör ett avgränsat jobb och håller människan i kontroll, hela vägen till produktion. Vill ni veta vilket flöde som lämpar sig först hos er? Boka ett samtal, så tittar vi på det tillsammans.