Der går en fortælling i markedet om, at “alle andre” allerede er langt med agenter. Gracelys pointe er den modsatte. Mange ledere overvurderer, hvor bagud de faktisk er, og teams lærer hurtigere, når de først begynder at bygge, end de selv regner med. Det er betryggende – og risikabelt. For når adoption stiger, gør omkostningerne det også. Hurtigt.
Red Hats diagnose af stall mode
På AI Impact beskrev Gracely tre knaster, der går igen, når agenter rammer virkeligheden: cost-disciplin, sikkerhedsblindspots og organisatorisk friktion. VentureBeats dækning gengiver, at agentforbrug ligger flere størrelsesordener over chatbot-æraen, hvilket skubber regningen opad for hvert API-kald og hver tool-iteration. Samtidig bliver afhængigheden af få modelleverandører tydeligere, og flere virksomheder kigger derfor mod alternativer for at styre både pris og infrastrukturkontrol. Alt sammen plausible observationer – men uden tal i artiklen, der kvantificerer størrelsesordenerne.
Gracely siger også, at hold rykker hurtigere op ad læringskurven end ventet, når de bygger agenter i praksis. Det sætter topledelsen i et spændingsfelt. Presset fra bestyrelser på at levere AI-fremskridt møder stigende spend. Og hvis modningen i governance og drift ikke følger med, rammer projekterne muren. Den lyd kender man godt. Et klik af skuffelse, når PoC’en forbliver en demo i et mødelokale.
Virksomheder mislæser ofte konkurrencen
Frygten for at være bagud er en omkostning i sig selv. Ifølge VentureBeat-artiklen overestimerer mange enterprise-ledere, hvor langt konkurrenter er på agentik. Misforståelsen lever ikke kun af hype, men af manglen på interne feedback-loops. Når først et lille agentprojekt lander hos to udviklere og en driftsprofil, går der sjældent lang tid, før tempoet findes. Den oplevelse går igen i samtaler på tværs af brancher. Nej, det er ikke statistik, men mønsteret virker robust nok til at kalde ud.
Konsekvensen er vigtig: træk vejret, og byg beviserne selv. Angst køber for dyre modeller, for brede platforme og for hurtige løfter. Et mindre, målt eksperiment med tydelige guardrails koster mindre end et halvt års styringskomitéer, der forsøger at købe sig til modenhed.
Sådan vælter regningen
Hvorfor eksploderer omkostninger i agentiske flows sammenlignet med en klassisk chatbot i en supportkanal? De fleste agenter laver flere kald per opgave. De henter værktøjer, læser dokumenter, skriver mellemkonklusioner, evaluerer og prøver igen. Tokens går til både systemprompter, tilstandsmanagement og kæder af funktionskald. Læg dertil, at output ofte bliver længere for at sikre kvalitet med redundans. Summen er multiplicativ, ikke lineær.
Det hurtigste greb mod regningen er modelvalg. Default til den største model er dyrt og sjældent nødvendigt. Gracely fremhæver right-sizing som den primære løftestang. Ingen forsikringstegning kræver hele verdens viden. Eller fodboldstatistik. Pointen er jordnær og korrekt, men VentureBeats artikel leverer ikke kvantificerede spareeksempler. Det bør man efterspørge internt. Helt nøgternt i et regneark per use case.
Værktøjerne der faktisk sænker spend
Tre tekniske greb går igen i erfarne teams. Semantic routing: klassificér opgaver og send dem mod små, mellem eller store modeller efter kompleksitet. Caching: gem svar på gentagne forespørgsler, især systemprompter, statiske værktøjsbeskrivelser og hyppige retrieval-spørgsmål. Model-hierarki: kald små modeller først til ekstraktion, klassifikation og plan-skitser, og eskaler kun, når usikkerheden er høj.
Tradeoffs er reelle. Routing kræver gode eval-set, ellers forværres kvaliteten i hjørnesager. Caching er svær ved personfølsomme data, hvor kontekst varierer meget, og TTL skal styres stramt. Model-hierarki kan øge latenstid en smule, fordi man lægger flere trin ind, selv om GPU-regningen falder. Men i enterprise-regi går tidsforbruget ofte på integration og godkendelser, ikke 200 millisekunder mere i inference. Det er en fair byttehandel.
Modelafhængighed og markedstrykket
VentureBeat refererer Gracely for, at to til tre topudbydere siger, de taber penge og søger børsmarkedet for at lukke hullerne. Det er en markant påstand, som bør læses med forbehold. Artiklen linker ikke til regnskaber eller officielle udtalelser, der kvantificerer tabene. Signalværdien er dog klar nok. Hvis kerneleverandører kører med subsidieret prissætning i dag, kan priskurver ændre retning i morgen, og afhængigheden blive dyrere end den ser ud nu.
Derfor kigger flere virksomheder på alternativer. Poly-model strategier, hvor man kombinerer flere udbydere. Eller drift af udvalgte open source-modeller i egne miljøer for at få mere kontrol med data og cost. Det er ikke gratis at skifte. Man køber kompleksitet i drift, eval og sikkerhed, og man skal kunne dokumentere compliance. Men fleksibiliteten giver bedre forhandlingskraft og lavere risiko for lock-in.
Sikkerhedsblindspots i agenters adfærd
Når agenter får handlemuligheder, dukker nye angrebsflader op. Prompt-injektion i værktøjsbeskrivelser. Dataforgiftning via kilder, der ligner interne, men ikke er det. Over-permissive tokens, hvor en enkelt læk åbner for kædereaktioner af handlinger i tredjepartssystemer. Gracely taler om blindspots, der først står klart i produktion. VentureBeat gengiver advarslen, men leverer få konkrete hændelser, hvilket efterlader et behov for delte post-mortems fra branchen.
Praktisk betyder det, at virksomheder må opdatere sikkerhedsmodellen. Gør threat modelling for autonome flows til standard inden release. Isolér credentials per værktøj og per agent, og brug kortlivede tokens. Indfør approval-gates for bestemte handlinger, fx finansielle transaktioner, masse-udsendelser eller data-sletninger. Og log alt. Post-action audit trails med input, beslutningsgrundlag og output er ikke pæne at kigge på, men uundværlige, når noget går galt en tirsdag klokken 02.17.
Organisatorisk friktion afgør skæbnen
Teknikken kan være flot. Alligevel stagnerer adoption, hvis governance, ansvar og incitamenter er uklare. VentureBeat og Red Hats budskab er, at forandringens kernelogik er organisatorisk. Beslutningslinjer for, hvem der ejer runbooks. Hvem der godkender modelskift. Hvem der må opsætte nye værktøjer. Uden det går projekter i cirkler. Man kan næsten høre de samme møder gentage sig måned efter måned.
Change management er kedeligt, men målbart. Sæt KPI’er, der ikke bare handler om demoer, men om stabil drift: tid til gendannelse ved fejl, antal vellykkede gennemførte workflows per uge, cost per completed workflow. Ja, det er banalt. Nej, det bliver ikke gjort konsekvent. Og uden sponsorat fra ledelsen bliver agenter ved med at være pilot-darlings.
Fra PoC til drift kræver et produktionsapparat
Skalering kræver mere end en model. Det kræver et helt operationslag omkring den. Infrastruktur til at køre evals, rollback af prompter og værktøjsopdateringer, CI for prompts og værktøjsbeskrivelser, CD til sikre deploys i miljøer med forskellige dataklasser. Dertil observability, så man kan se, hvad der foregår, når et agentforløb tager en drejning klokken 16 på månedens sidste hverdag.
En enkel tjekliste, der prioriterer realitet over skønhed, kan hjælpe:
- Observability: målinger af tokenforbrug per workflow, værktøjskald per opgave, latenstid per hop, fejlrate per værktøj, andel af eskalationer til mennesker.
- Kontrol: policy-as-code for, hvilke handlinger der kræver approval, og hvem der må ændre policies.
- Dataops: dokumenterede datastrømme til retrieval, versionsstyring af indekser, datakvalitetsalarmer.
- Modelstyring: eval-batteri per use case, canary-udrulninger og automatisk rollback ved kvalitetsregression.
- Incident-håndtering: runbooks for modelfejl, promptdrift, rate limits og tredjepartsnedbrud.
Når right-sizing bliver virkeligt
At matche model til opgave er nemt at sige, sværere at gøre disciplineret. Det kræver en taxonomi for opgavetyper, et sæt faste evals og et hierarki af modeller fra lille til stor. Man må acceptere, at 5 til 10 procent af opgaverne vil eskalere til en større model, og at det er okay. Det samme gælder caching. Den virker bedst, når man identificerer de 10 til 20 prompts, der æder mest. Ikke når man forsøger at cache alt over en kam.
VentureBeats artikel giver ikke konkrete gevinster i procenter ved semantic routing eller caching. Det er et hul i rapporteringen – og en invitation til at måle selv. Ét råd her er lavpraktisk: Start med to modeller, ikke fem. Få styr på skillelinjen mellem dem, og udvid først, når gevinsten er dokumenteret over flere uger, ikke én god dag.
Sektorperspektiv fra pharma
I lægemiddeludvikling er problemet ikke mangel på data. Det er spredningen. AWS’ ML-blog beskriver, hvordan viden ligger i PubMed, interne labnoter, genomdatabaser og rapportarkiver, og hvordan fragmenteringen gør tidlig forskning langsom. Succesraten er lav, screening tager måneder, og evidensspor er svære at samle, når folk skifter job. Det er præcis et miljø, hvor agenter kan give mening, hvis de kan binde kilder sammen uden at smadre integriteten.
GraphRAG og domænespecifikke vidensgrafer nævnes som veje til at forbinde brudstykkerne. Det lyder teknisk, men handler om noget enkelt: at kunne svare på, hvad der allerede er prøvet – med dokumentation. Ikke bare en smart opsummering, men en kæde af kilder, som en regulator kan kigge i. Her bliver audit trails, dataklassificering og versionskontrol ikke bare nice to have. De er passet til branchen.
Hvad ledere bør gøre nu
Ledelse handler her om at insistere på disciplin i stedet for slogans. Budgetstyring: kræv synlige dashboards for spend per use case og break-glass-regler for eskalation til dyre modeller. Model-governance: fastlæg evals, kanarier og beslutningskriterier for skift mellem modeller. Sikkerhedsreview: gennemfør trusselsmodeller for de 2 til 3 vigtigste agentflows og fjern over-permissive tokens. Gør det kvartalsvist, ikke årligt.
Leverandørstrategi kræver valg. Enten fokuserer man dybt på én platform og lever med lock-in for enklere drift. Eller man bygger poly-models og køber kompleksitet for at få pris- og compliance-fordele. Begge strategier virker, hvis de vælges bevidst og dokumenteres. Målepunkter for succes bør være jordnære: cost per completed workflow, MTTR for modelskift, andel af manuelle eskalationer og driftstabilitet over tid.
Lad os tale om manglerne i fortællingen
VentureBeats dækning er nyttig, men efterlader huller. Påstande om flere størrelsesordener højere agentforbrug er ikke kvantificeret. Referencen til tab hos topudbydere er ikke bundet til offentlig finansdata. Og de sikkerhedshændelser, der omtales som blindspots, er ikke ledsaget af cases. Det gør ikke indsigterne ugyldige, men det gør det nødvendigt, at virksomheder selv indsamler tal. Gerne anonymiserede, så branchen kan lære hurtigere.
En sidste ting, der overraskede mig, er hvor stille feltet er om standard-KPI’er for skaleringssucces. MTTR for modelfejl, cost per completed workflow og fejlrate per værktøj bør efterhånden være lige så normale som CPU og RAM i traditionelle dashboards. Indtil det bliver standard, vil sammenligninger være slørede, og beslutninger mere politiske end tekniske.
Næste skridt uden store armbevægelser
Vil man undgå stall mode, er vejen mindre glamourøs, end slides lover. Kortlæg de 3 til 5 vigtigste agentflows. Mål spend, kvalitet og fejl. Indfør routing mellem to modeller, ikke fem. Sæt approval-gates på risikofyldte handlinger. Og byg et minimalt, men rigtigt, observability-lag, der gør fejlsøgning kedeligt enkelt. Det er ikke smukt. Men det virker.
Hvis man forventer mirakler fra en enkelt model, bliver man skuffet. Hvis man forventer fremskridt fra en disciplineret kæde af små skridt, ender man sjældent i pilotlimbo. Man opdager først forskellen, når man sidder med det i hænderne. Og ja, man kan næsten lugte den varme elektronik i serverrummet, når workloads stiger en fredag efter frokost. Det er der, styringen skal stå sin prøve.
