Agent‑frameworks har fyldt spalterne i to år, men mange teams sidder stadig fast i proof‑of‑concepts, der aldrig bliver til drift. Vi fulgte en udvikler, der testede ti af de største frameworks i 2026. Ikke en pæn demo, men rigtige opgaver med fejl, tidspres og logfiler. Her er guiden, vi selv manglede.
Timingen er banal. Rådene skifter hver måned, mens driftsbehovene står stille. I stedet for feature‑bingo samler vi det, der faktisk flytter noget i en dansk virksomheds hverdag.
Hvad vi dækker
(Fra 1608) Kernen er en praktisk gennemgang af ti agent‑frameworks testet hands‑on hos Towards AI. Herfra henter vi mønstre, smertepunkter og valgkriterier.
(Snilld 1609) Vi lægger vores erfaringer fra nordiske projekter ovenpå: hvor ting knækker i drift, hvad vi ville bygge først, og hvor vi ville holde igen.

Metode og de ti frameworks
(Fra 1608) Forfatteren testede: LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAIs Agents SDK, PydanticAI, Haystack Agents, LlamaIndex Workflows, Atomic Agents og DSPy. Testen beskriver oplevelser og trade‑offs, ikke reproducerbare benchmarks. Læs performance som kvalitative indsigter.
(Snilld 1609) Vi spejlede pointerne i små sandboxes og mini‑PoCs for at se, hvor de holdt hos os. Ikke standardiserede målinger, men nok til at genkende mønstre.
Hovedkonklusion
(Fra 1608) Økosystemet er fragmenteret. Ingen klar vinder. Frameworks vægter forskelligt mellem kontrol og abstraktion, orkestreringsstil, tool‑calling og håndtering af state og memory.
(Snilld 1609) Oversat til praksis: vælg bevidst. Hver ekstra abstraktion gemmer kompleksitet et andet sted. Mere automagi betyder mere on‑call, når noget låser tirsdag kl. 22.

Tre smertepunkter vi ser igen og igen
(Fra 1608) 1) Tool‑calling bliver rodet: stop, retry, timeouts, semantiske fejl. 2) State og memory undervurderes og ender ofte i wrapper‑logik for kontekst, idempotens og snapshots. 3) Orkestrering skalerer skævt, og observability ryger, når antallet af agenter vokser.
(Snilld 1609) Vi har set samme mønstre hos en dansk retail‑aktør og et mellemstort SaaS‑team. I en intern test ramte vi et tool‑callback deadlock ved netværksfejl, hvor retries og circuit breaker kæmpede om ejerskab. Vi opdagede det for sent i Grafana. Læringen sad fast.

Hvor nogle frameworks skiller sig ud
(Fra 1608) Til strukturerede outputs peges især på PydanticAI og DSPy. Når output skal være valid JSON, hjælper klare kontrakter og tæt fejlhåndtering.
(Snilld 1609) LangGraph og LlamaIndex Workflows giver god kontrol over flow, men kræver tålmodighed med state, logging og limkode. AutoGen og CrewAI gør multi‑agent‑opsætninger nemme, men hold øje med on‑call‑byrden. OpenAIs Agents SDK er stramt og pænt, men binder jer delvist til deres måde at gøre ting på.
Debugging og observability
(Fra 1608) Dokumentation, debugging‑hjælp og observability varierer markant. Kryds‑framework livscyklus‑indsigt er ofte fraværende.
(Snilld 1609) Aftal en logging‑kontrakt før første linje kode: felter, korrelations‑id, værktøjsnavne, timing, retry‑tællere. Brug OpenTelemetry‑traces eller bare en Postgres‑tabel med et simpelt dashboard. Uden sporbarhed lærer I ikke af fejlene. Og så gentager de sig.
Valgkriterier der dur
(Fra 1608) Vælg efter problemfit, integrations‑ og dependency‑fodaftryk, model‑ og providersupport og produktionsmodenhed og stabilitet. Ikke kun features.
- (Snilld 1609) Problemfit: Kan frameworket bevise værdi på jeres top‑use case på to uger.
- Kontrol kontra abstraktion: Hvor meget vil I selv styre tool‑kald, retries og state.
- Model‑support: Hvilke LLM’er, function‑calling og streaming‑mønstre virker i praksis hos jer.
- Integrationsbyrde: Webhooks, auth, idempotens, netværkspolicies. Hvad koster limkoden.
- Observability: Hooks til structured logging og traces uden omskrivning af halvdelen af koden.
- Fejltolerance: Retry‑politikker, timeouts, circuit breakers. Overlever den en dårlig fredag.
- Licens og afhængigheder: MIT eller Apache, eller noget der bider senere. Tjek transitive deps.
- Vedligehold: Releases, issues, dokumentation, commit‑puls. Er der liv i projektet.

Hvornår orkestrering er overkill
(Fra 1608) Start med simple function‑calling‑loops, hvis I ikke har et reelt orkestreringsbehov.
(Snilld 1609) Vi har haft størst effekt med single‑agent plus tools og først lagt en tynd supervisor på, når automatiseringsgrad, compliance‑krav eller svartider krævede det. Kedeligt valg. Stabil drift.
Konsekvenser for drift og support
(Snilld 1609) Agent‑projekter fejler sjældent i koden, men i driften. Læg grundspillet nu:
- Governance: Hvem må tilføje værktøjer, hvem godkender prompts, hvor ligger audit‑trail.
- Fejltolerance: Standardiserede retry‑politikker, backoff, circuit breakers, fallback‑svar.
- Monitorering: Dashboards på tool‑fejl, model‑latency, tokens pr. flow, succesrater.
- Incident‑playbooks: Hvad gør vagthavende, når modellen skifter adfærd fredag aften.
- Omkostninger: Tokens, eksterne API‑kald, CPU‑spikes. Sæt budgetalarmer.
(Snilld 1609) Integrationsomkostninger kan fordoble en PoC, især når webhooks og auth skal synkroniseres på tværs af tre miljøer. Ikke eksotisk. Bare hverdagsarbejde der tager tid.
Hurtige PoC‑idéer
(Snilld 1609) Vil I teste de tre store risici på 2–4 uger, så vælg én case til hver:

- Tool‑calling stress: Agent med 3–4 værktøjer, hvor ét fejler bevidst 5 procent af tiden. Mål genopretning og svartid.
- State og memory: Flerversioneret opgave med idempotenskrav og genkørsel fra midten. Mål wrapper‑kodens omfang.
- Orkestrering: To agenter med simpel supervisor. Indfør netværksjitter og se, hvor koordineringen bryder.
(Snilld 1609) Hold miljøet lukket med syntetiske data og fuld logging. Brug Redis eller Postgres til state‑snapshots og OpenTelemetry til spor.
Hvor markedet bevæger sig
(Fra 1610) Hexo Labs har åbnet SIA som open source under MIT. Idéen er et selvforbedrende loop, der både kan ændre agentens scaffold og justere modelvægte via LoRA‑opdateringer, med base på openai\/gpt‑oss‑120b og støtteprocesser på Claude Sonnet 4.6. Vi mangler uafhængige tests af sikkerhed, stabilitet og effekt. Tag det som retning, ikke som produktionsråd.
(Snilld 1609) Hvis I vil eksperimentere med selvforbedrende loops, så indfør ekstra kontrolpunkter: godkendelse før vægtopdatering, versionsspor for prompts og scaffold, og en hurtig rollback‑sti. Ellers bliver audit umulig.
Hvad vi ville gøre nu
(Snilld 1609) Et jordnært roadmap:
- Uge 0–1 PoC‑design: Én use case med klare succeskriterier og logging‑kontrakt.
- Uge 1–2 Prototype: Single‑agent med function‑calling. PydanticAI eller DSPy ved strengt JSON‑krav.
- Uge 2–3 Observability: Structured logging, traces og simpelt dashboard. Indfør bevidste fejl.
- Uge 3–4 Pilot: Læg tynd supervisor på ved reelt behov. Sæt incident‑playbook og on‑call.
- Måned 2–3 Drift: Stabiliser retries, sæt budgetalarmer, plan for modelopdatering. Udvid først derefter.
(Snilld 1609) Ingen fortryder at have sat logging før orkestrering.
Risici og huller i dækningen
(Fra 1608) Der mangler stadig: reproducerbare benchmarks på latency, throughput og fejlprocenter; fulde konfigurationer (modeller, temperaturer, prompts, hardware); tal for adfærd ved mere end 5–10 samtidige agenter; dyb sikkerheds‑ og compliance‑gennemgang; klarhed om licenser og transitive afhængigheder; viden om langtidsholdbarhed ved modelopdateringer.
(Fra 1610) SIA kræver uafhængig verifikation af sikkerhed, stabilitet og governance, især når vægte opdateres automatisk.
Kilder og hvad der er hvad
(Fra 1608) Fragmentering, trade‑offs, smertepunkter og fremhævelsen af PydanticAI og DSPy til strukturerede outputs stammer fra udviklerens hands‑on test hos Towards AI.
(Snilld 1609) Implementeringsråd, PoC‑skabeloner, drift, observability og prioriteringer er vores erfaring fra projekter i Danmark og Norden.
(Fra 1610) Oplysninger om SIA, LoRA‑opdateringer og MIT‑licens er rapporteret af MarkTechPost, og vi markerer eksplicit, at uafhængige tests mangler.
Opsummering
Agent‑frameworks i 2026 er stærke og uens. Ingen universel vinder. PydanticAI og DSPy er stabile til strukturerede outputs. Orkestrering bliver hurtigt overkill. Observability fra dag ét er det bedste forsvar mod dyre nedture.
Hold det enkelt. Mål alt. Pas på state. Byg flere lag først, når forretningen beder om det. Forskellen mærkes, når man sidder med det i hænderne.