LangGraph vs. CrewAI vs. direkte API: valg af agentframework i 2026

Landskabet for agentframeworks er i 2026 mere modent end for to år siden og ikke mere overskueligt. LangChain/LangGraph er fortsat dominerende, men bliver i stigende grad udfordret. CrewAI har fundet sin niche. Pydantic AI vinder tilhængere med typesikkerhed. OpenAI Agents SDK og Anthropics Claude SDK vokser. Samtidig går en stille bevægelse af teams tilbage til direkte API-kald, især i produktion.

Alle frameworks har både fortalere og kritikere. Debatten er højlydt. Beslutningen er som regel mere personlig end objektiv.

Denne artikel skærer igennem støjen med en arbejdende arkitekts blik: Hvad hvert framework faktisk gør, hvor det passer, og hvilke ærlige mønstre vi ser i produktion. Ingen religionskrig, kun afvejninger.

Hvad et agentframework skal bruges til

Inden sammenligningen skal vi afklare, hvad vi vælger imellem. Et »agentframework« leverer typisk:

1. En måde at definere agenter på — deres rolle, værktøjer og adfærd.
2. En eksekveringsløkke — kald LLM’en, fortolk output, beslut næste handling, kald værktøjer, og gentag.
3. Tilstandshåndtering — hvad agenten husker, og hvordan det organiseres.
4. Værktøjsintegration — hvordan værktøjer defineres og stilles til rådighed.
5. Orkestrering — flere agenter, der arbejder sammen, forgrenede workflows og genforsøg.
6. Hooks til observerbarhed — sporing, logning og fejlfinding.
7. Praktiske hjælpefunktioner — promptskabeloner, almindelige mønstre og hjælpeværktøjer.

Hvert framework prioriterer disse forskelligt. Nogle vægter orkestrering tungt, andre fokuserer på agentdefinition, og andre igen er tynde lag over model-API’erne.

Landskabet

LangChain / LangGraph

Den store aktør. LangChain begyndte som et Python-bibliotek til at kæde LLM-kald sammen og blev de facto-framework for mange AI-projekter. LangGraph er det agentspecifikke framework ovenpå.

Det gør det godt:

• LangGraph til tilstandsmaskiner. Grafmodellen (noder som trin, kanter som overgange og tilstand, der sendes imellem) passer godt til komplekse agentworkflows.
• Rigt økosystem. Mange integrationer: vektordatabaser, modelleverandører, værktøjer og observerbarhed.
• LangSmith til observerbarhed. Moden brugerflade til sporing og fejlfinding.
• Stor udbredelse. Mange eksempler, omfattende dokumentation og mange mennesker med erfaring.

Det gør det ikke:

• Abstraktionsomkostning. Især LangChain har mange abstraktionslag. Fejlfinding er sværere, og det kræver arbejde at forstå, hvad der faktisk sker.
• API-ændringer. Hyppige inkompatible ændringer. Kode fra 12 måneder siden kræver ofte opdateringer.
• Ydelsesomkostning. Lag af indirektion koster latenstid og tokens.
• Indlæringskurve. Reel beherskelse tager uger.

Hvornår du bør vælge det:

• Komplekse agentworkflows med forgrenet tilstand.
• Teams, der har gavn af et standardframework (mange udviklere og fælles mønstre).
• Når du ønsker LangSmith-observerbarhed.

Hvornår du bør fravælge det:

• Enkle chatbots eller løkker med én agent (direkte API er enklere).
• Teams, der tidligere har haft problemer med LangChains ændringstakt.
• Projekter, hvor hvert millisekund latenstid betyder noget.

CrewAI

Et multiagent-framework med fokus på rollebaserede agenter. Hver agent har en rolle, et mål og en baggrundshistorie; de samarbejder om opgaver.

Det gør det godt:

• Multiagent-orkestrering. Indbygget understøttelse af agenter, der taler sammen, uddelegerer og samarbejder.
• Rollebaseret mental model. Let at forstå (»researchagenten gør X, skriveagenten gør Y«).
• Enklere end LangGraph til multiagentarbejde. Hurtigere at komme i gang med.
• Aktivt community.

Det gør det ikke:

• Begrænset dybde for enkeltagenter. Hvis opgaven kræver én kompleks agent, kan CrewAI’s abstraktioner passe dårligt.
• Ydelse. Multiagentopsætninger mangedobler LLM-kaldene; pris og latenstid vokser hurtigt.
• Modenhedsgab. Yngre end LangChain, og nogle ujævnheder består.
• Holdningspræget. Mindre fleksibelt end direkte løsninger.

Hvornår du bør vælge det:

• Multiagent-workflows, hvor rollefordeling giver mening.
• »Crew«-modeller (et team af agenter, der arbejder sammen).
• Hurtig prototyping af multiagentidéer.

Hvornår du bør fravælge det:

• Opgaver til én agent (overdimensioneret).
• Produktion, hvor ydelse betyder meget (multiagent er dyrt).
• Opgaver, hvor »agentsamarbejde« er mere teater end substans.

Pydantic AI

Et nyere framework med fokus på typesikkerhed og udvikleroplevelse.

Det gør det godt:

• Stærke typer. Pydantic hele vejen igennem. Input og output er typede. Fejl opdages under udviklingen.
• Ren API. Mindre abstraktion end LangChain og tættere på model-API’erne.
• Moderne Python. Async, type hints og Pydantic v2.
• Modeluafhængigt. Fungerer med de fleste leverandører.

Det gør det ikke:

• Mindre økosystem. Færre integrationer end LangChain.
• Mindre gennemprøvet i stor skala. Nyere, og produktionsmønstrene er stadig under udvikling.
• Færre orkestreringsværktøjer. Ikke lige så funktionsrigt som LangGraph til komplekse workflows.

Hvornår du bør vælge det:

• Python-teams med fokus på typesikkerhed.
• Opsætninger med én agent eller enkel multiagent.
• Teams, der foretrækker minimal abstraktion.

Hvornår du bør fravælge det:

• Meget kompleks orkestrering (LangGraph passer måske bedre).
• Projekter uden Python (det er kun til Python).
• Når du har brug for et stort økosystem af færdige integrationer.

OpenAI Agents SDK

OpenAI’s officielle agentframework, optimeret til OpenAI-modeller.

Det gør det godt:

• Optimeret til OpenAI. Særligt designet til GPT-5/o3-mønstre.
• Enkel API. Mindre abstrakt end LangChain.
• Indbyggede overdragelser. Overdragelser mellem agenter er en førsteklasses funktion.
• Moden sporing. Indbygget observerbarhed knyttet til OpenAI-dashboardet.

Det gør det ikke:

• Binding til OpenAI. Designet til OpenAI’s modeller. Andre leverandører er besværlige at bruge.
• Mindre fleksibilitet. Nogle mønstre er lettere i mere generelle frameworks.
• Nyere end LangChain. Mindre community.

Hvornår du bør vælge det:

• Når I satser fuldt ud på OpenAI-modeller.
• Når I ønsker en leverandørunderstøttet vej.
• Ved enkel til moderat agentkompleksitet.

Hvornår du bør fravælge det:

• Ved en strategi med flere leverandører (brug et mere generelt framework eller direkte API).
• Når I primært bruger Anthropic eller Google.

Anthropic Claude SDK

Tilsvarende — Anthropics vej til at bygge agenter med Claude.

Det gør det godt:

• Optimeret til Claude. Særligt velegnet til Claudes udvidede tænkning, computer use og MCP-integration.
• Idiomatisk til Claude-modeller.
• Stærk MCP-understøttelse.

Det gør det ikke:

• Binding til Claude. Samme afvejning som med OpenAI Agents SDK.

Hvornår du bør vælge det:

• Når I satser fuldt ud på Claude.
• Ved omfattende brug af Claude-specifikke funktioner.

Hvornår du bør fravælge det:

• Ved en strategi med flere leverandører.

Direkte API

Spring frameworks helt over. Kald OpenAI-, Anthropic- eller Gemini-API’erne direkte. Skriv selv løkken.

Det gør det godt:

• Fuld kontrol. Alle dele af systemet er jeres.
• Ingen abstraktionsomkostning. Det, du ser, er det, der kører.
• Let at fejlfinde. Ingen lag at grave igennem.
• Let at optimere. Ingen framework-overhead.
• Ingen versionsuro. I opgraderer, når I vælger det.

Det gør det ikke:

• Mere kode. I håndterer selv de mønstre, frameworket ellers håndterer.
• Genopfindelse. Almindelige mønstre implementeres igen i hvert projekt.
• Mindre standardisering. Forskellige teams bygger ensartede systemer forskelligt.

Hvornår du bør vælge det:

• Modne teams, der leverer produktionssystemer, hvor pålidelighed er vigtigere end bekvemmelighed.
• Enkeltstående, fokuserede brugsscenarier, som ikke kræver et frameworks fleksibilitet.
• Ydelseskritiske stier.
• Efter prototyping med et framework og indlæring af mønstrene.

Hvornår du bør fravælge det:

• I en ny, udforskende fase, hvor spørgsmålet er »hvad skal vi bygge?« (et framework hjælper med at opdage mønstrene).
• Teams med begrænset udviklingskapacitet.

LlamaIndex

Begyndte som et RAG-fokuseret bibliotek og er vokset ind på det bredere agentområde.

Det gør det godt:

• RAG-tunge systemer. Blandt de bedste til agenter med fokus på retrieval.
• Dataforbindelser. Mange integrationer til datakilder.
• Modne retrieval-abstraktioner.

Det gør det ikke:

• Svagere agentabstraktioner. Bedre til RAG end til generelle agenter.
• En vis overlapning med LangChain-økosystemet.

Hvornår du bør vælge det:

• Stort fokus på retrieval og RAG.
• Behov for forbindelser til mange datakilder.

Hvornår du bør fravælge det:

• Agentarbejde uden RAG.

Microsoft Autogen, Semantic Kernel

Microsofts tilbud. Autogen til multiagent og Semantic Kernel til generelle AI-applikationer.

Det gør det godt:

• Integration med Microsoft-økosystemet. Fungerer godt med Azure, .NET og Microsoft 365.
• Semantic Kernel: opleves mere enterprise-orienteret end alternativerne.
• Autogen: stærkt til multiagent-research.

Det gør det ikke:

• Mindre community uden for Microsoft-miljøer.
• Mindre fremdrift end LangChain/LangGraph.

Hvornår du bør vælge det:

• Teams i et Microsoft-miljø.
• Omfattende Azure-integration.

Dimensioner, du bør overveje

Valget handler ikke om at kåre en vinder, men om at matche afvejningerne med dit projekt.

Dimension 1: Orkestreringens kompleksitet

Hvor komplekse er jeres agentworkflows?

• Enkel (chatbot, én agent, lineært flow): direkte API eller Pydantic AI.
• Moderat (én agent, forgrenet logik): Pydantic AI, LangGraph eller direkte API.
• Kompleks (flere agenter, tilstandsmaskiner, genforsøg): LangGraph, CrewAI eller specialbygget.
• Meget kompleks (store tilstandsmaskiner, parallelle agenter, kompleks routing): LangGraph eller specialbygget.

Dimension 2: Produktionsmodenhed

Hvor vigtig er pålidelighed i forhold til eksperimenter?

• Eksperimenter/prototyping: Ethvert framework hjælper jer med at arbejde hurtigt.
• Produktion, kundevendt: Foretræk velkendte frameworks (LangChain har flest mønstre, direkte API giver mest kontrol).
• Produktion, missionskritisk: Direkte API vinder ofte; I forstår hver eneste linje.

Dimension 3: Teamets størrelse og kompetencer

• Lille team (1-3 udviklere): Mindre framework-overhead er bedre. Direkte API eller enkle frameworks.
• Mellemstort team (5-15): Et framework hjælper med standardisering. LangChain eller Pydantic AI.
• Stort team (20+): Et framework er afgørende for fælles mønstre. LangGraph eller et internt framework.

Dimension 4: Leverandørstrategi

• Flere leverandører: Generelle frameworks (LangChain, Pydantic AI) eller direkte API.
• Én leverandør: Leverandørens SDK (OpenAI Agents SDK, Anthropic Claude SDK).

Dimension 5: Følsomhed over for ydelse

• Latenskritisk (brugeroplevelse i realtid): Direkte API. Frameworks tilføjer latenstid.
• Omkostningskritisk (høj volumen): Direkte API. Frameworks kan tilføje tokens.
• Standard: Ethvert framework er fint.

Dimension 6: Behov for observerbarhed

• Stærkt fra start: LangChain + LangSmith.
• Byg selv: Ethvert framework + jeres eget observerbarhedslag.

Bevægelsen mod direkte API

Et mønster, vi ser stadig oftere i 2026: Modne teams flytter fra frameworks til direkte API i produktion.

Hvorfor:

• Efter 1-2 års agentarbejde kender teams mønstrene. Frameworkets værdi (at lære mønstrene fra sig) er udtømt.
• Frameworks ændrer sig. Direkte API gør ikke. Stabilitet i produktion taler for direkte adgang.
• Ydelse: Frameworks tilføjer overhead. Direkte API gør ikke.
• Fejlfindbarhed: Når noget går galt, gør direkte API det tydeligt, »hvad der skete«.
• Tilpasning: Alle produktionssystemer har unikke krav. Frameworks modarbejder tilpasning; direkte API omfavner den.

Det er ikke en fordømmelse af frameworks. De er glimrende til læring, prototyping og moderat komplekse produktionssystemer. Men i moden produktion er direkte API ofte det bedre valg.

Et typisk migreringsmønster:

1. Start med LangChain eller lignende.
2. Byg de første versioner.
3. Lær mønstrene.
4. Bemærk friktionspunkter (fejlfinding, ydelse, tilpasning).
5. Flyt kritiske stier til direkte API.
6. Til sidst består det meste produktionskode af direkte API.

Det er ikke et framework, der har fejlet; det er dets naturlige livscyklus for nogle teams.

En praktisk beslutningsramme

Hvis du vælger til et nyt projekt:

Trin 1: Definér projektet.

• Hvor kompleks er agenten?
• Hvor mange udviklere?
• Produktion eller prototype?
• Én eller flere leverandører?

Trin 2: Anvend tommelfingerregler.

Trin 3: Byg en prototype, og vurder den.

Brug en uge med det valgte framework. Byg et repræsentativt udsnit. Vurdér:

• Passer det til jeres mønstre?
• Arbejder I imod frameworket eller sammen med det?
• Er fejlfinding håndterbar?
• Er ydelsen acceptabel?

Hvis ja: Fortsæt. Hvis nej: Prøv et andet eller gå direkte.

Trin 4: Undgå uigenkaldelig binding.

Strukturér selv frameworkbaseret kode, så det er muligt at skifte. Isolér brugen af frameworket i et tyndt lag, og byg logikken i frameworkuafhængig kode.

Mønstre, der går på tværs af frameworks

Uanset framework er visse mønstre universelle:

Adskillelse af ansvar. Prompthåndtering adskilt fra agentlogik, adskilt fra værktøjsdefinitioner, adskilt fra eksekveringsløkken. Hvert framework hjælper med noget; I håndterer resten.

Observerbarhed. Spor hvert LLM-kald. Spor hvert værktøjskald. Saml målinger. Det er jeres ansvar uanset framework.

Trinbudgetter og nødudgange. Alle produktionsagenter har dem. Frameworks håndhæver dem ikke; I skal tilføje dem.

Evalueringspakker. Frameworks indeholder ikke seriøse evalueringsværktøjer. Byg dem separat (Promptfoo, Braintrust eller specialbygget).

Produktionshærdning. Hastighedsgrænser, idempotens, fejlhåndtering og fallback. Frameworket giver nogle primitiver; I bygger resten.

Fokuserer I på disse universelle mønstre, betyder det konkrete framework mindre. Teamets disciplin betyder mere.

Vurdering af hvert framework

Efter arbejde med mange af dem er vores holdningsprægede vurdering:

LangChain/LangGraph: Kraftfuldt, men tungt. Værd at lære. I produktion flyttes kritiske stier ofte væk fra det.

CrewAI: Sjovt til multiagentidéer. I produktion spildes multiagentparadigmet ofte på opgaver, der ikke havde brug for det. Brug det selektivt.

Pydantic AI: Undervurderet. Typesikkerheden giver udbytte. Værd at afprøve.

OpenAI Agents SDK / Anthropic Claude SDK: Gode, hvis I har valgt den pågældende leverandør. Ellers er bindingen en risiko.

LlamaIndex: Stadig førende til RAG-tungt arbejde. Mindre overbevisende til generelle agenter.

Direkte API: Valget for modne teams. Begynd ikke nødvendigvis her, men forvent at ende her for produktionskritisk kode.

Microsoft Autogen / Semantic Kernel: Gode i Microsoft-økosystemet; mindre overbevisende udenfor.

En migreringshistorie

For at gøre det konkret er her et realistisk forløb:

Måned 1-3: Teamet bygger sine første AI-funktioner i LangChain. Hurtigt at levere, og mange mønstre bliver lært.

Måned 4-6: Krav til produktionskvalitet opstår — observerbarhed, evalueringer og ydelse. Teamet bygger dem oven på LangChain.

Måned 7-9: Nogle LangChain-abstraktioner bliver friktionspunkter. Teamet begynder at pakke LangChain ind i egne interfaces.

Måned 10-12: En LangChain-opgradering ødelægger flere systemer. Teamet omskriver kritiske stier til direkte API. Mindre kritiske stier forbliver i LangChain.

År 2: Det meste produktionskode bruger direkte API. LangChain bruges lejlighedsvis til prototyping. Teamets interne »agentframework« — bygget på direkte API — er standarden.

Det er ét gyldigt forløb. Andre er også gyldige — nogle teams bliver tilfredse i LangChain, og andre springer det over fra første dag.

Et andet perspektiv: Hvad du egentlig vælger

Ud over frameworket vælger du:

• Et community at lære fra.
• Et tempo af API-ændringer, du skal leve med.
• Et sæt mønstre at standardisere efter.
• En fejlfindingsoplevelse.
• En strategi for observerbarhed.
• En fremtidig migreringsomkostning.

Frameworket er ét udtryk for disse forhold. Men det er dem, der påvirker teamet i hverdagen.

Et framework, der passer til jeres community, tolerance for ændringer, mønstre, fejlfindingsstil og behov for observerbarhed, er det rigtige valg. Uden det match er selv det mest populære framework forkert for jer.

Konklusionen

Der findes ikke ét universelt bedste agentframework i 2026. Det rigtige valg afhænger af projektets kompleksitet, teamets størrelse, produktionsmodenhed, leverandørstrategi og teamets præferencer.

En fungerende tilgang:

• Match frameworket med projektkravene ved hjælp af tommelfingerreglerne ovenfor.
• Byg en prototype, før I forpligter jer.
• Strukturér koden, så den kan skiftes ud.
• Fokuser på universelle mønstre uanset framework.
• Forvent udvikling — det, der passer nu, passer måske ikke om 12 måneder.

Mange modne teams ender med direkte API til produktionskritisk kode. Frameworks er fortsat nyttige til prototyping, læring og moderat kompleks orkestrering. Valget er ikke religiøst, men kontekstafhængigt.

Vælg det, der passer i dag. Justér, når det ikke længere passer. Det system, du bygger, betyder mere end det framework, du bygger det med.