Regningen for agentiske AI-systemer stiger ikke pænt. Den tager små spring. Når en agent tænker i flere trin, henter filer, kalder API’er og gentager sig selv, følger faktureringen tokens. MachineLearningMastery beskriver det ret nøgternt: i produktion er agentiske loops ofte dyre, fordi både LLM’er og eksterne API’er ligger tæt op ad tokenforbrug i deres afregning (kilde 1308). Det matcher det, vi ser i projekter.
Det mærkes især, når teams går fra chat-POC til rigtige arbejdsgange med planlægning, payloads og jobkøer. Token-økonomien æder budgettet. Vi har set månedstal, der lander to til tre gange over en ren chat-opsætning, primært fordi arkitekturen sender for meget kontekst og genkører for ofte. Det er vores erfaring fra drift, ikke laboratorietestering (se 1309).
Hvor pengene forsvinder
Mønstret er genkendeligt: gentagne loops, voksende kontekst og et standardvalg af en for dyr generalistmodel. Dertil connectors mod Gmail, Slack, Salesforce og CRM. Claude Cowork er et godt eksempel på arkitekturen: multi-step planlægning, filadgang, connectors, parallel kørsel og planlagte opgaver. Stærkt, men alle de lag forstørrer både token- og API-forbrug, hvis input ikke styres stramt (kilde 1310).
I vores audits falder nålen ofte på fire ting: for lange prompts, mangel på cache, fuld dokumentkontekst i hvert kald og modelvalg uden omtanke. En kort, stabil opsummering mellem trin kan skære meget af det overflødige væk. Det er her, vi starter, når regningen skal ned (Snilld perspektiv, 1309).
Prompt-komprimering der faktisk hjælper
Komprimering er disciplin. Omskriv input til kompakte, strukturerede repræsentationer før den dyre model. Vi bruger tre simple mønstre igen og igen: 1) kort vs. langt input med en lille for-model, 2) en abstrakt mellemrepræsentation, 3) faste templates med slots. Sidstnævnte tvinger output i felter til næste step frem for hele historier. Færre ord ind, færre tokens ud.
I en salgsautomation i foråret gik første version fra cirka 6–8 tusind tokens per lead-gennemløb til under 3 tusind, alene ved at lade et lille for-trin destillere mails til en 12-linjers faktaliste. Kvaliteten holdt, men vi justerede to felter for tone. Tal og effekt er vores egne driftserfaringer, ikke peer-reviewede benchmarks, se 1309.
Hvordan laves den liste konkret fra en mailtråd? Først normaliserer vi signaturer og citater væk, derefter ekstraheres nøglevendinger om behov, tidsramme, budget og seneste handling. Til sidst mappes de til faste felter. Eksempel på målformat:
- Lead-navn
- Virksomhed
- Rolle eller funktion
- Produktinteresse
- Nuværende løsning
- Budgetindikator
- Tidsramme
- Nøglekrav
- Risici eller forbehold
- Seneste kontaktpunkt
- Anbefalet næste skridt
- Confidence-score
Det er kedeligt på den gode måde. Nem at validere. Nem at overlevere.
Når RAG slår fulde dokumenter
RAG giver mening, når konteksten er tung. I stedet for at sende hele manualer i hvert loop, lægger du dem i en vektorstore og henter kun relevante bidder. Det fjerner gentagen ballast, til gengæld kommer der noget latenstid og vedligehold af indekset med i pakken. Det er et fair bytte i de fleste vidensdomæner, men kræver opsyn med retrieverkvalitet og opdateringsvinduer (Snilld erfaring, 1309).
Hold det enkelt i starten: små, konsistente chunks, en let re-ranking og synlig logging af retrieval-hits. Log fx uden at gemme hele prompten:
{
"request_id": "uuid",
"retriever_query": "string",
"selected_snippets": ["doc_hash#offset"],
"re_ranker_version": "vX.Y",
"model_version": "model@ver",
"latency_ms": 142
}
Det gør fejlsporbarhed mulig uden at blæse tokenforbruget op (1309).
Caching og respons-summering uden drama
Cache er ofte den hurtigste gevinst. Genbrug summarerede svar i minutter frem for sekunder, afhængigt af domæne og friskhedskrav. Brug TTL, der matcher forretningen, og nøgler, der følger intentionen, ikke kun rå tekst. Et robust key-design kunne se sådan ud:
key = hash(
normalize(user_role) +
normalize(intent) +
normalize(query_semantics) +
join(sorted(doc_hashes))
)
Normalisér, så støj som tidsstempler og e-mailtråde ikke ødelægger hits. Summér først, cache bagefter. Vi ser markant højere hit-rate, når det sker i den rækkefølge, fordi små sproglige forskelle ikke vælter nøglen. Erfaring fra drift, 1309.
Hybridarkitektur uden at flække kvaliteten
Ikke alt kræver en stor model. Læg rutineopgaver ned på lokale eller mindre hosted modeller: klassificering, deduplikering, simple ekstraktioner, strukturvalidering. Brug den store model til planlægning, kreativ syntese eller tricky fejlfinding. En router kan træffe valg på inputlængde, usikkerhedsscore eller enkle regler. Heuristikker rækker langt i praksis, så længe I måler og kan rulle tilbage (1309).
Men pas på overivrig model-hopping. Hver overgang koster i latenstid og engineering. Vi havde internt en opsætning, hvor en lille lokal model lavede entity-ekstraktion på vores domæne, og den dyre model kun blev kaldt ved tvivl. Det føltes hurtigere og billigere i vores setup på det tidspunkt. Anekdote, ja, men nyttig for beslutningen om hybrid (1309).
Orkestrering, batching og budgetvagter
Samleforespørgsler er sund fornuft. Batch små henvendelser, hvor de naturligt kan slås sammen. Paralleliser kun, når det ikke fordobler konteksten. Og læg økonomiske sikringer ind i rate-limiters: stopkriterier pr. bruger, pr. minut og pr. jobtype. En simpel budgetvagt, der kan afbryde en kæde pænt før den går amok, betaler sig hurtigt. Det er et af de greb, der har reddet vores kunder på travle dage, se 1309.
Vi så for nylig et support-flow med high-frequency polling mod et CRM. Ingen cache, ingen rate-limit. Loggen lød som en printer, der ikke ville holde op. Efter en time var budgettet for dagen brugt flere gange. En backoff og event-triggers fjernede hovedpresset. Drifterfaring, 1309.
Operativt overblik der betaler sig
Uden monitorering af tokens flyver du i blinde. Læg et dashboard med mindst tre metrikker: tokens pr. intention, succesrate pr. loop og cost-per-action. Skift model med omtanke og A/B-test prompt-versioner som var det landing pages. Vi ramte selv en fælde, hvor en strammere prompt gav lavere tokens men flere genkørsler. Rodårsagen var rollefordelingerne mellem del-agenterne. Den slags dukker først op, når tallene står i lyset (1309).
Glem ikke ekstern API-pris. En agent koster ikke kun LLM-tokens. Den kalder søgning, filer, CRM, måske e-sign. Det hele lægges oveni. Det er også pointeret i 1308 og i vores egne notater, 1309.
Compliance når du komprimerer
Komprimering og cache kan gøre sporbarhed sværere. Løsningen er ikke at gemme alt, men at gemme det rigtige. Vi anbefaler at logge: prompt-skabelon-id, dokument-hashes, retrieval-ids, modelversioner og beslutningsnoder. Gem mellemrepræsentationer, som agenten traf valg på, i stedet for hele råinput. Så kan audit rekonstruere et forløb uden at sprænge budget og retention-politik. Det er sådan, vi sætter det op i regulerede miljøer, se 1309.
Til retention: aftal opbevaring for metadata, ikke fuldtekst, og giv sikkerhed adgang til originalsager via styrede referencer frem for duplikater. Det gør både DPO og drift roligere, uden at systemet bliver tungt.
Et kort, anonymt casebillede
En nordisk B2B-aktør bad os trimme en salgsautomatisering. Systemet scannede indbakker, Slack og CRM for nye leads og kørte 4–6 agent-trin. Uden cache. Hvert trin sendte fuld kontekst med mails og profilfelter. Resultat: månedlig drift cirka 2,5 gange en sammenlignelig chatløsning. Vi indførte tre ting: prompt-komprimering til 12 felter, RAG for produkttekster og en kort cache på resuméer. Efter tre uger faldt tokens pr. lead fra omkring 7.200 til cirka 2.900 i median. Besparelsen holdt hen over en måned. Kvaliteten var uændret ifølge deres SDR-team. Det er vores egne tal fra drift, ikke benchmarks, se 1309.
En lille detalje fra maskinrummet: en connector gentog en identisk forespørgsel hvert halvandet minut som standard. Det var nok til at vælte flere dashboards på travle dage, indtil vi satte backoff og cache på plads.
Hvad betyder det for jeres workflow
Udviklere bruger mindre tid på lange instrukser, mere på retrievers, vektorstores og cache-hit-rates. Data engineers bliver vigtige for pipelines. SRE skal kende nye failure-modes: cache-miss storme, svingende RAG-kvalitet, eksploderende batch-jobs. Produktledere bør regne på cost-per-action, ikke kun nettoscore.
Supportteams har brug for en kort playbook. Eksempel:
- Hit-rate falder brat: tjek nøglenormalisering og seneste deploy af prompt-skabelon.
- RAG svarer forældet: verificér ingest-kø og indeksopdateringer.
- Rate-limiter fyrer ofte: se efter loops uden stopkriterier.
Et 6–12 ugers realistisk roadmap
Uge 1–2 Audit: Byg et token-map over flows, kortlæg top-kald og udgift pr. kæde. A/B-test 1–2 komprimeringsskabeloner i en sandkasse.
Uge 3–5 Pilot: Implementer basal prompt-komprimering, et lille cache-lag og en enkel RAG-pipeline på ét dokumentkorpus. Sæt dashboard op med tokens per intention, succesrate og cost-per-action.
Uge 6–8 Udvidelse: Læg mindst én rutineopgave over på en mindre eller lokal model. Tilføj rate-limits og batch, hvor det giver mening. Formalisér metadata-logging til audit.
Uge 9–12 Hærdning: Kør kapacitets- og fejlsimulering, finjustér retriever, justér cache-keys, indfør budgetvagt og fail-safes. Forbered produktions-checklisten med rollback og eskalationsveje.
Hvad koster det og hvad sparer man
Vi er forsigtige med tal. Størrelsen af besparelser afhænger af workload og loop-frekvens. Vores konservative erfaringer i drift: prompt-komprimering og summariseringslag kan ofte reducere tokens i de dyre trin i størrelsesordenen 20–50 procent. RAG oveni kan sænke totalen yderligere der, hvor dokumenter før fyldte meget. Caching varierer; realistiske hit-rater kan ligge højt i support og salg, men svinger med sæson og adfærd. Alt ovenstående er Snilld-ranges fra projekter, ikke peer-reviewede benchmarks, se 1309.
En hurtig regneøvelse, helt generisk: Har du 100.000 handlinger om måneden, 3.000 tokens i snit per handling og en typisk pris per tusind tokens, lander rå LLM-delen i millionklassen årligt. Skærer du en tredjedel, er forskellen også i millionklassen. Ranges, ja, men store nok til at finansiere et par ingeniøruger uden at blinke. Egen erfaring fra drift, 1309.
Implementeringsfælder at undgå
Tre klassikere. 1) Over-komprimering, der fjerner signal: du sparer tokens, men får flere genkørsler. 2) RAG uden governance: indeks bliver forældet, svar mister aktualitet. 3) Cache-nøgler med volatile felter: hit-rate kollapser, og I dømmer cache ude for tidligt. Og nummer fire, den kedelige: ingen budget-grænser. Sæt caps per projekt og rolle.
En lille værktøjskasse
Pseudo-workflow til prompt-komprimering:
raw_input -> normalize() -> redact(PHI) ->
small_model.summarize(template=12_fields) ->
validate(schema) -> big_model(reason over fields)
Eksempel på simpel metrik-log for tokens per intention:
{
"ts": 1712845523,
"request_id": "uuid",
"user_id": "anonym_ref",
"intent": "lead_qualify",
"tokens_prompt": 842,
"tokens_completion": 511,
"tokens_total": 1353,
"model": "provider:model@ver",
"cache_hit": true,
"cost_usd": 0.0031,
"success": true
}
Det er alt, der skal til for at spotte de dyre kæder og handle på dem uden at drukne i data.
Hvad vi ikke dækker her
Der findes mere avanceret komprimering med lærte encodere, proprietære token-scorere og distillation-tricks. Spændende, men kræver særskilt test og ofte specialværktøjer. Vi holder os her til mønstre, man kan rulle ud nu. Branchen mangler desuden mere generelle benchmarks. Vi overvejer at samle data til en åben rapport og hører gerne fra teams, der vil bidrage, se 1309.
Prioriteringsliste når I skal i gang
Start sådan her:
- Kortlæg token-flowet og find de dyreste kæder.
- Indfør en enkel komprimeringsskabelon og et lille cache-lag.
- Tilføj RAG på de største dokumentbjerge.
- Flyt rutineopgaver til mindre eller lokale modeller.
- Opsæt dashboard, budgetvagt og A/B på prompts.
- Stram metadata-logging så audit er muligt uden fuldtekst.
Man opdager først forskellen, når man sidder med det i hænderne.
Bilag og kilder
Kilder: MachineLearningMastery om koblingen mellem agentiske loops, token-baseret fakturering og høje omkostninger (1308). Snillds egne manualer og projektnoter er grundlaget for strategierne her, med klar caveat om at tal er ranges fra drift, ikke akademiske studier (1309). Og en gennemgang af Claude Cowork, der illustrerer agentiske arkitekturer med multi-step, connectors og planlagte opgaver, som typisk driver forbruget op, hvis man ikke komprimerer og cacher (1310).
- MachineLearningMastery, Implementing Prompt Compression to Reduce Agentic Loop Costs, 1308.
- Snilld manual brief, anbefalinger om komprimering, RAG, caching, hybridarkitektur, batching og rate-limiting, 1309.
- Claude Cowork 101, eksempel på agentisk arkitektur med multi-step og connectors, 1310.
