LinkedIn, Walmart og Zendesk om AI-agenter

LinkedIns problem var opstartstid, og det er et problem, jeg kender indefra. Når en agent skal spinde en ny udførelsescontainer op for hver opgave, hver samtale og hvert værktøjskald, betaler man en cold-start-afgift, der kan løbe op i sekunder. For et menneske, der venter på en side, er det irriterende. For en agent, der skal kæde ti eller tyve handlinger sammen for at nå i mål, bliver ventetiden multiplikativ. Så er systemet dødt i produktion, uanset hvor god modellen er.

LinkedIn vendte logikken om. I stedet for at bygge containere on demand holder de nu forhåndsklargjorte puljer varme og klar. En agent, der har brug for et miljø, henter et, der allerede kører, i stedet for at vente på et nyt. Det lyder simpelt, men det kræver en anden måde at tænke kapacitet på. Man betaler for beredskab i stedet for kun for faktisk forbrug. De flyttede samtidig sprogmodellerne ud til bladene i et kontrol-flow, der for det meste er deterministisk. Det er den samme erkendelse, jeg selv er landet på. Modellen skal kaldes, hvor der reelt er brug for et skøn, ikke som motor i hvert eneste trin. Det meste af en agent, der holder, er almindelig, forudsigelig kode.

Walmarts udfordring var ikke hastighed, men orden. Når mange teams i en stor organisation begynder at bygge agenter på samme tid, opstår der hurtigt overlap. To afdelinger bygger hver deres version af den samme kundeserviceagent, uden at nogen af dem ved det. Resultatet er dobbeltarbejde, adfærd der ikke hænger sammen på tværs af systemet, og en voksende bunke agenter, som ingen har det fulde overblik over.

Walmarts svar var reel governance omkring agentudvikling. Ikke som en bureaukratisk bremse, men som et register. En central oversigt over, hvilke agenter der findes, hvad de gør, og hvem der ejer dem. Før et team bygger en ny, tjekker de, om opgaven allerede er løst et andet sted. Det lyder banalt, men det er præcis den struktur, jeg ser flest springe over i iveren efter at komme i gang. Selve agenten er sjældent det svære. Det svære er grænsen: hvad den må røre, hvad den skal spørge om først, og hvad der sker, når den tager fejl. Governance er ikke papirarbejde oven på systemet. Det er selve ingeniørarbejdet.

Zendesks pointe var måske den mest kontraintuitive, og det er en, jeg selv har måttet lære. Den nemme løsning på, at en agent mangler kontekst, er at proppe mere ind i prompten. Længere historik, flere dokumenter, et større kontekstvindue. Zendesk fandt, at det ikke er vejen frem. Store kontekstvinduer er dyre at køre og langsommere at behandle, og de gør det sværere for modellen at finde den relevante information i støjen.

I stedet investerede Zendesk i datapipelines, der henter og strukturerer præcis den kontekst, en agent har brug for, i det øjeblik den har brug for den. Ikke alt læsset på forhånd. Det flytter arbejdet fra modellen til infrastrukturen omkring den. Hentning, filtrering og strukturering sker, før spørgsmålet når frem til agenten. Det er min egen erfaring i én sætning. En skarp datapipeline slår et stort kontekstvindue næsten hver gang, fordi agenten så arbejder med et rent udsnit i stedet for et støjfyldt hele.

På tværs af de tre gik tre valg igen, uanset om problemet hed hastighed, orden eller kontekst. Det er de samme tre, jeg selv vil forsvare.

Det første er systematisk evaluering. Ingen af dem stoler på, at en agent virker, fordi den så ud til at virke i en demo. De kører evals, der løbende måler agentens output mod konkrete mål, så en regression bliver fanget, før den rammer produktionen. Kan du ikke se, hvad agenten faktisk gjorde, har du ikke en medarbejder, du har en risiko med god omtale.

Det andet er et eget agent-harness. Altså det lag, der styrer, hvordan en agent kalder værktøjer, håndterer fejl og kæder handlinger sammen. I stedet for at læne sig fuldt op ad en leverandørs standardramme har alle tre bygget deres eget lag oven på, skræddersyet til deres skala og deres krav til pålidelighed. Det er den del, jeg selv ejer tidligst, fordi det er der, driften enten holder eller falder.

Det tredje er model-uafhængighed. Ingen af dem har bundet sig fast til én leverandør af sprogmodeller. De har bygget deres systemer bag egne gateways, så modellen kan skiftes ud, når noget bedre eller billigere dukker op, uden at hele arkitekturen skal rives ned, og uden at miste den kontekst, de har opbygget. Det er den samme grund til, at jeg kører på infrastruktur, jeg selv kontrollerer. Når systemet er forretningen, vil man ikke have, at forretningen er en linje på en andens udfasningsplan.

De fleste danske virksomheder, jeg taler med, er stadig på et tidligere stadie end LinkedIn, Walmart og Zendesk. Men de tre lektier gælder allerede, længe før man rammer den skala.

Tænk på opstartstid og ventetid som en reel omkostning, ikke en detalje. Skal en agent kæde flere handlinger sammen, tæller hver forsinkelse med, og et infrastrukturvalg, der virker fint til én forespørgsel ad gangen, bliver en flaskehals, når agenten skal arbejde selvstændigt gennem en hel opgave.

Hav styr på, hvilke agenter der allerede findes, før I bygger flere. Selv i en mindre organisation opstår overlap hurtigt, når to teams griber det samme problem an hver for sig. Et simpelt register sparer jer for oprydning senere.

Og husk, at mere kontekst ikke automatisk er bedre. Før I udvider, hvor meget data en agent får at arbejde med, er det værd at spørge, om problemet i virkeligheden er, at den rigtige information ikke bliver hentet frem på det rigtige tidspunkt.

Det, jeg tog med fra Transform 2026, er ikke, at agenter er svære at bygge. Det er, at infrastrukturen omkring dem kræver lige så meget omtanke som selve modellen, og at de, der tager den del alvorligt tidligt, sparer sig selv for en dyr ombygning senere. Det er ikke antallet af hænder, der afgør, hvor meget en agent-drift kan bære. Det er, hvor god infrastrukturen under den er.