De fleste virksomheder, der ruller AI-agenter ud, sætter først for
De fleste virksomheder, der ruller AI-agenter ud, sætter først for alvor et tal på gevinsten, efter agenten allerede kører. Zillow og Glean gjorde det modsatte. Begge byggede en måle-baseline, før en eneste kundehenvendelse blev automatiseret, og det er præcis den rækkefølge, der afgør om et ROI-tal senere kan forsvares over for en bestyrelse eller blot er et gæt med et procenttegn på.
Kontekst
Data var ikke det svære - at huske kundens rejse var
Zillows tekniske ledelse har været tydelig om, at den store forhindring aldrig var at skaffe data. Boligdata, lånedata og mæglerinformation findes rigeligt i ejendomsbranchen. Det svære var noget andet: at en AI-agent kunne huske, hvor en given kunde befandt sig i sin rejse, på tværs af en telefonsamtale, en låneansøgning og en samtale med en mægler, uden at kunden skulle gentage sig selv hver gang kanalen skiftede.
Det er en pointe, der rammer bredere end ejendomsbranchen. Enhver virksomhed, der sætter AI-agenter til kundevendte opgaver, støder på det samme problem, som også går igen i debatten om agentisk kontekstlag: uden et lag, der bærer konteksten med, bliver hver kanal en ø, og kunden oplever en organisation, der ikke kan huske sin egen samtale.
Arkitektur
Sådan bygger Zillow et vedvarende kontekstlag på tværs af telefon, lån og mægler
Zillows løsning var ikke endnu en model, men et kontekstlag, der ligger under modellerne og binder kanalerne sammen - en tilgang der minder om et selvlærende kontekstlag. Laget holder styr på, hvor en kunde er i processen, hvilke spørgsmål der allerede er stillet, og hvilke beslutninger der er truffet, uanset om kunden ringer ind, udfylder en låneformular eller taler med en mægler i felten.
Det betyder i praksis, at en AI-agent, der tager telefonen, kan trække på den samme kontekst som den agent, der behandler låneansøgningen, og at en mægler kan se historikken uden at skulle stykke den sammen manuelt. Gevinsten er ikke kun en bedre kundeoplevelse. Det er også, at hver ny agent, der tilføjes til systemet, ikke skal starte forfra med at lære kunden at kende. Kontekstlaget bliver den infrastruktur, alle fremtidige AI-investeringer bygger ovenpå, hvilket ændrer regnestykket for, hvad hver ny agent reelt koster at sætte i drift.
Skalering
Tusindvis af Glean-agenter i produktion via en MCP-gateway
Glean har taget en anden, men beslægtet vej og har nu tusindvis af agenter kørende i produktion. Det er ikke tusindvis af separat byggede løsninger, men agenter, der kobles til virksomhedens systemer gennem en fælles MCP-gateway, et lag der standardiserer, hvordan en agent henter data, kalder værktøjer og taler med andre systemer.
Den arkitektur løser et problem, mange organisationer først opdager, når de forsøger at skalere fra en enkelt pilotagent til flere dusin: uden et MCP-kompatibelt koblingslag bliver hver ny agent en engangsintegration, der skal vedligeholdes for sig selv. Med en gateway bliver tilføjelsen af agent nummer femogtyve markant billigere end agent nummer to, fordi grundarbejdet allerede er lagt. Det er en af de mest konkrete lektioner fra Gleans skalering: gevinsten ved at investere i et fælles lag stiger, jo flere agenter der kommer til.
Med en gateway bliver tilføjelsen af agent nummer femogtyve markant billigere end agent nummer to, fordi grundarbejdet allerede er lagt.
Omkostninger
Model-routing og forudberegnet kontekst som omkostningshåndtag
Når agenter tælles i tusinder, bliver omkostningen per forespørgsel en ledelsesbeslutning i sig selv, ikke bare en teknisk detalje. Glean bruger model-routing til at sende hver opgave til den model, der er tilstrækkelig til formålet, i stedet for altid at trække på den dyreste og mest kraftfulde model.
Dertil kommer forudberegnet kontekst, altså at relevant information hentes og struktureres på forhånd, så agenten ikke skal foretage de samme dyre opslag igen og igen for hver ny henvendelse. Begge greb minder om optimering af orkestreringslaget og handler om det samme: at gøre omkostningen per interaktion forudsigelig og styrbar, i stedet for at lade den vokse lineært med antallet af agenter og forespørgsler. For en virksomhed, der planlægger at gå fra en pilot til drift i stor skala, er det her forskellen mellem et budget, der holder, og et der løber løbsk, ligger.
ROI
Måle-baseline før udrulning: forudsætningen for troværdig ROI
Det, der binder Zillows og Gleans tilgange sammen, er rækkefølgen. Begge etablerede en klar baseline, før agenterne blev sat i drift. Det lyder banalt, men det er sjældent gjort i praksis. De fleste organisationer ruller en agent ud og forsøger bagefter at rekonstruere, hvad situationen var før, typisk ud fra ufuldstændige eller slet ikke sammenlignelige tal.
Uden en baseline før udrulning bliver ethvert ROI-tal en påstand, ikke et bevis - det samme gabet mellem test og produktion illustrerer i evalueringssammenhæng. Man kan sige, at en agent har reduceret svartiden med treogtyve procent, men kun hvis man rent faktisk vidste, hvad svartiden var, inden agenten kom til. Det samme gælder fejlrater, eskaleringer til mennesker og kundetilfredshed. En baseline er ikke et ekstra skridt, man kan spare væk for at komme hurtigere i gang. Den er selve forudsætningen for, at nogen bagefter kan stole på tallet.
For virksomheder, der overvejer deres næste AI-agent, er lektionen fra Zillow og Glean derfor ikke primært et spørgsmål om, hvilken model der vælges. Det er et spørgsmål om, hvorvidt der findes et kontekstlag, der binder kanalerne sammen, en arkitektur der gør det billigere at skalere fra en til hundrede agenter, og en baseline, der er målt, før første agent går i produktion. Uden de tre ting bliver selv den bedste model svær at forsvare på et regneark.